Add a Thread.Sleep after you call SD.MountFileSystem. It seems some SD cards take longer to respond than others. I have a 3 second wait (Thread.Sleep(3000)) in my code, I did not do a lot of experimentation to see what the minimum pause time should be though.
Toshko, out of curiosity, why are you using paste bin instead posting the exception right here? I think it is easier to other to help you if you pout everything here instead of us need to navigate somewhere else.
You can use the "quotes to keep your exception quoted…like this
Old habits die hard I guess Gus anyway I’ve already tried adding a delay (read it from another topic) it still raises the exception.
Might there be a problem in the PersistentStorage class? I noticed on the fresh test project for this exception that if I added “GHIElectronics.NETMF.IO” it kept asking that I was missing a class USB_Host from “GHIElectronics.NETMF.USBHost”, when adding that reference and using it still kept saying the same thing. Adding the “GHIElectronics.NETMF.System” reference allowed me to compile.
I believe we tested similar Kingstone Cards and it turned out that these cards withdraw relativity a higher current than other kinds on write operations. and that causes voltage drop on the SD. To solve this issue you need to add a hardware fix or you use another kind of cards like SanDisk.
The hardware fix is by adding an additional 10uF Capacitor in parallel to C10 to resist voltage drop on the SD card.
Well, That’s a bummer. I had one of those cards and had the exact same issues with it. Nice to finally have some closure on what the cause of the issue was, though.
Hahaha, well, SanDisk, Kingston, PNY and Lexar are the main SD card companies, and you can pretty much trust that they get their stuff straight. The only reason I bought the Kingston was because it was really cheap ($8) and I figured I could get away with it.
I was very excited to see this thread pop up. I was just about to post the exact same issue. This error has been crippling my system for a while now, and I’ve done exhaustive testing of different SD cards, formatting, FEZ software, even replacing a resistor as suggested in a previous thread (essentially adding a 4.7k R in parallel with R14–a pull down at SD power). None of that, save the recommended FAT format, seemed to do much of anything in the long run.
The most frustrating part of this situation is that I’ve been seeing this failure not immediately, but after various amounts of time between 1 second and nearly 2 hours into my data logging application. Even with Verbatim cards, I was consistently failing around 7 minutes into my execution. For the record, all I’m doing is simple USB Host->SD card writes of not more than a few hundred bytes of data/sec.
I will happily try this second HW mod, though I’m still uneasy, since the Verbatims I got to replace the Kingstons are also failing. I’ve been posting about this a bit on the main GHI USBizi forum, and they said NETMF 4.1 has many fixes for the FAT filesystem. It should be out within a week or two.
I caution those who think the problem is solved by moving to a different SD card. Not to rain on any parades, but I assumed the Verbatims were better when they lasted longer than the ~45 seconds of the Kingston (pre-R14 mod), but on further inspection I’m still getting this CLR_E_FILE_IO exception. Let’s hope the cap change will help.
I think the problem is not easy to solve because we have multiple sources to the issue. Remember that each card can have slight different characteristic. If we only had to support one single card of the same type, same FAT format and same size then it will be very easy!
The resistor is needed fro those cards that do not reset properly when power drops to about 1V. You need a resistor to help bringing the voltage lower. I see this a card problem but we have to work around it. You will see this problem ONLY when initializing the card.
The capacitor problem is related to card causing mini power surges. We already have 0.1uF capacitor but then we found out that some cards are too bad! 10uf is needed!! You may see this problem anytime since it is random.
The last possible problem is a bug in the FAT drivers. There has been a lot of little fixes on 4.1 so this may help or solve the problem. Once way to know if this is the source is by using USB memory stick. If you never see problem in USB then the FAT driver is fine and your issue is related to the 2 earlier ones.