TouchGFX Double Buffer LTDC Causes Hardfault

[Dfarr.1]

After enabling double buffering my custom system suffers a single hardfault each time its power cycled. After a software reset NVIC_SystemReset() the system functions normally until the next power cycle.

CFSR and HFSR show a FORCED UNALIGNED hardfault, which isn't super helpful.

Config:

CubeMX>MultiMedia>LTDC>Layer 0 Settings>Frame Buffer Start Address>0xC0000000

CubeMX>SoftwarePacks>TouchGFX>Display>Start Address 0cC0000000

CubeMX>SoftwarePacks>TouchGFX>Display>Start Address2 0xC0400000

The hardfault occurs only once each power cycle. When LTDC IRQ handler fires after the first call to touchGFX>flushFrameBuffer().

I'm not sure what information would be helpful here. Is there something I'm missing in my config?

[Romain DIELEMAN]

Hi,

Just to be 100% sure 😅 have you set the first address to 0xC000000 and not 0cC0000000 ?

You only face the hardfault when using a double framebuffer or for all framebuffer strategies ? When you run with a single framebuffer can you see anything transferred to the 0xC040000 address and above ?

Did you base your project and configuration on an application template for one of the ST development kit available in TouchGFX Designer ?

Could you maybe share your TouchGFXHAL and TouchGFXGeneratedHAL files ?

/Romain

[Dfarr.1]

Yes I used "x" that was a typo when creating my post. Good catch.

I only see the hardfault when double buffering is enabled in software packs. Single buffering at 0xC0000000 works fine.

And remember the hardfault only happens 1 single time after a power cycle. Not continually.

Its a custom project started from scratch. But we did make a lot of hardware choices that match the DISCO board we started with, so the project has similarities too.

In single-buffer mode I do see a smattering of values written throughout the 0xC0400000 space. It kind of looks random. But running a couple of times with power cycles in between shows that the values and their locations are repeatable.

I see similar "noise values" in a significant chunk of the lower addresses of the 0xC0000000 buffer, which looks like most of the pixel data is packed toward the end of the buffer. But I'm not really sure what it should look like though.

Which files do you want to see?

• TouchGFXGeneratedHAL.hpp
• TouchGFXGeneratedHAL.cpp
• TouchGFXHAL.hpp
• TouchGFXHAL.cpp

[Dfarr.1]

This is what my memory address space looks like (attached).

I've calculated how large my frameBuffer should be (320x240x24bpp/8 = 0x38400 bytes). There seem to be very large blocks of additional data appended to this raw pixel data (see ?? chunks in address space diagram). What is this additional information? Its HUGE.

I'm also noticing a single byte overlap at the end of my second framebuffer. So rather than ending at 0xC07FFFFF, there's a single byte being written into 0xC0800000.

This might explain my UNALIGNED hardfault. But it doesn't explain why it goes away after firing once. The memory misalignment persists, but the hardfaults don't keep happening.

Am I on to something here?

[Dfarr.1]

Tried a few variations on the external memory scheme:

• Single buffer located at 0xC0000000 works fine.
• Single buffer located at 0xC0400000 works fine.
• Double buffers located at 0xC0000000 and 0xC0400000 functions, but suffers 1 hardfault after each power cycle.
• Double buffers located at 0xC0000000 and 0xC0038400 functions, but suffers 1 hardfault after each power cycle.
• Double buffers located at 0xC0400000 and 0xC0000000 (swapped addr 1 and 2) functions, but suffers 1 hardfault after each power cycle.

Also found this bug which seems to be relevant:

https://developer.arm.com/documentation/ka002886/latest

Still reading through it.

[Dfarr.1]

I implemented the recommended MPU solution from that article. But my problem persists. Which suggests the UNALIGNED fault might not actually be happening in external SDRAM, but rather somewhere else as a result of enabling the double buffer.