Issue Using Internal 4.2MB SRAM (0x34000000) as LTDC Framebuffer – RGB Signals Inactive

[Shivani]

Dear ST Support Team,

I am currently working with the STM32N657X0H3 microcontroller.

We are attempting to use the internal 4.2 MB continuous SRAM (starting at address 0x34000000) as the framebuffer for LTDC.

The procedure followed is:

• Writing pixel data into internal SRAM at 0x34000000
• Configuring LTDC_Layer1->CFBAR with the same framebuffer address
• Enabling LTDC and RGB output

However, when using the internal SRAM (0x34000000) as the framebuffer, the RGB output signals remain inactive.

When we configure the framebuffer in DTCM memory (as mentioned in the reference manual), the RGB signals become active and function as expected.
However, the DTCM memory size is very small and not sufficient to hold a full framebuffer for our display resolution. Therefore, using DTCM is not a practical solution for our application.

We have verified the following:

• AXI read/write test passes successfully
• Framebuffer base address is correctly configured
• LTDC timing configuration is correct
• RGB pin configuration is verified
• No bus faults are observed

We would like guidance on the following:

1. How should the internal 4.2 MB continuous SRAM be configured to be accessible by LTDC?

2. What MPU attributes (cacheable, bufferable, shareable) are recommended for LTDC framebuffer memory?

3. Are there any AXI/AHB bus matrix or domain clock requirements for LTDC access to this SRAM region?

4. Are there any restrictions preventing LTDC from accessing 0x34000000?

We have attached the relevant initialization code and configuration files for your reference.

Kindly provide your guidance on how to correctly configure the internal SRAM to enable active RGB signals.

Best regards,
Shivani Elavena

[MM..1]

Are you sure. 0x34000000 is secure memory = usable only for secure peripherals. You dont write word about TZ.

For unsecure/normal memory use 0x24... And offcourse only same bus connected area is usable.

[Shivani]

Hi @MM..1,

We have re-tested using the non-secure SRAM region starting at 0x24000000, as suggested.

However, even after placing the buffer in 0x24000000 (AXI SRAM – non-secure), the issue still persists.

Observations:

• CPU read/write access to 0x24000000 is working correctly (verified via debugger).

• The peripheral still does not operate as expected.

• The RGB signals remain inactive when writing data into this memory region.

• This behaviour is identical to what we observed earlier.

Could you please clarify:

1. Whether AXI SRAM at 0x24000000 requires any other additional configuration for peripheral access?

2. If this peripheral has bus domain restrictions that prevent access to AXI SRAM?

3. If this peripheral supports AXI SRAM access at all, or if it must use a different SRAM region (e.g., D2/D3 SRAM)?

Thanks & Regards,
Shivani E

[MM..1]

Open reference manual and will see, that 0x24000000 isnt right start addr...

[ANJS]

Hello!
LTDC is a non RIF-aware AXI master. To have it access the secure or non-secure AXISRAM1, you need to configure its security attributes (CID, security, privilege) in the RIMU.
AXISRAM1 also have the RISAF firewall that filtering access according security attribute (CID, security, privilege).
Both need to be aligned.
Best regards
anjs