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

[r_teixeir]

Hi chipfryer2 and Matrixtsl Team

Following up on my previous post, I have spent the last few days trying to bypass this limitation by developing a custom component and testing different approaches, but unfortunately, there has been no success in getting the physical display to work.

The breakdown of my tests clearly proves that Flowcode 11 is blocking my custom C code from overwriting the native bit-banging routines. I proved this by analyzing two distinct scenarios:

Scenario 1: Using only my custom component (WITHOUT Supplementary Code)
The custom component was built using "Expose to top level" on the three main macros (Initialise, LCD_Write_Reg, LCD_Write_Data), replacing their contents with custom C code targeting the physical PMP registers (PORTBbits.RB15, PMDIN, etc.). It was exported with a new GUID, macros set to "Downloadable", and "Use supplementary header code" enabled.
- Result: The simulation/animation works perfectly on the PC screen. The compilation to target also finishes successfully and generates the hexadecimal file. HOWEVER, nothing happens on the real hardware. When checking the generated .c file, I discovered that Flowcode completely ignored my custom C code and forced the generation of the default software bit-banging routines (SET_PORT_PIN sequences) at the bottom of the file anyway.

Scenario 2: Trying to bypass the limitation (WITH Supplementary Code)
To stop Flowcode from using the bit-banging routines, I tried adding macro #define steering directives or re-declarations inside the application's "Supplementary Code" window.
- Result: The simulation still works fine, but the compilation to target completely crashes, failing to generate the hexadecimal file. The XC32 compiler returns error code 0xFF (error: expected identifier or '(' before '{' token or error: redefinition). This happens because Flowcode insists on generating the native function signatures further down the file, causing a direct syntax collision with my supplementary C code.

Conclusion: In all scenarios, it is proven that the custom register-level code cannot overwrite the native component's bit-banging routines. Either Flowcode forces the bit-banging silently into the .hex (Scenario 1), or it causes a compilation collision when I try to override it (Scenario 2).

Since I am just trying to compile a simple "Hello World" application and the software structure is preventing me from using the required hardware PMP bus, what is the official way to force Flowcode 11 to completely drop or ignore the native bit-banging routines so my custom C code can take over?

If you need anything alse let me know
download/file.php?mode=view&id=12136
Best regards,
Rod

[mnfisher]

I tested this - I modified your component (slightly - gave it a new GUID changed the name) and compiled to SSD_TEST - then compiled the test program having modified it to use the new component and removed the old component. The new component moved to development - with name SSD_TEST

Have no way of testing on hardware - but it should use the write routines in your code.

Martin