SDIO(FatFS) File open(write) problem

[Kim KyungTack]

Posted on April 03, 2018 at 05:35

Hi.

At the first time, SDIO works well but 10~20 minutes later, when i try to open a file(FA_CREATE_NEW | FA_WRITE options), there is no answer for 30 seconds and then SDIO does not work anymore after being shown FR_DISK_ERR.

Through debugging, I found that SDIO doesn't work as soon as the osMessageGet called on SD-Write function (osMessageGet result is osEventTimeout).

This problem disappears when the SDIO clock speed is lowered (ClockDiv is 8 or more). However, the Read/Write speed get very slow too much than i want.

STM32F429 use

CubeMX 4.25.0

STM32CubeF4 Firmware Package v1.21.0

FreeRTOS 9.0.0 (CMSIS 1.02)

FatFS R0.12c

SDIO Settings (DMA used)

[Tesla DeLorean]

Posted on April 03, 2018 at 15:22

Looks fairly standard. You'll perhaps need to analyze what is happening to the card. Check things like power and connectivity over time, and see if you can retry or reconnect with the card when it gets into this condition.

[Kim KyungTack]

Posted on April 04, 2018 at 05:02

Dear Clive One,

Thank you for your reply. I have been worked with Std library since two years ago.

I found this problem while i converted my project to use HAL driver.

As your say, i tried to reconnect as soon as i faced FR_DISK_ERR but HAL_SD_ERROR_TIMEOUT was happened in SD_FindSCR.

I'm sorry but i can't understand why i faced the problem when i try to write some data. There is no any problem while i read the file about 10 minutes.

Because i didn't find any problem while i have used STM32f103 (Used HAL, didn't use FreeRTOS that time), i have no idea about the way what i should do for test.Another question, I found the SD Read/Write speed is too slower than Std libray (No use DMA) even though i use HAL driver (use DMA).I'm afraid that i did wrong set with Peripheral or there is any problem with the way i use it. I'm using the default code generated by CubeMX.

It would be very appericiate it, if you would let me know what i have to pay attention to set SDIO, FreeRTOS and FatFS.

Thank you so much for your help.

++++++++++++++++++++++++++++++

About 5~ minutes later SDIO_IRQHandler is called although i do not use SDIO. And i found that HSD state is changed as above.

[peter__]

Posted on April 04, 2018 at 12:44

I experience the same problem in the same setup.

It happened after moving to the new F4 HAL 1.19.0 from 1.16.0 (a new SDIO lib was introduced).

Everything works as expected, even under high load .. until you let it sit for some time - then the SDIO bus dies on a write. The 'idle' time needed to reproduce this bug is about 3 minutes here.

Tried with different SD-cards - no impact.

Working workaround (NO THIS IS NOT AN ACCEPTABLE SOLUTION): write to the card every 30s.

EDIT: oh, and the bug does not happen during debug .. only when running freely

[Tesla DeLorean]

Posted on April 08, 2018 at 17:18

>>the bug does not happen during debug .. only when running freely

Is there code that is powering down the peripherals/pins?

Can you dump out the SDIO peripheral registers either side of the failing condition?

The SDIO peripheral viewer in the debugger can alter the peripherals behaviour, no specific DBGMCU settings related to SDIO so some other relationship occurring (TIM, PWR, etc)

Instrument the diskio layer to see failure of the read/write interaction, failure tends to cascade, neither the SDMMC/SDIO and FATFS have much in the way of error recovery or retrying.

The F4 HAL is current at 1.21.0

[peter__]

Posted on April 09, 2018 at 08:59

Thank you for the answer!

Is there code that is powering down the peripherals/pins?

No.

Can you dump out the SDIO peripheral registers either side of the failing condition?

As I mentioned, I cannot reproduce the issue during debug. So i can't read the registers..

Instrument the diskio layer to see failure of the read/write interaction, failure tends to cascade, neither the SDMMC/SDIO and FATFS have much in the way of error recovery or retrying.

The error can be pinned to an exact location in the code:

After the DMA transfer is started (HAL_SD_WriteBlocks_DMA), the related callback (HAL_SD_TxCpltCallback) never arrives. Therefore a timeout happens.

The F4 HAL is current at 1.21.0

Yes - I'm using that version. I just wanted to mention, that the bug must have been introduced with v1.19.0.

[Tesla DeLorean]

Posted on April 09, 2018 at 14:10

Your own software can read the registers and dump observed settings via USART. This can operate independently of a debugger by instrumenting the code, especially along failure paths 

[Tesla DeLorean]

Posted on April 09, 2018 at 16:46

Not aware of a specific low-power timeout on the SDIO/SDMMC interface, there is a clock enable/disable option. Suspect it might be some inactivity setting in the card, would make an interesting test case. Have seen issues closing a file after an hour, but seemed to be more of an issue with an under/over-run and 1-sector write, as other larger writes were occurring successfully every 20-30 seconds.

Externally having a scope trigger on the power pin might be an interesting experiment.

[Podkovirin.Anton]

Posted on April 11, 2018 at 17:41

I have a similar issue on the SMT32F777 with no RTOS. 

The problem occurs when trying to read from the sd card.

My configuration:

STM32F777 use

CubeMX 4.23.0

STM32CubeF7 Firmware Package v1.8.0

FatFS R0.12c.

Here are my observations:

In my case, if i'm accessing the sd card frequently(~ less than 10 minutes intervals), i can successfully open and read files. After leaving the code running without explicitly accessing the sdcard for a long duration, next time i try to access it(open a file), it fails with the FR_DISK_ERR.

When I apply a workaround where i try to open a non existing file every 10 seconds, I'm able to access the sdcard after long delays.

I noticed that during the long idle time, the 'SD_DMARxAbort' function is triggered (I'm not explicitly trying to access the sd card at this point). The function is triggered due to the

HAL_SD_ERROR_DATA_TIMEOUT  

error. The next time I try to access the SDCARD it fails. Any following attempt to open a file on the SDCARD fails. 

Tried unmounting, unlinking and disabling the power to the card and reinitialize it, but the issue persisted. I was able to access the sd card again only after a power-cycle.

[Richard I]

Posted on May 01, 2018 at 13:41

Same problem on a STM32F767 (silicon revision is 'Z'). SDIO fails after a few minutes of idle and is impossible to recover. I'm afraid this may be a silicon bug that is not in the errata (yet), because I can see on the scope that the SDCLK output signal gets stuck at high level and needs reset to recover. The clock is generated by the STM chip and during normal operation is at a continuous 24 MHz. There is no code to suspend this clock that is actually called by any existing functions - it can only be initialised. I tried HAL_SD_DeInit-ing the SD after each operation, which suspends the clock (low level) between access cycles, but the SDIO still fails after a long idle.

If anyone has managed to resolve this issue, help would be much appreciated, as this is a pretty major blocker at the moment.