How to recover data from SD?

[muntu_the_killer]

Posted on November 07, 2013 at 12:14

Hello everyone,

I'm writing data to SD for a few seconds/minutes. If I disconnect the board while recording, when I look at the file with windows, it shows the file with an extension of 0Kb. How can I fix the file after? My intention is to fix it in the next execution of the program.I think I've to access to the FAT table, but I don't know how. In theory, the sectors are written, but I need to fix something.How can I do it?Thanks!Miquel

[Tesla DeLorean]

Posted on November 07, 2013 at 13:08

Doing a close or flush should prevent the file system getting in this state.

You need to do the equivalent to CHKDSK or FSCK, navigating the lost FAT chains, and then associate them with a file or files. This is a non-trivial task and will require you to understand the FAT file system at a structural level.

[muntu_the_killer]

Posted on November 07, 2013 at 13:26

Hi Clive,

I understand how FAT works, writing data in non consecutive sectors. In theory, should be some place where appears the next sector that contains the next data of the same file. The problem is that I don't know how to see the FAT table to search in which sectors is the file.Can you help me on this?Thanks!Miquel

[frankmeyer9]

Posted on November 07, 2013 at 14:26

I believe clive's comment steered more towards solving the problem at the root, and not dealing with the symptoms/effects.

Try adding a call to f_sync() after each write to the SD card, to get all you changes actually written to the file. And try not to pull the card while writing to it. And it might be necessary to re-format the corrupted SD card(s).

[Tesla DeLorean]

Posted on November 07, 2013 at 14:27

Like I said, you need to understand the FAT file system at a structural level. This means understanding the BPB, and how that infers the location and size of the internal structures. In all likelihood you will have a chain of clusters in the FAT table, which may/may not be associated with a specific file within the directory tree. The length of the chain can infer size, at least in clusters, of the file they are backing. The file entry may/may not fully express the current size. There may be multiple lost chains, and files.

Observing the behaviour of tools like CHKDSK/FSCK, and their source, may be instructive as to how to fix the file system structures. You have access to sector read/write functions, and you will need to use these to navigate the media, and the file system.

[muntu_the_killer]

Posted on November 07, 2013 at 16:16

I need to solve the poblem in my program, not using windows, because I want to create a device. So, I need to fix the file on the top of my main program. I need to know which parameters are wrong in the file, so that I can change it in the program, close the file, and fix it.

[Tesla DeLorean]

Posted on November 07, 2013 at 17:26

Indeed, please re-read what I've written.

[dthedens23]

Posted on November 07, 2013 at 22:36

SD cards are not ment to be ripped out while in use.

change your hardware and firmware to power off the SD card (use a LDO with a shutoff pin to remove 3.3v from the SD card.then wire up the SD card insert and removal pin on the SD connector to a GPIO  interrupt pin so that you can detect insert and removal (so you know when to reapply power).then make users press a button or something before they can remove the SD card so you can close all open files and turn off the 3.3v to the card.Maybe you should read the SD card spec to see what it says about hot swapping SD cards.