Continuous LTDC FIFO underruns after >2 weeks of operation

[inojosh]

• STM32H753 @ 480MHz
• 32bit SDRAM @ 125MHz
• LTDC clock @ 40.8MHz, 800x480 display, RGB565

I increment a counter in the LTDC error interrupt when there is a FIFO underrun.

That value will be 0 for >2 weeks. Then, one day, it will thousands of times every second. And of course, the display is erratic, glitchy, completely messed up.

This is pretty reproducible as well. When I reboot the hardware, it will run for 18 days or something without issue, and then it happens again.

I am at my wits end with this one... anyone have any clue whatsoever as to what could be happening here?

[waclawek.jan]

Well, something eats up the SDRAM bandwidth, so find out, what.

Heap in SDRAM? Continuous free memory in it runs out after x days? Changing heap size makes any difference?

Some graphics library writes to SDRAM? Goes astray after x days? Any clue from that library aithors how to monitor or suspend?

Do you DMA into SDRAM? DMA2D perhaps? Any problem with that?

It's your program, only you know the details so it's your call. 

JW

 

[inojosh]

Thanks for throwing out some ideas on this.

It may be my program, but it isn't my chip. I can't imagine what my application is doing after 18 days of running that suddenly changes SDRAM access patterns so drastically as to cause thousands of LTDC FIFO underruns per second.

There are some heap type memories in SDRAM - in this case, they aren't actively being used (that memory is only used in certain circumstances, of which aren't happening in this long running test unit to catch this problem).

LVGL (GUI/graphics library) does indeed write to SDRAM for the display buffers. But this is happening all the time, and isn't causing any issues for the days/weeks leading up to the problem. I can tell that the buffers are still being updated "normally"; the glitches on the display are related to the underruns rather than the library writing to the wrong addresses or something like that.

Not using DMA2D.

[TDK]

There's no 18-day doomsday clock on the chip. Probably not going to get a resolution looking there.

How close are you to exceeding bandwidth on the chip? If you overclock an interface by 20% does it still keep up? Are you using FIFO buffers to reduce bandwidth? The more you can show the more likely something will be spotted.

If it happens repeatably at an exact time since reset, that could provide a clue.

[waclawek.jan]

> I can't imagine what my application is doing after 18 days of running 

As I've hinted above: dynamic memory allocation fragments up to the point where some mechanism attempting to collect data kicks in.

> LVGL

LVGL has its own dynamic memory allocator. Investigate.

JW