Read From SD Card gets stuck in a While-Loop (Bug?)

[SPfis.1]

I am working on a custom board equipped with an STM32H753 and a SD-Card connected via SDMMC 4bit wide Bus. FreeRTOS is used. HAL is generated using CubeMX and the package "STM32Cube FW_H7 V1.9.1".

CubeMX generates the file sd_diskio.c and in it (line 214) the following code is found:

if(BSP_SD_ReadBlocks_DMA((uint32_t*)buff,
                             (uint32_t) (sector),
                             count) == MSD_OK)
    {
      ReadStatus = 0;
      /* Wait that the reading process is completed or a timeout occurs */
      timeout = HAL_GetTick();
      while((ReadStatus == 0) && ((HAL_GetTick() - timeout) < SD_TIMEOUT))
      {
        // HERE WE TIMEOUT
      }
      /* in case of a timeout return error */
      if (ReadStatus == 0)
      {
        res = RES_ERROR;
      }

After several read calls it suddenly stalls in this while loop (at "HERE WE TIMEOUT"). My guess is that in some cases it can happen that the DMA interrupt returns to set the "ReadStatus" before the line "ReadStatus = 0;" is reached (line 5 in snippet).

To fix it I moved the line "ReadStatus = 0;" above the DMA call like this:

ReadStatus = 0;
    if(BSP_SD_ReadBlocks_DMA((uint32_t*)buff,
                             (uint32_t) (sector),
                             count) == MSD_OK)
    {
      /* Wait that the reading process is completed or a timeout occurs */
      timeout = HAL_GetTick();
      while((ReadStatus == 0) && ((HAL_GetTick() - timeout) < SD_TIMEOUT))
      {
        // HERE WE TIMEOUT
      }
      /* in case of a timeout return error */
      if (ReadStatus == 0)
      {
        res = RES_ERROR;
      }

That solved the issue for me. Does Anybody else have that issue? Is it solved that way? does it create new problems?

[Rookie38]

I already noticed this line in a negative way when I was debugging step by step. I also packed the Complete Callback variable before the DMA call and can report that it worked reliably when writing 2 GB of data spread over 12 hours.

[Tesla DeLorean]

Yes, is a potential race condition if HAL DMA code blocks until completion, like you're debugging it​ and causing significant delay with it waiting at the keyboard or printing telemetry. Or in other interrupts or task switch. In a more normative sense you should have thousands of machine cycles of margin.

Still safer to clear prior.​

[Amel NASRI]

Hi @SPfis.1​ ,

I tracked this issue internally. The fix you suggested is already applied in STM32CubeH7/sd_diskio_dma_template_bspv2.c. But it seems that STM32CubeMX is using STM32CubeH7/sd_diskio_dma_template_bspv1.c to generate sd_diskio.c.

Internal ticket number: 133209 (This is an internal tracking number and is not accessible or usable by customers).

-Amel

[SPfis.1]

Hi @Amel NASRI​ ,

If this ticket is not yet closed, maybe you could also add a fix I documented in the ticket: "FATFS f_open fails when data cache is enabled"

( https://community.st.com/s/question/0D53W00001lpxbASAQ/fatfs-fopen-fails-when-data-cache-is-enabled )