Associate III

Question

SDIO(FatFS) File open(write) problem

Forum|Forum|8 years ago
April 3, 2018
8 replies
15051 views

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)

This topic has been closed for replies.

Tesla DeLorean

Guru

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.

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..

Kim KyungTackAuthor

Associate III

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__

Associate

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

Guru

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

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..

peter__

Associate

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.

Podkovirin.Anton

Associate II

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

Visitor II

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.

Tesla DeLorean

Guru

Posted on May 01, 2018 at 19:19

Running a F767ZI-NUCLEO (Rev A) with a 4-bit SDMMC implementation, STM32CubeF7 Firmware Package v1.9.0, not using CubeMX

I implemented a dwell test where it opens a file, adds a line, and closes, and then spins doing nothing for periods incrementing at 10 minute intervals.

Writing new line to DWELLLOG.TXT...

Waiting 0 minutes..Writing new line to DWELLLOG.TXT...

Waiting 10 minutes..Writing new line to DWELLLOG.TXT...

Waiting 20 minutes..Writing new line to DWELLLOG.TXT...

Waiting 30 minutes..Writing new line to DWELLLOG.TXT...

Waiting 40 minutes..Writing new line to DWELLLOG.TXT...

Waiting 50 minutes..Writing new line to DWELLLOG.TXT...

Doing a 60 minute wait currently, pretty confident this will run as long as I let it. Checks FATFS error results on all commands, and data written returned from f_write()

Will try and find a Z, everyone feel free to support my work...

Got a bunch of F746G-DISCO and F769I-DISCO running dataloggers for weeks on end.

Provide break down of SDMMC (w/Card Detect GPIO), USART, LED, HSE for these custom boards, I'll create a test build. If you think there are silicon issues ST will expect you to provide clear and convincing evidence and software that demonstrates the failure minimally.

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..

DShin

Visitor II

I had a lot of trouble with the same problem. But I do not understand. I still do not have the skills to understand it.

Could you share the modified source?

developer2

Senior

Hi guys,

i'm not on time but i would like to share my experience ...

i used examples from ST's STM32 Cube package for STM32F4 version 1.24.0

i have same issue ... after 3 minutes i can't read any sector from SD card,

i used DMA access ...

i have workaround but it's not very fast ... steps:

first - reduce timeout value on rough calculation - it does not need to be 30 seconds, for example if my successful block transfer takes less than 1ms then i could set timeout 30 milliseconds - depends on clocking of peripheral ...
on timeout procedure do HAL_SD_DeInit()
then __HAL_RCC_SDIO_CLK_ENABLE(); __HAL_RCC_SDIO_FORCE_RESET(); __HAL_RCC_SDIO_RELEASE_RESET();
and then HAL_SD_Init();

finally it will need timeout 30ms but after peripheral restart it will come up with correct results ... this delay is acceptable for me ...

without reseting peripheral SDIO looks like it's frozen ... after 3 minutes, something like internal counter overflow - on overflow peripheral freezes ...

if somebody will write "idle" lines into text file on SD card then fragmentation on filesystem will happen ...

if you have some testcases i can try, please write ... i don't have any JTAG or debug devices ... i will try without debugging devices ...

Kind regards,

Tesla DeLorean

Guru

Standard board or something custom? USART and pins usable for diagnostic output? Which?

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..

developer2

Senior

USART2 with DMA and a lot of circular buffering - no delays for waiting flushing through USART ... flushing buffers from main cycle ...

standard boards mostly include debug support ... and i didn't use any standard board all the time i'm working with STM32F1/F4

and on my board i'm using HSE 12MHz

developer2

Senior

after additional investigation and testing i found that there is register DTIMER, and for each transfer is initialized with constant : SDMMC_DATATIMEOUT , value: 0xFFFFFFFFU

which means (2^32 - 1) / 48MHz = 89.5 -> 89.5 * 2 = 179seconds = 3 minutes ...

after deducting DTIMER register to zero SDIO is raising interrupt DTIMEOUT ... and this interrupt is processed as "Data Transfer abort" in IRQ Handler ... even if there is no transfer in progress ...

so probably developers in ST forgot to handle DTIMER register after successful transfer ... which cause Aborting transfer that already finished before 179seconds ...

if this message is read by ST's develpers , then please fix the bug in HAL ...

Kind regards,

maciek

Associate III

Hi @developer2 !

Have you managed to make any workaround?

Evgeniy Vasyliev

Associate III

@Kim KyungTack, I am facing exactly the same problem as you describe in start of this post, I am getting lost on how to solve it. Did you solve it during this period (I see that you wrote this question more than a year ago). If there is any solution with it - please let me know. Thank you.