STM32H7 buffer underrun and speculative reads

[PaulMoosman]

We have Cortex-M7 STM32H7 (STM32H753) system and we are experiencing buffer underrun.

We have read application note AN4861 which describes issues that can cause buffer underrun. I think we have implemented all the recommendations in AN4861, however, we are still seeing buffer underrun.

Our display is 480x272 24bpp (RGB888).

We are using two framebuffers located in FMC controlled SDRAM. One framebuffer in bank 3 and the other in bank 4.

We set the buffer pitch to be 512 to ensure 1-Kbyte boundary for LTDC burst read.

We set the pixel clock to be 8 MHz (the lowest value recommended by the LCD manufacturer).

We are currently only using 1-layer.

We have also configured MPU regions for memory regions disabling execution.

The application note talks about speculative read potentially causing buffer underrun issue. How can I tell if my buffer underrun errors are cause by speculative reads? Is there anyway to tell which memory regions are being accessed by the bus when the buffer underrun occurs?

We don't always see buffer underruns. Seemly unrelated code can cause the buffer underrun issue to appear and disappear.

Disabling the DCache seems to make the buffer underrun issue go away. e.g. SCB_DisableDCache();

If disabling the DCache makes the buffer underrun go away, does that mean our buffer underrun is likely caused by speculative reads?

Do you recommend turning off the DCache to prevent speculative read buffer underruns?

Can both DCache and ICache speculative reads cause buffer underrun? If so, do you recommend turning off both DCache and ICache?

In order to prevent speculative DCache reads to memory region, my understanding is that we need to set the following MPU attribute:

MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;

Correct?

When we set MPU_ACCESS_NOT_CACHEABLE to a memory region with unaligned static variables, we get a hard fault. (HardFault_Handler() is called). Is this expected? If we turn off caching, do we need to align all static variable accesses?

Any other suggestions or recommendations?

[Piranha]

Buffer underruns are not directly related to speculative reads. It seems that either you are using the word "underrun" wrongly or are misunderstand something in general. How do you detect the "underrun" here? Also what do you mean by "pitch" respective to the buffer - size, alignment or something else?

As for cache maintenance in general, read this:

https://community.st.com/t5/stm32-mcus-products/maintaining-cpu-data-cache-coherence-for-dma-buffers/m-p/95746

P.S. And what's with that "almost every sentence is a paragraph" style? Why don't you write it as a normal text?

[PaulMoosman]

By buffer underrun, I'm referring to the LTDC global error interrupt "FIFO underrun". Pitch is the distance between the start of one line and the beginning of the next line in bytes in the framebuffer.

[FBL]

Hello @PaulMoosman 

You can monitor the bus activity and see which memory regions are being accessed when the buffer underrun occurs. This can help you identify any potential issues with speculative reads.

Speculative reads can cause cache misses leading to buffer underrun. Disabling the data cache can help prevent speculative read buffer underruns, but it can also impact performance.

Also, it is possible that it is linked to insufficient bandwidth or incorrect configuration of the LTDC or SDRAM.

Do you see any missing or corrupted pixels?

[PaulMoosman]

@FBL Thanks for your response.

| You can monitor the bus activity and see which memory regions are being accessed when the buffer underrun occurs. This can help you identify any potential issues with speculative reads.

How would I monitor the bus activity? Are there registers I can check?

| Also, it is possible that it is linked to insufficient bandwidth 

It is possible. However, I experimented by turning most other tasks running. But we still see buffer underrun.

| or incorrect configuration of the LTDC or SDRAM.

It is possible that there is a configuration problem with the LTDC or SDRAM. I reviewed those setting and I don't see any problems. Is there a particular setting that we should double-check?

We have tried many different things trying to prevent buffer underrun. Often changes seem successful, then, later on unrelated code changes seem to cause buffer underrun to re-appear. My hope is that we could somehow monitor the bus to see what is causing the buffer underrun in order to prevent it. My guess is that speculative reads are causing the underrun. The only solution I see is to turn off the DCache and potentially the ICache.

[PaulMoosman]

@F.Belaid Thanks for your response.

| You can monitor the bus activity and see which memory regions are being accessed when the buffer underrun occurs. This can help you identify any potential issues with speculative reads.

How would I monitor the bus activity? Are there registers I can check?

[Piranha]

Take a note that speculative accesses are not related to the cache and cannot be disabled:

https://community.st.com/t5/stm32-mcus-products/m7-speculative-access-vs-cache/td-p/131916

Also setting memory as non-cacheable is not enough to stop speculative accesses - it must be configured as a device or strongly-ordered memory type. Have you read AN4838 and AN4839? How exactly have you configured the MPU?

[PaulMoosman]

@Piranha Thanks for your response. I have read the application notes you mention and I have read the community post you reference. However, I will take another look at them and see if I missed anything.

I configured the FMC and QuadSPI regions as strongly ordered. I did not however, configure the AXI SRAM nor the SRAM as strongly ordered.

The MPU setting we used are in the attached mpu_regions.c

My assumption is that we are getting fifo underrun errors because the CPU is keeping the bus busy doing speculative reads filling the DCache. So, if I turn off the DCache, the CPU will not try and fill the DCache.

Any thoughts or recommendations are appreciated.

[Piranha]

Disabling cache will of course avoid cache line filling and make those reads shorter, but, as I said, it cannot avoid speculative accesses as such. In MPU you have configured as strongly ordered only the address ranges of your memories, but the CPU doesn't care whether the address range has an actual memory device behind it or not. Therefore one has to configure the whole address ranges and it can be done with a single MPU region by using sub-regions. And then, after you've got that correct, add an additional higher priority MPU region with a size exactly for your actual memory, which changes back memory type to normal and enables buffering and caching as necessary.

FMC bank 1 is enabled by default - I don't know whether it changes anything, but, in case it does, have you disabled it?

[PaulMoosman · Accepted solution]

@Piranha Thanks for your reply.

We are currently only using 8MB of the FMC address space. We are only using 8MB of FMC SDRAM Bank #1. I created FMC MPU regions disabling access to regions we are not using. This seems to have fixed our LTDC fifo underrun problem.

Attached is the MPU settings (mpu_regions.2.c)

Thanks again for your suggestions.