Hello,
We are using FlashFS (RL-ARM 4.13) and experiencing several problems with SD cards: some of them end up with a damaged FAT, others are physically damaged beyond repair/format (sector 0 not accessible). The assumption is that power failure events tend to incur this damage (however, files are being closed ASAP after writing, data is also flushed ASAP after writing in writing multiple blocks, power failure is detected within 1[ms] approximately after it occurs and it closes all files), but my question is simple: Can an (industrial grade) SD card be physically damaged beyond repair due to a power failure? The problem is so severe that the client WANTS FlashFS out ASAP even though it is not entirely clear what the reason is. Have you experienced something similar? Another product we have here does not suffer from this problem, but is also a lot simpler and does not use a preemptive scheduler. Any comments are welcome.
Most flash cards have an controller that performs wear leveling and other stuff and then have to store own information on the card to be able to know what sectors are stored where.
Does your problem affect more than one brand of cards? Maybe the flash controller isn't so good, so it stores the information in a way that it can't roll back and get a valid defects list etc in some situations.
Another thing - have you verified all power parameters (rise time, fall time, ...) for the supply voltages and control voltages to the memory cards?
Hello Per,
The problem does indeed affect multiple brands. A solution for the non-preemptive scheduler product that I mentioned was to increase the DMA transfer timeout (Keil suggested that) in the MCI driver, but that does not seem to help for the other products, alas. The power parameters were verified when the first prototypes were received - but it's worse asking the hardware team again. I am also going to make a few measurements of my own. Thanks for your reply.
Have you spoken to your "industrial grade" SD card supplier about this?
No I have not - but you're right, I should do that !
Tamir,
We use FlashFS RL-ARM 4.13 for our logging of data etc in our controller, where we will write a few log lines per second. We have similar checks for power failure etc, closing all the files etc.
We have performed tests on our controller using standard Sandisk 2GB SD card where we powered the instrument on and off on a timer every 10 or so seconds for about 4 days. I found to my surprise that while files could become corrupted we didn't have a total SD card failure. While this is not a perfect test it is deemed good enough for our purposes.
So far I have never managed to totally corrupt an SD card beyond repair. Although Keils earlier FlashFS code had some pretty good attempts at doing this!
Have you tried the "SD formmater" program? Its from the sdcard association, I use version 2 but it appears there is now a version 3. This has repaired all the problems I have encountered so far on corrupted Sd cards. Just search for it under google if you want to give it a try.
Stuart.
Typo that should be sd formatter
www.sdcard.org/.../
Thanks a lot for everybody's input! Much appreciated!
Stuart, all,
I have tried this tool, but I'm afraid that the SD cards in question are so damaged that they are not even recognized by my Windows XP machine, nor are a Linux box... I need to measure it, but it could be that we're operating outside of the specifications of the cards - ergo, at voltage levels that are too low to write resulting in physical damage. Since a hardware change at this point is out of the question, I am considering not forcibly closing files upon power failure detection and accepting theoretical file corruption in case there was a write in progress. Another option is not to use any buffering. Any thoughts...?
I log CAN msgs ( about 10 meg in a day).
The hardware uses the SDIO perpherial
To detect power failures I use a A2D watchdog (stm32) and then on unexpected power downs try immediately open write and close. The hardware has a certain power reserve that allows me to do this.
I was worried about the number of sector manipulations the FS does to write small amounts of data so I now buffer the data into a sector size then open and write the file and close it.
Occasionally I get rubbish appended to the end of the file, but its stopped corrupting the sd card as earlier writing schemes did. E.g. open the file the write when required close when power failing.
Sometimes just geting and empty file - I assumed the cluster chain and root directory were not being updated before the power went
Sometime the SD card would be unsable afterwards - cant format in a PC etc
Perhaps it may be worth looking at how you run the SD card, rather than try and find a "special brand" SD card that works all the time.
Just been informed there is a update to the tool chain because of the Filesystem etc - the links I had to the source for the FS does not seem to be active with a new update so lets find out whats new !