SD Card File Corruption - Teensy 3.5

Hi

I have a project - DotClk - this presents an animated clock on HUB75 style LED panels. I've been fighting an issue of the SD Card corrupting for about 3 years now. I've finally put together some example code that recreates the issue.

Setup is as follows:
Teensy 3.5
120MHz standard clock speed
Compiler set at Faster
SD Card 8GB Kingston, speed rated 4

The project involves displaying a digital clock, with an animation presented at various times. The animations are on the SD Card held in binary files of my design. After some time, possibly days / weeks / months, the clock will crash - no display is shown and the teensy LED tick of the clock stops. When examining the SD Card and comparing the contents it is found that one or more of the files is corrupted.

I have put together a minimal code example to recreate the issue - the code looks unnecessarily complex but it is based on the full project which is complex. This example just accesses the SD Card with the same routines as in the original project but without any delays. When I ran this it crashed within 2 days.

The code example can be found here:
https://github.com/sigmafx/DotClk_Fault

An SD Card inserted into the teensy needs the files from the following repository:
https://github.com/sigmafx/DotClk-Resources

When the code is running, the LED on the teensy will flash at .5Hz, and when it crashes it will stop - comparing the files on SD Card against the repository will show where there are corruptions.

I have tried many things to fix this issue - adding watchdog timer, setting the low voltage comparator check, changing the SD library, different SD Cards, formatting cards differently etc, etc.

I would really appreciate any help with this issue.

Many thanks

David.
 
Which version of Teensyduino are you using? In Arduino, click Help > About to check.

1.55 is the latest. Starting with 1.54 the old Arduino SD library was replaced with SdFat and SD is now just a thin compatibility layer which actually uses SdFat for everything.

If you're using 1.53 or earlier, try updating to the latest. Maybe it won't make any difference, but it's so easy to try and indeed all the code which accesses the SD card completely changed from 1.53 to 1.54, so it's probably worth a try.
 
Have I missed something, or are these really only read accesses to the card?
Then I would try another card.
And maybe see if the voltage is stable, and maybe add a buffer capacitor.
 
Have I missed something, or are these really only read accesses to the card?
Then I would try another card.
And maybe see if the voltage is stable, and maybe add a buffer capacitor.

Yes, just file reads. So on the long list of things I tried...
Used many different SD Cards
Run the teensy from a 5V power supply, with a large capacitor across the rails.
Run the teensy standalone from the USB port of a computer
 
I have no idea how this can happen with read only accesses as long as the voltage is stable.I think I can't help there. But a Teensyduino update will hardly help. I can not imagine a software problem.
 
I have no idea how this can happen with read only accesses as long as the voltage is stable.I think I can't help there. But a Teensyduino update will hardly help. I can not imagine a software problem.

Yes, it's a difficult problem, that's why I've been at it for 3 years trying to fix :D
 
I've updated to 1.55 - I was on pre 1.53 before.

I'm also using..
#include <SD.h>
// Initialising the card with...
SD.sdfs.begin(SdioConfig(DMA_SDIO))
// Reading files with...
SdFile fileScene;
fileScene.open(pathScene, O_RDONLY);

I presume using SdFile is okay?
 
I presume using SdFile is okay?

SdFat's file object is FsFile (we're using SdFat version 2), and yes, it's ok to use it. But use SD.sdfs.open() function which gives you a FsFile which you can then use with read(), write(), println(), etc.

Code:
#include <SD.h>

void setup() {
  SD.sdfs.begin(SdioConfig(DMA_SDIO));
  FsFile fileScene;
  fileScene = SD.sdfs.open("filename.txt", O_RDONLY);
}

In Arduino, click File > Examples > SD > SdFat_Usage.
 
Last edited:
SdFat's file object is FsFile (we're using SdFat version 2), and yes, it's ok to use it. But use SD.sdfs.open() function which gives you a FsFile which you can then use with read(), write(), println(), etc.

Code:
#include <SD.h>

void setup() {
  SD.sdfs.begin(SdioConfig(DMA_SDIO));
  FsFile fileScene;
  fileScene = SD.sdfs.open("filename.txt", O_RDONLY);
}

