I am using a FEZ Domino for a cheap off-the-shelf board for a DataLogger project which we have had working for the last year and a half. It takes data every 5 seconds and records it to a file. Just recently it stopped recording data and we believe that the issue is that the .NET Micro environment sees the SD card as being full, but there is only a few MB on a 4GB flash drive. What I think is happening is that the SD card blocks are being marked as “for erasure”, but the .NET Micro does not actually ever delete these blocks.
Putting the SD card to a PC and formatting it fixes the problem until it gets full again. I did simulate the problem again in a few hours time by just writing to the file once a second as opposed to once a every 5 minutes (300-seconds). Again, there was only a few MB of space on the SD card but it was giving an I/O error exception.
Has anyone else run into this problem or solved it? I am unsure if there is a command I can do in .NET MF to tell it to clean up a Fat File System (or Fat32) and actually erase blocks that should be because nothing of importance is written to them.
@ ShaamRocks - Not sure this is a problem. If there is a few MBs left, shortly they would be gone and you would be out of storage. You might need some logic to delete older files from the SD.
I do not have any knowledge of the MF file system, but I suspect there is some minimum amount of storage that is necessary to create a new file. The remaining MBs might not be enough for a new file. Or, you have actually exhausted storage, but the SD has not been update to reflect the condition. If you are running out of space while writing to a file, then close the file and see if there is still free space on the SD.
@ Mike
The problem that I am running into is that I don’t just have a few MBs left, I have GB’s left on the card. This is why I think that the problem may exist beyond my ability to debug it, such as the .NET filesystem implementation.
Older files are deleted constantly, we only keep a running 30-days worth of data, with each new file being a different function of the unit being logged. The logging can last a few hours to a few days at times. What SHOULD happen when I open a file and write a single line is that it opens and pushes a single line, it should write it, but I suspect that the filesystem is re-writing the entire file, and eventually 10kb adds up when copied thousands of times, and it grows as time passes.
This is why I am coming here to the experts to see if anyone else has run into this issue or actually uses GHI products for a production intent.
Thanks for the question Mike. I actually believe that we are being “bit” by the Kingston issue where it will sometimes lower the voltage too much and that is causing the card to require reinitialization.
@ Peter
My data logging application has the FEZ (soon to be G120) copying from the SD card to a USB card.
I’m now intentionally putting corrupted files on the system and trying to figure out programmatically how to run a check disk on the SD card because if I start running a File.Copy(source, dest) on the bad file, there are no exceptions and it simply locks up. I might have to run a separate timer to not allow a file larger than a particular size to copy (because it cannot exist, such as a file returning 26GB on a 4GB SD card).
So…when I have more information on this, I’ll post my findings.
I started a new thread more or less on the same issue. I have developed a data logger and ran into problems on asynchronously power down and reset events… Then I read this post, so I continue here…
This is indeed a generic problem which is widely ignored ( except here
I had already activated the FlusAll() function every 5 seconds, but it seems there is still some kind of corruption in the filesystem preventing from futher datalogging after an asynchronous RESET or POWER down…
So I think the best option for now is to implement a reset-, power down-, sd-remove-button, and using a super-cap or battery…as suggested earlier https://www.ghielectronics.com/community/forum/topic?id=15879
