Bug Report: GLCD SSD1963 component generates [-Woverflow] warnings and fails on PIC32MX795F512L

[r_teixeir]

Hello Matrix TSL Team,

I am experiencing a critical issue with the gLCD SSD1963 (Parallel Mode) component in Flowcode 11.2.17 when targeting the PIC32MX795F512L microcontroller on a Mikromedia+ board.

Even with standard properties configurations, the compiler (XC32) outputs three consecutive warnings regarding integer truncation:
"warning: large integer implicitly truncated to unsigned type [-Woverflow]"

The compilation log clearly pinpoints that the truncation overflow happens inside the auto-generated code of the component libraries, specifically inside the following functions:
- FCD_04581_gLCD_SSD1963__Initialise
- FCD_04581_gLCD_SSD1963__ClearDisplay

Because of this math calculation overflow inside the initialisation commands string, the PIC32 execution crashes at boot, blocking the peripheral pins and rendering the display completely unresponsive (including the hardware backlight trigger).

To isolate the issue, I successfully tested other hardware peripherals on the same board. Both the RGB LED pins (RA9, RA14, RA15) and the passive Buzzer (RF13) are working perfectly via Timer 2 interrupts. This confirms that the configuration fuses (80 MHz clock with 16 MHz crystal via PRIPLL, Watchdog disabled, etc.) are 100% correct, and the chip is running normally. The failure is strictly happening during the display component initialization block.

I tried to modify the Display Refresh Rate PLL multipliers/dividers, Colour Bit Depth (switching between 16-bit and 18-bit), and manually selecting colors via the visual picker instead of hex text boxes, but the compiler warnings persist exactly the same.

It seems the internal C/FCDX macro generation code for the PIC32 target is implicitly processing a 32-bit or larger integer where a smaller data type is expected by the component backend structure.

I am attaching the screenshot of the compiler messages. Could you please check if the SSD1963 component C template needs an update or a data type casting fix for the PIC32 toolchain?

Thank you in advance!

Rod

[Steve-Matrix]

I've had a quick look and I don't think those warnings are causing the crash.

Are the Connections properties of the display appropriate for your hardware?

[r_teixeir]

Hi Steve,Thank you for the quick look.
Yes, I have carefully verified the Connections properties in Flowcode. I must mention that my pin mapping was indeed compromised (incorrect) before, but I have now corrected it to match the hardware layout exactly.
To prove that the hardware and the physical connections are now 100% correct, I tested the board using a separate program written in direct C code, and the display initialized and worked perfectly.
To isolate the issue within Flowcode, I also completely excluded the touchscreen driver (STMPE610) from this project, focusing strictly on getting the component display driver initialized first. However, when compiling through Flowcode, the display still remains completely blank and unresponsive.
I am leaving the schematic of the board attached here for your verification, along with my .fcfx project file, so you can review the exact connection properties and configuration settings.
Could there be an issue with how the native SSD1963 component handles the initialization timing or data bus layout specifically for the PIC32 target?Best regards,
Rod

[Steve-Matrix]

Your first post talks about a "crash", which I presume is a lock-up of the PIC32 device. If this is the case, after which specific Flowcode component macro call does this happen? You can try toggling pins after each call to see if it is working ok.

If all of the Flowcode macros are returning ok, then it could be a timing issue. Are you definitely running the chip at the correct speed and is Flowcode aware of this speed? To make sure, you should confirm a 1-second flasher project with your chip configuration settings.

[r_teixeir]

Hi Steve,
I have just performed the 1-second LED blinking test exactly as you suggested, embedding it directly into the main application loop. To provide absolute proof, I monitored the pin behavior using an oscilloscope.
I am attaching the screenshot of the waveform measurement below, which shows:
Frequency: Exactly 1.0000 Hz
Period: Exactly 0.99999 s
These physical measurements definitively confirm two critical facts:
1 - The clock configuration is 100% correct: Flowcode's internal timing calculation aligns perfectly with the actual physical execution speed of the PIC32MX795F512L.
2 - The MCU does not freeze or lock up: The code executes and loops flawlessly without any physical crash or software hang, even after the SSD1963 initialization macro runs.
The program remains fully responsive, yet the display panel simply stays completely blank. Since the timing, hardware, and connection properties are now verified to be correct, what would be the best next step to investigate why the component is not initializing the display properly?
Best regards,
Rod

[Steve-Matrix]

I'm personally not familiar with this display. Maybe someone else on this forum has experience with this component and can help.

I will also check to see if anyone else in our office has a sample of this display.

[chipfryer27]

Hi

Do you have logic analyser that you could put on the associated pins to see what is being sent out?

Regards

[r_teixeir]

Hi chipfryer27 and Steve,
Unfortunately, checking the lines with a physical logic analyzer is not feasible on this specific hardware layout. The mikromedia+ for PIC32MX7 board is a highly integrated, multi-layer PCB where the entire 8/16-bit parallel data bus and control lines run directly from the MCU pins to the TFT FPC connector underneath the display panel, with no external headers or exposed test points available to hook up probes.
However, looking into the working direct C code library baseline generated for this exact board, the display initialization heavily relies on the PIC32's hardware PMP (Parallel Master Port) peripheral to communicate with the SSD1963, driving the data through the PMDIN register and checking the PMMODEbits.BUSY flag:

void Set_Index(unsigned short index) {
TFT_RS = 0;
PMDIN = index;
while(PMMODEbits.BUSY);
TFT_RS = 1;
}

Given that we verified the MCU clock is perfectly accurate via the previous oscilloscope test, it is highly likely that the native Flowcode v11 SSD1963 component is trying to drive the parallel lines via standard software GPIO bit-banging instead of initializing and routing the data through the PIC32's native hardware PMP driver, which causes the display to remain completely unresponsive.
Does the native Flowcode v11 SSD1963 component utilize the hardware PMP peripheral for PIC32 targets, or is there a specific property setting required to enable it?
Best regards,
Rod