Data corruption when using D-Cache on STM32F7508-DK

[DRobe.4]

I have an unsophisticated system. RAM/Flash internal to the F750. Running perfectly at 200 MHz, many UARTs and other peripherals, displaying data/status on LCD screen. Compiled with Keil free uVision V5.27.1.0 with no errors and no warnings.

Enabled I/D-Cache. Some data (displayed near bottom of screen, in case it matters) was corrupted. Disabled D-Cache and problem disappears. Re-enable D-Cache problem reappears. I-Cache enable/disable has no effect on the problem. Any suggestion how to avoid the problem? Is there a way of increasing the level of array checking, etc. in case my coding is to blame?

[Tesla DeLorean]

Do you configure the MMU for memory shared with DMA or LTDC?

Do you commit writes to the frame buffer with Clean DCache​ by Address?

[DRobe.4]

I do not use MMU or DMA. I have not heard of "Clean DCache" but I have not see any references to it when I have consulted claimed-working STM32Cube_FW_F7_V1.14.0 examples. I am doing nothing exotic. If the Cube code works, so should mine, since I have taken a conservative approach to building a robust system. Lots of interrupts but no DMA. What do you recommend?

[DRobe.4]

Oops... I should have said that code that I've written do not use DMA, but BSP functions supporting the LTDC probably use DMA.

[berendi]

LTDC is reading pixel data from framebuffer memory, so the framebuffer should be treated just like a DMA transmit buffer, even if there is no DMA/DMA2D/MDMA access in BSP or elsewhere.

You should either disable write-back caching on the framebuffer through the MMU, or clean it from DCache after each frame update.

Do not ever assume that BSP or HAL functions are implemented correctly. What is correct anyway? They are barely documented so everyone has a somewhat different opinion on what they are supposed to do. There is no guarantee whatsoever that they would work outside the example projects.

[Tesla DeLorean]

  /*

  the SCB_CleanDCache_by_Addr() requires a 32-Byte aligned address

  adjust the address and the D-Cache size to clean accordingly.

  */

  alignedAddr = (uint32_t)buff & ~0x1F;

  SCB_CleanDCache_by_Addr((uint32_t*)alignedAddr, count*BLOCKSIZE + ((uint32_t)buff - alignedAddr));

[DRobe.4]

Thanks for this help. I also found dm00272913, but it doesn't really tell me when to perform these clean/invalidate operations (once per second, after every DMA to LTDC, whenever the framebuffer is changed,.....?). If I really understood the cause of the problem, perhaps I could figure out when to clean the cache. Just to make the process even longer and more painful, if I must clean the D-Cache after some operation is performed in a BSP function, I might need to understand the detailed operation of the BSP functions.... has anyone done this before and posted their changes to the BSP functions on the web?

Thanks,

[DRobe.4]

I have been trying out things like cleaning/invalidating the whole cache at certain points in my code (BUT not within the BSP functions).... no effect.

Then I tried something that worked... for me at least. This post may help others that encounter similar issues.

1. only certain lines on my display are corrupted, always the same 2 lines, the rest of the display (and data producing the results on the display, I presume) are always uncorrupted.
2. the two lines that are corrupted are written by one function. I cannot delete that function without impairing the capability of the whole project.
3. I disable the D-Cache just before calling the function mentioned in step 2. I re-enable the D-Cache just after the call to that function.
4. the problem disappears. The only negative impact is that the function in step 2 takes longer to execute. I display the msec that the whole code takes and it is vastly improved by using D-Cache as well as I-Cache, but slightly degraded by the disabling of D-Cache within the function in step 2.
5. I'm happy with this workaround. I will keep my eyes peeled for data corruption that may pop up as development continues.