2022-03-10 12:49 PM
Reading blocks from a SD card often result in corrupted data if IDMA and CPU Data Cache are enabled. I am not sure if this falls under erratum 2.1.1 of STM32H753xI. Attached are the STM32Cube project and modified main I used to run tests.
The code in the main reads alternatively the first and second blocks of the SD card and resets the read buffer to 0x55 as a sanity check to verify that internal memory is written. In my test, the connected SD card had a valid FAT32 file system so I knew what data should be read.
Using HAL_SD_ReadBlocks_DMA() to read a block always results in corrupted data while CPU DCACHE is enabled. There is however no corruption if either reading blocks using HAL_SD_ReadBlocks_DMA() when CPU DCACHE is disabled (commenting SCB_EnableDCache() in main.c) or if using HAL_SD_ReadBlocks_IT() / HAL_SD_ReadBlocks() when CPU DCACHE is enabled.
I first encountered this issue in another code base I am working on where it is desired to have CPU DCACHE enabled and use SDMMC IDMA. Is this a real issue or am I missing something?
2022-03-10 01:03 PM
>>Is this a real issue or am I missing something?
Cache coherency is a real problem, that *you* have to manage.
You can do it from the MPU configuration.
You can do it with DCache Clean / Invalidate by Address functions.
Perhaps some examples in the FatFs DISKIO DMA code, see
STM32Cube_FW_F7_V1.16.0\Middlewares\Third_Party\FatFs\src\drivers\sd_diskio_dma_template_bspv1.c
#define ENABLE_SD_DMA_CACHE_MAINTENANCE 1
2022-03-11 02:48 AM
Hello,
Indeed, this is a data cache coherency issue.
We suggest you to read the AN4839 "Level 1 cache on STM32F7 Series and STM32H7 Series"
2022-03-11 04:26 AM
Thanks for the info.