STM32 freeRTOS data corruption when writing to sd card

benjamingraef95 wrote on Wednesday, November 27, 2019:

Hello, I am working on a project where data shall be logged onto a SD Card.
I am using a stm32 mcu with freeRTOS running on it. I use spi and the fatfs library to communicate with the sd card.

I have a own task which write the data from a circular buffer to the sd card with spi1. No other task is accessing spi1 or is doing any stuff with the sd card. The data logging works fine until some point in time, the data on the sd card gets corrupted with unreadable stuff.

see following example of sd card data:
1;3;31986;5;10;56;59;50;12204;12160;-26;1;7800;527728;-527292;9;10;9;0;150391; (good data)
õÓÃuŒÂÕq Ùý+ñaÙï+±è[Ž&Û)% !É;IdH¦L*W (bad data)
óÓ×(bad data)
1;3;26447;5;10;56;59;50;12216;12160;-26;1;7800;381132;-380813;9;10;10;0;150391; (good data)

It recovers itselfe and write correct data again. The other tasks keep running at the same time, because the functionality of the other tasks is still working. also the log data says that the internal time has increased at the time during the faulty write occured.

I tryed to figure out if any other task is disturbing during the write to the sd card, so I used taskEnterCritical() and taskExitCritical() when writing to the sd card. That did not help.
Also I checked the the circular buffer data was not the cause. This is also not the root of the problem.

Any ideas what could be wrong here.

Sometimes the error doesnt occure for days, then it occures again after 10 minutes. Sometimes is lasts over 1 hour, and writes tons of garbage data. Sometimes it lasts just for a few seconds.

Any help is appreciated.


rtel wrote on Wednesday, November 27, 2019:

Where did the SPI driver come from? Do you have confidence in it - for
example if you were using the SPI driver to access the SD card from
main() rather than from a FreeRTOS task would you be able to use the
card for days without any corruption? Fatfs (which is not our code) has
some configuration parameters that need to be set if you are using it in
a multi-threaded environment, but if you are only accessing the file
system from one task then that should not be necessary.

benjamingraef95 wrote on Thursday, November 28, 2019:

the SPI driver is from ChaN. The name is “STM32F100: MMCv3/SDv1/SDv2 (SPI mode) control module”

Basically I provide my SPI send and receiv byte functions to this module and it implements the functions which are used by the fatfs module to send data to the sd card.

I will try to let it run in main for a while and see if I can reproduce that error.

benjamingraef95 wrote on Wednesday, December 04, 2019:

Ok so I think I have found the issue. The problem was not related to freeRTOS. The implementation of my SPI send bytes function which I provide to the fatfs library was not catching errors, so if an error occured within the HAL_SPI_Transmit function, the MySPI1_SendBytes funciton would return, assuming the byte was send successfully. Now I loop until the functions returns no error. This should solve it( at least no error occured after several days of testing).

If I manually return an error from within the funciton HAL_SPI_Transmit, I could reproduce the corrupted data writ to the SD card, so I assumed that the issue was laying there.

/ SPI1 send x bytes, new implementation/
uint8_t MySPI1_SendBytes(uint8_t *data, uint16_t numBytes) {
while (HAL_SPI_GetState(&hspi1) != HAL_SPI_STATE_READY);
while(HAL_SPI_Transmit(&hspi1, data, numBytes, 500) != HAL_OK);
return 0;

/ SPI1 send x bytes, old implementation/
uint8_t MySPI1_SendBytes(uint8_t *data, uint16_t numBytes) {
while (HAL_SPI_GetState(&hspi1) != HAL_SPI_STATE_READY);
HAL_SPI_Transmit(&hspi1, data, numBytes, 500) ;
return 0;

Best regards, Benjamin

rtel wrote on Wednesday, December 04, 2019:

Thanks for taking the time to report back.

Hi Benjamin,

a word of caution from experience: Make sure to exclusively use industrial quality SD cards. Consumer products suffer from all kinds of quality problems that may cost you fortunes trying to pinpoint when attributed to software problems!

Hello @Buckridge, yes, same experience here. It is worth to pay more for your memory cards in order to get a better quality.

A second problem is that the memory cards slide into a socket. Hundreds of times I have taken out a card, cleaned its contacts and remounted it. Only then it would work again.

Some companies decide to use fixed memory cards, they can only be replaced with a soldering iron, which I think is a good solution.
If not, you are facing problems with oxidation ( rust ) and all kinds of small insects like spiders.

Does this answer your question or did you have something else in mind?