This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SD card physical damage using FlashFS

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.

Parents
  • 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...?

Reply
  • 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...?

Children
  • 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 !