In Arduino, click File > Examples > SD > SdFat_Usage.

I've updated the repository at...
https://github.com/sigmafx/DotClk_Fault
... to use SD and FsFile, but I still get corrupted files on the SD Card.
 
Yes, was expected.
And this really happens with new cards, too?
Could you post a schematic? How sure are you that are no voltage spikes or similar..?
 
I've updated the repository at...
https://github.com/sigmafx/DotClk_Fault
... to use SD and FsFile, but I still get corrupted files on the SD Card.

Was it ever run with a different T_3.5?

Was it run without any added hardware connected or powered to see if the corruption persists?

Is the display well grounded to the supply not through the Teensy ? { used a panel once that wouldn't USB program and when connected over an AMP was going through USB cable - needed another GND pin from display }
 
In some rare cases, corruption is also a Windows false positive. Have seen this in the past. When reinserting the card reader, the message disappeared and the card was "OK". But that didn't happen that often, and doesn't seem to be the case here. Just thought I'd mention it....
 
Was it ever run with a different T_3.5?

Was it run without any added hardware connected or powered to see if the corruption persists?

Is the display well grounded to the supply not through the Teensy ? { used a panel once that wouldn't USB program and when connected over an AMP was going through USB cable - needed another GND pin from display }

I've run it on many 3.5s > 5
My test app DotClk_Fault is running on a naked teensy plugged into the USB port of my PC.
 
In some rare cases, corruption is also a Windows false positive. Have seen this in the past. When reinserting the card reader, the message disappeared and the card was "OK". But that didn't happen that often, and doesn't seem to be the case here. Just thought I'd mention it....

I use Windows command line 'fc' to compare the files on the SD Card and the files in my local copy of the repo DotClk_Resources. I do this after the teensy has crashed - the led will flash a heart beat, but after ~24 hours this stops so I know it has crashed.

Code:
fc /B Scenes\* G:\Scenes\* > verify.txt
echo %ERRORLEVEL% >> verify.txt
 
I have been running the original version of the code (with slight mods) on a Teensy 3.6 and a Teensy 3.2. I have a T3.5 but unfortunately it's busy right now.
The T3.6 has been running non-stop for 7 days and the T3.2 for 6 days. They both use the uSD card on an audio board.
If the problem was something to do with software, such as a memory leak in a library, it should have crashed the T3.2 very quickly because it only has 64kB of ram.
At first I thought the problem might be something to do with the use of realloc but I tested that and satisfied myself that malloc/realloc work just fine.
So, I'm left with either this is something very specific to the T3.5 or it's a hardware/software problem at the user's end.

Pete
 
I have been running the original version of the code (with slight mods) on a Teensy 3.6 and a Teensy 3.2. I have a T3.5 but unfortunately it's busy right now.
The T3.6 has been running non-stop for 7 days and the T3.2 for 6 days. They both use the uSD card on an audio board.
If the problem was something to do with software, such as a memory leak in a library, it should have crashed the T3.2 very quickly because it only has 64kB of ram.
At first I thought the problem might be something to do with the use of realloc but I tested that and satisfied myself that malloc/realloc work just fine.
So, I'm left with either this is something very specific to the T3.5 or it's a hardware/software problem at the user's end.

Pete

Pete

Thanks for your efforts with this. Can I check that you copied the files to the SD Card from the github repo as described in my original post? Also, I'm using the SD Card built into the teensy.

I've been tinkering with this for a few days now and have found that if I allocate the SD object on the heap (use new and store the returned pointer) rather than using the global SD then it doesn't crash. That isn't the whole story, I also delete and new the object each time the file is closed. This is either masking a software problem by refreshing the SD object, or there is a problem with SD on the teensy 3.5 / 3.6??

When I've done a bit more work I'll update the repo with the code changes.
 
I've checked the two uSD cards, and their contents are identical to the original Scenes directory.
I'll try your newer version on just the T3.6 with the builtin uSD this time.

Pete
 
Back
Top