cancel
Showing results for 
Search instead for 
Did you mean: 

Data corruption on SD card when using SPI for data transfer.

benjamin Gräf
Associate II

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 Ùý+ñ Ùï+ ±è[Ž&Û)% !É;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.

The SPI driver I am using is from ChaN. The name is "STM32F100: MMCv3/SDv1/SDv2 (SPI mode) control module"

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

Any help is appreciated.

Benjamin

2 REPLIES 2
Danish1
Lead II
  1. How strongly do you know that the data in the circular buffer is consistently good? Is it (for example) numbers that you generate on the stm32 and then convert to ascii inside the stm32?
  2. How large do you allow a file to grow? Will it be the same file used over several days?
  3. How do you send your data from the circular buffer to the fatfs library? For example, do you open a file, seek to the end of it and then write a character before closing the file?
  4. How long are the wires from the stm32 to the SD-card? Do you have access to an oscilloscope to verify that the waveform is nice and crisp with little ringing when doing both reads and writes?
  5. Have you tried changing the SPI clock rate e.g. slowing it down by a factor of 2?
  6. For a short sequence of bad data, if you shift it by a whole number of bits does it then look credible?

Answering these questions should help us narrow down the problem.

Any FAT-based system will be more efficient if you write in units that are a multiple of the sector size (i.e. 512 bytes) than writing just a few bytes a time. To add data to a partially-written sector, the fatfs library has to read in the current contents of the sector, add what you are writing and then write back the sector, so corruption might occur on reads or writes.

For SPI it is vitally important that you trigger on the correct edge of the waveform. If you have inverting buffers the code must be changed to suit.

Regards,

Danish

KnarfB
Principal III

some more thoughts

  1. is the SD card + power supply reliable, see https://community.st.com/s/question/0D50X00009XkhmDSAR/sd-card-damage-after-writing-datasolved
  2. Is the data in the ring buffer corrupted?
    1. check with isprint() or such before writing to SD
    2. write synthetic data instead of buffer data to exclude overwritten memory
  3. an external adapter like sparkfun microsd card sniffer may help detecting electrical issues (but may also introduce some at high speeds)

hth

KnarfB