Hello
In my project, I am writing data from an accelerometer on a SD card. The first like 15 times it worked perfectly during the whole duration of the test (around 100 seconds). All of the sudden the program fails to open the card at some point during the test. Randomly, not always at the same time.
I don't know what the issue could be but I need it fixed, especially when future test will take a lot longer.
HARDWARE Info:
SOFTWARE Info:
- I use the SD library
- The card is the only device on the bus
- Sampling time 25ms. I don't think too fast for the program
if (micros () - last_us > PERIOD) // PERIOD = 25000... so 25ms
{
last_us += PERIOD;
- Initializing. Works every time
while (!Serial) {
}
Serial.print("Initializing SD card...");
if (!SD.begin(CS_PIN)) {
Serial.println("Card failed, or not present");
// don't do anything more:
while (1);
}
Serial.println("card initialized.");
- Writing on Card part. The value written on the card is a float
myFileAcc = SD.open("example.txt", FILE_WRITE);
if (myFileAcc)
{
myFileAcc.println(accelBuffer[i],4); // this is a float
myFileAcc.close();
}
else
{
Serial.println("error opening txt-File");
}
I hope you can help me.
Thank you all!!!
You could try opening the file once and close it when your test ends.
For better help though, post or attach the whole sketch.
I have tried opening once and close it at the end but I encountered the issue that some values on the sd card were damaged when I did this... really weird.
Out of 3000 values about 10 were damaged and could not be processed afterwards. I take the data produced by the Arduino and process it on MatLab. There, I read the data from the txt-file into a vector but it cannot get passed the damaged values and I have to manually fix them, really annoying.
But open/close once has the advantage that the loop/program runs 23ms faster, hence I can sample faster and get better results.
Have you considered FRAM (Feroresemot Random Access Memory) It's similar to Static random-access memory, only with a ferroelectric layer instead of a dielectric layer. This gives it stable handling (the bytes you write are non-volatile) with dynamic responsiveness (you can write them very fast!). Some of the advantages I see in FRAM are high speed reading and writing, non-volatile storage (it remembers its contents without needing power or battery backup), virtually unlimited read / write cycles - you can't wear it out unlike some other types of non-volatile memory. To get started try this link: Adafruit SPI Non-Volatile FRAM Breakout - 64Kbit / 8KByte : ID 1897 : $5.95 : Adafruit Industries, Unique & fun DIY electronics and kits There board has a write enable input so you can lock it down and read it on another machine without worry about trashing the date. you can also copy it to the SD card when you are finished sampling.
Good Luck & Have Fun!
Gil
That sounds really interesting! Do you think that sampling at 100Hz is too fast for save writing? I thought SPI works at MHz levels? Because I don't know what can cause the values to be damaged... it goes for example like this:
0.0549
0.0522
0.43
0.0498 ...
The third value is damaged. The two missing digits are invisible, I can delete them but they can not be seen or read by MatLab, so I have to manually write or delete them.
Can the cause be buffering of SD-writing? Code? Hardware?
IMO when a system develops unexplained/random faults, especially in a system that is well ordered as in computer programming, I look first to the power supply. I know it sounds simplistic but you need to accept the fact that when diagnosing a problem you cannot assume anything.
For example, I recently developed a device with several sensors which was working well. I then decided to add to it an MKRGPS shield. I realized that if I used the I2C that power must come from the 5VDC line but I was running on battery. I devised a method to back feed the 5V line with a DC-DC converter and diodes. It seemed to work perfectly until I noticed that my SD system would unexplainably not be able to write or create files on the media. I wrote debugging script into the device to isolate but it never happened at the same time or with a specific action as the trigger. I removed the power supply modifications and was less than surprised to find that the problem instantly went away. Since then I reexamined my power scheme and the new systems happily coexist.
My advice to you is to eliminate all power drains and run your code with dummy values being written to the SD card. IOW go back to basics and prove to yourself first that the underlying code functions without fail as a basic concept. Then add in live values and the associated loads to the power supply system one by one. You will find it.