Hello!
I bought an assembled Cerbot, an SD Card and a serial Camera. The above Software works fine, but only once! The second time the SD card is corrupted and I have to format it.
I tried to delete existing files
(if (File.Exists(path)) {file.Delete();}
but this doesn’t work.
What can I do to run the program twice or more? Why became the SD Card corrupted?
Thanks in advace
Ingeborg
If you write to SD card, the data is not necessarily written immediately.
It can take several second or even minutes before the data is really written.
If you turn of your device before the data is written, the file system might be corrupt.
To avoid this you could look for ‘flush file system’ in forum / Codeshare.
Can’t find information about “flush file system”.
Please help me with a link.
Thanks
Ingeborg
@ Ingeborg -
Some thing like this:
VolumeInfo vol = VolumeInfo.GetVolumes()[0];
.........
// open stream
//.......
/// write data
.........
vol.FlushAll();
This is done in the code section (see above).
The excample code is working well: I took more than 100 pictures. They were stored on the SD Card and I can read them in the PC with a picture viewer. The problem is that this is done only once! It is really no solution to format the card to take new pictures with the same name.
Ingeborg
Please fully articulate what you’re doing to see this. What does work, what does not. What process you use to test this and where your findings deviate from your expectations, and tell us what error messages are reported along the way.
From what I am hearing though, you are successfully writing multiple images to the SD card. Then at some stage, you take that card over to a PC and read the images, which works fine. (here’s a guess) If you attempt to take the card back into your Cerbot and take more images, you can’t. At this point the only remedy is to format the card on a PC.
If the scenario above is what you are experiencing then I think you’re going to need to show us your full code so we can understand where things are going wrong. Could it be that your code is not handling filenames correctly and potentially trying to write a file with a name that is already in use, and the format “fixes” this by removing the duplicate? I personally think the most telling information will be what your debugging of the situation shows, what errors are thrown, when. Usually when I have a problem, debugging output tells me where - for you that might mean your cerbot loses some of it’s freedom temporarily and lives connected to a PC.
I used the code in #15 without changes (besides the namespace) , C# express 2010, Cerbot connected to PC via USB (no hub). SC Card on socket 1, serCam on socket 3.
Copy of the output window follows.
Found debugger!
Create TS.
Assembly: Microsoft.SPOT.Hardware.Usb (4.2.0.0) Assembly: System.Xml (4.2.0.0)
Assembly: Microsoft.SPOT.Hardware.PWM (4.2.0.1) Assembly: Microsoft.SPOT.Net (4.2.0.0)
Assembly: System (4.2.0.0) Loading Deployment Assemblies.
Attaching deployed file.
Assembly: GHI.OSHW.Hardware (4.2.6.1) Attaching deployed file.
Assembly: Gadgeteer (2.42.0.0) Attaching deployed file.
Assembly: GTM.GHIElectronics.SDCard (4.2.102.0) Attaching deployed file.
Assembly: Gadgeteer.Serial (2.42.0.0) Attaching deployed file.
Assembly: CerbotSDSercam_Topic14475 (1.0.0.0) Attaching deployed file.
The debugging target runtime is loading the application assemblies and starting execution.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Micro Framework\v4.2\Assemblies\le\mscorlib.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Native.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Graphics.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.TinyCore.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.SerialPort.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.IO.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Micro Framework\v4.2\Assemblies\le\System.IO.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.OneWire.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.Usb.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Micro Framework\v4.2\Assemblies\le\System.Xml.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.PWM.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Net.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Micro Framework\v4.2\Assemblies\le\System.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\GHI Electronics\GHI OSHW NETMF v4.2 SDK\Assemblies\le\GHI.OSHW.Hardware.dll” geladen
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Gadgeteer\Core\Assemblies.NET Micro Framework 4.2\le\Gadgeteer.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\GHI Electronics\GHI .NET Gadgeteer SDK\Modules\SDCard\NETMF 4.2\le\GTM.GHIElectronics.SDCard.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Gadgeteer\Core\Assemblies.NET Micro Framework 4.2\le\Gadgeteer.SPI.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\Microsoft .NET Gadgeteer\Core\Assemblies.NET Micro Framework 4.2\le\Gadgeteer.Serial.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\GHI Electronics\GHI .NET Gadgeteer SDK\Modules\SerCam\NETMF 4.2\le\GTM.GHIElectronics.SerCam.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\GHI Electronics\GHI .NET Gadgeteer SDK\Modules\CerbotController\NETMF 4.2\le\GTM.GHIElectronics.CerbotController.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Programme\GHI Electronics\GHI .NET Gadgeteer SDK\Mainboards\FEZCerbot\NETMF 4.2\le\GHIElectronics.Gadgeteer.FEZCerbot.dll” geladen, Symbole geladen.
“Microsoft.SPOT.Debugger.CorDebug.dll” (Verwaltet): “C:\Dokumente und Einstellungen\Wagner\eigene dateien\visual studio 2010\Projects\CerbotSDSercam_Topic14475\CerbotSDSercam_Topic14475\bin\Debug\le\CerbotSDSercam_Topic14475.exe” geladen, Symbole geladen.
Der Thread ‘’ (0x2) hat mit Code 0 (0x0) geendet.
Using mainboard GHI Electronics FEZCerbot version 1.0
Program Started
Der Thread ‘’ (0x3) hat mit Code 0 (0x0) geendet.
SD Mount Detected
Found root directory: \SD
Starting Camera Feed
Saved \SD\Image-0.bmp
Saved \SD\Image-1.bmp
Saved \SD\Image-2.bmp
Saved \SD\Image-3.bmp
Saved \SD\Image-4.bmp
Saved \SD\Image-5.bmp
Saved \SD\Image-6.bmp
Saved \SD\Image-7.bmp
Saved \SD\Image-8.bmp
Saved \SD\Image-9.bmp
Saved \SD\Image-10.bmp
Saved \SD\Image-11.bmp
Saved \SD\Image-12.bmp
Saved \SD\Image-13.bmp
Saved \SD\Image-14.bmp
Saved \SD\Image-15.bmp
Saved \SD\Image-16.bmp
Saved \SD\Image-17.bmp
Saved \SD\Image-18.bmp
Saved \SD\Image-19.bmp
Saved \SD\Image-20.bmp
Saved \SD\Image-21.bmp
Saved \SD\Image-22.bmp
Saved \SD\Image-23.bmp
Saved \SD\Image-24.bmp
… which doesn’t show any sign of corruption, and successfully writes the file numerous times.
Nobody said the code in any of these posts is robust, it’s a starting point. If you show us the debug when you run into the issue you’ll help (yourself mainly) to understand what you might want to do to make it meet your needs.
Thank You for your help!
I’ll give the Cerbot back!
So easy to use! :wall:
Ingeborg
Sorry to hear that you feel that way.
You’ve not told us anything about what you’re trying to achieve or your experience level. These devices are programming devices, so you really will need to understand the code at some stage. The code provided here is totally just to prove the capability of the device. If you want to extend it, but can’t, then you’ll have to help out by showing us more debugging info.
By the way: I’m a computer scientist and physisist (PHD in Germany: Dr.) I am coding for Atmel Studio (in C) with Atmel and all things are running. Just for fun I want to run a small robot on the floor, catching pictures an find the yellow egg in the room.
But: things going worse.
I think the same happen to KWAUGH.
Ingeborg
Amazing!
???
ok cool. So you’re more than capable of working through this, that’s great. (and I won’t bring out the AVR Freaks “we aren’t going to do your homework for you” comments). I hope you stick it out and get past this challenge
Here’s my potential solution to what I think your problem is.
Keep a file that contains just a serial number, that we’ll use to create the “next” filename to use. Call it NextFile.txt.
At startup, open nextfile for reading. Parse the file contents. Set the file number counter to this value. Close the file.
After writing each image file, open the nextfile for writing/overwrite and write the updated counter out; close the file.
You can prove my hypothesis of what is going on here by taking the SD card over to a PC and simply deleting the files that exist, and then re-run the cerbot and confirm a new set of files are created. If the SD volume is not actually corrupted as you earlier said, this should work fine.
Of course if this is the scenario you’re hitting, then there are many ways to really deal with this. Another alternative is you could name the files with a real date and time (image-yyyymmddhhmmss.jpg for example) but you’ll need to make sure you have an RTC (I have no cerbot to know if that’s there or not). You could use system ticks value and hope that you never get a conflict. But one easy step is to look at the debug output when you’re reproducing the “failed” state and see what the errors thrown and (most likely) not handled properly.
As Brett said, there is lots of help to be found here on the forum.
From your background, I think you know all the comments and suggestions in the paragraph below. But have become very frustrated! Keep at it, post your results and your ideas, and we will do our best to assist you in a timely fashion.
Remember, we are not sitting in your office nor can we duplicate your exact environment. Which is why we ask for information, suggest experiments; and wait for the data from the experiments. Your problem may be something very simple; but not obvious. There could be hardware issues, there could be power issues,…
[quote]I think the same happen to KWAUGH.[/quote] The problem you have described could be related to the memory issues reported by KWAUGH. Based on what you’ve reported so far, I would suspect otherwise. The fact that the program runs correctly the first time, but not the second, indicates that’s Brett’s suggestions are better to follow.
Brett:
(and I won’t bring out the AVR Freaks “we aren’t going to do your homework for you” comments)
What do you mean?
Brett
…you have an RTC (I have no cerbot to know if that’s there or not) RTFM
Thank You! I am really not interested in such comments
@ Ingeborg - :naughty:
Who are you?