STM32U5G9 / U5F9 LTDC: Display fails when HSPI1 disabled (HSPI not used for assets)

[JH56]

Hi everyone,

I'm experiencing a very specific bus/clock issue on a custom board using the STM32U5G9ZJ (and also tested on STM32U5F9ZJ).

The Problem: My display (320x240, RGB565 via LTDC) only works if the HSPI1 peripheral is enabled in CubeMX. As soon as I disable HSPI1 (which I need to do to free the PH9 pin for power management reasons), the screen turns grey, even though the LTDC settings remain unchanged.

Key Technical Details:

• Data Location: All assets (images/fonts) are stored in Internal Flash memory. The HSPI/OctoSPI bus is NOT used during the display process.

• Memory Status: In Debug mode, I can confirm via the Memory Browser that the Frame Buffer (located at 0x20025800) is correctly populated with pixel data.

• LTDC Behavior: Despite the RAM being correct, the LTDC fails to output data to the panel when HSPI1 is OFF.

• Configuration: Pixel Clock (PLL3R) is at 200MHz, GPIOs are "Very High Speed", and the Frame Buffer is placed to avoid conflicts with the RTOS (ThreadX) heap.

The Mystery: Why does the LTDC depend on the HSPI1 state to fetch data from internal SRAM?

• Is there a Clock Gating issue where disabling HSPI1 also kills the AHB/APB bridge used by the LTDC Master?

• Does the Bus Matrix on the U5G9/F9 require an active memory controller to maintain high-speed arbitration for the LTDC?

• Is there a specific Power Domain (VDD_CORE or similar) that scales down when HSPI is disabled, preventing the LTDC from reaching its target bandwidth?

I need to free PH9, but I cannot lose the display. Has anyone encountered this "ghost dependency" between OctoSPI and LTDC on the U5 series?

Environment:

• MCU: STM32U5G9ZJ / STM32U5F9ZJ

• OS: FREERTOS (ThreadX)

• Graphics: LVGL 9

Thanks for your help!

[mƎALLEm]

Hello @JH56 and welcome to the ST communiuty,

---

• Data Location: All assets (images/fonts) are stored in Internal Flash memory. The HSPI/OctoSPI bus is NOT used during the display process.

---

Based on what you have described you need to check again if all the assets are really located in the internal flash memory. Check again your linker file, check your source files where the assets are declared (it may be something forced asset(s) location to the HSPI).

[JH56]

Thank you for the suggestion, but I have ruled out the assets issue. I am testing with a raw memory fill directly in my task :

uint16_t *framebuffer = (uint16_t *)0x20025800;
for (int i = 0; i < (320 * 240); i++)
{
  framebuffer[i] = 0x001F; // Solid Blue
}

The behavior is still identical:

• HSPI Enabled: Screen shows Blue.

• HSPI Disabled: Screen is Grey.

There are no assets involved in this test .

[mƎALLEm]

To me that doesn't make sense!

From architectural stand point, there is no dependency between the enable of external memories (over FMC, xSPI etc..) and the LTDC function except LTDC is fetching from that external memory. There is no known limitation on U5 product related to your behavior.

[MM..1]

You show test , but nothink about init init order etc. How you disable HSPI in MX or call deinit ...? How version of MX used. Seems as some HAL bug... Your realy debug your code, isnt Grey in hardfault ...?

[mathiasmarkussen]

Are you sure there is no code in your project to memory map the HSPI?

Why is your pixel clock at 200 MHz  for a 320x240 display? That seems about an order of magnitude too high to me. Do you have a data sheet for the display controller?