The initSDcard routine sets up the I/O pins for the SD card and initializes the card itself by sending a whole bunch of clock pulses with the card selected and a reset command to the card. Make sure you have the I/O pins correct. Sometimes DI and DO are mixed up although if you were able to get an SD card to work previously with the same setup, it wouldn't change suddenly.
If the wiring is correct, then initSDcard should succeed. If it doesn't, the card may be defective or the Propeller's I/O pins may be damaged. initSDcard works at a pretty basic level and has nothing to do with whether there's any data recorded on the card.
Thanks, Mike, I'll double check the wiring and then I'll try a fresh SD card and a program that wrote data in the past without any problems. Maybe I fried the Propeller pins.
Leave it to me to write a program that can destroy SD cards.
Well....
I double checked the wiring and all looks okay. Also, I put in a fresh, never used SD card and ran one of my older programs, which wrote lots of files and some data to the card, without any problems.
The two cards that I fried in succession with my software are of two different brands and two different sizes - One is a Lexar of 2 Gbytes, the other a Patriot of 1 Gbyte. When I run disk utilities on them, the errors that come up look the same. I guess that makes my software the culprit. I need to wrap this software with yellow tape and mark it TOXIC to SD cards.
Maybe I should've gone into investment banking, then I could really foul things up and yet have nothing to worry about.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It might be the Information Age but the Eon of Ignorance has yet to end.
I’m not sure that’s ok to do, I could be totally wrong here.
After I fried one of my 64mb cards, from what I can tell, was destroyed by not turning off the power to the data logger before removing/inserting the card, I have not fried any cards when the data loggers power has been turned off.
that's a very good question! Generally what I've done in the past is I stop my on-going program by downloading a "DoNothingProgram". That usually leaves all of my written and closed files intact but messes up the final file, which I never really cared about. That "technique" worked for many dozens of debuggings without discernible dramas going on. Not the most elegant way to do it, I admit, but when I started corrupting the SD cards, I was just doing some testing and figured I would install a less brutal system of closing down later on.
I'm not sure how to NOT hot-swap a card except to "close" its final file. Is it necessary to shut down power to the Vdd lines leading to the SD card, too? and/or maybe the Propeller as well???
The SD card and socket are designed so the card can be inserted and removed when power is present in the socket.
Even if the microcontroller is attempting to do a transfer, the removal of a card should not physically or electrically
damage the card or the microcontroller. The data may possibly become corrupt if a transfer is in progress, but the
card itself should be ok.
Resetting a prop while a transfer is in progress *may* cause some problems; I am not sure. I'd need to review things.
For instance, how long before reset is applied do the counters stop "counting"? Does program execution cease before
the counters stop? (Downloading your donothing program resets the prop for sure.)
But frankly, if your program is still crashing on its nth iteration while running, that may be strongly related. I fully
intended to download your program last night and try it on my protoboard, but I decided to spend some time with my
wife instead. Maybe tonight I'll get more lucky.
Because the forum serves as a kind of living document for the Propeller, I'm pointing this thread to another thread recently begun by rokicki, who provides a fix for this problem:
Sounds like you are passed the problem... but for others that might come across similar problems:
Using the uSD on the 4D Systems-Prop-96, I found that if I removed the card while writing to it then I would not be able to open the same file under Windows... and sometimes Windows wouldn't be able to see the uSD.
However, I could still see the file on a Mac, but be unable to open it. By copying the file from the uSD to the Mac HD I could then import the data to an application called ImageJ on a Mac (although other Mac applications would still fail) and then resave the file from ImageJ to another folder on the Mac. I have never actually ruined a card simply by removing it while writing... occasionally I have had cards that Windows wouldn't see... but the Mac would. Trashing the corrupted file on the Mac allows Windows to see and reformat the card.
What I did to try to avoid this problem was to close everything as often as possible in between writes. On my system, I was recording GPS data to the uSD about once a second... and mirroring the data to the screen, so I simply wait for the write to be over on the screen before removing the card... a green LED lit up when everything is closed would be a similar visual indicator[noparse]:)[/noparse]
Maybe Rokiki could design a system to pass a mild electrical shock to the finger when the card is writing...
rjo_ said...
....By copying the file from the uSD to the Mac HD I could then import the data to an application called ImageJ on a Mac (although other Mac applications would still fail) and then resave the file from ImageJ to another folder on the Mac...Trashing the corrupted file on the Mac allows Windows to see and reformat the card.
Maybe Rokiki could design a system to pass a mild electrical shock to the finger when the card is writing...
Hi rjo_
thanks for this tip. For me, however, my Mac could not see any of the files, only the SD card itself. So far nothing I've tried has brought the cards back from the dead. I'm hoping rokicki's discovery of the pwrite problem might also yield a solution to saving these "zombie-fied" SD cards.
As for providing electric arcs to the body when touching circuits, that sounds like my department.
rjo_ said...
However, I could still see the file on a Mac, but be unable to open it.
I found a similar problem when developing JDForth, and discovered a cause (under Windows at least).
The filename and extension MUST be all capital letters for the file to be opened by Windows. If not, then the file may be visible but Windows can't open it. I suspect it could be the same for MACs.
JDForth avoids this problem by automatically converting the file names to uppercase before writing them into the directory structure on disk.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Carl Jacobs
JDForth - Forth to Spin Compiler http://www.jacobsdesign.com.au/software/jdforth/jdforth.php
Includes: FAT16 support for SD cards. Bit-bash Serial at 2M baud. 32-bit floating point maths.·Fib(28) in 0.86 seconds. ~3x faster than spin, ~40% larger than spin.
Comments
If the wiring is correct, then initSDcard should succeed. If it doesn't, the card may be defective or the Propeller's I/O pins may be damaged. initSDcard works at a pretty basic level and has nothing to do with whether there's any data recorded on the card.
Leave it to me to write a program that can destroy SD cards.
I double checked the wiring and all looks okay. Also, I put in a fresh, never used SD card and ran one of my older programs, which wrote lots of files and some data to the card, without any problems.
The two cards that I fried in succession with my software are of two different brands and two different sizes - One is a Lexar of 2 Gbytes, the other a Patriot of 1 Gbyte. When I run disk utilities on them, the errors that come up look the same. I guess that makes my software the culprit. I need to wrap this software with yellow tape and mark it TOXIC to SD cards.
Maybe I should've gone into investment banking, then I could really foul things up and yet have nothing to worry about.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It might be the Information Age but the Eon of Ignorance has yet to end.
Have you been ‘hot swapping’ your cards?
I’m not sure that’s ok to do, I could be totally wrong here.
After I fried one of my 64mb cards, from what I can tell, was destroyed by not turning off the power to the data logger before removing/inserting the card, I have not fried any cards when the data loggers power has been turned off.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike
that's a very good question! Generally what I've done in the past is I stop my on-going program by downloading a "DoNothingProgram". That usually leaves all of my written and closed files intact but messes up the final file, which I never really cared about. That "technique" worked for many dozens of debuggings without discernible dramas going on. Not the most elegant way to do it, I admit, but when I started corrupting the SD cards, I was just doing some testing and figured I would install a less brutal system of closing down later on.
I'm not sure how to NOT hot-swap a card except to "close" its final file. Is it necessary to shut down power to the Vdd lines leading to the SD card, too? and/or maybe the Propeller as well???
This is something I never thought of before.
thanks!
Mark
Even if the microcontroller is attempting to do a transfer, the removal of a card should not physically or electrically
damage the card or the microcontroller. The data may possibly become corrupt if a transfer is in progress, but the
card itself should be ok.
For instance, how long before reset is applied do the counters stop "counting"? Does program execution cease before
the counters stop? (Downloading your donothing program resets the prop for sure.)
But frankly, if your program is still crashing on its nth iteration while running, that may be strongly related. I fully
intended to download your program last night and try it on my protoboard, but I decided to spend some time with my
wife instead. Maybe tonight I'll get more lucky.
I guess if she's a robot, he's got it made.
http://forums.parallax.com/forums/default.aspx?f=25&m=296377&p=1
Thanks everyone!
Mark
Lucky is a dog... so, I guess I feel lucky.
Sounds like you are passed the problem... but for others that might come across similar problems:
Using the uSD on the 4D Systems-Prop-96, I found that if I removed the card while writing to it then I would not be able to open the same file under Windows... and sometimes Windows wouldn't be able to see the uSD.
However, I could still see the file on a Mac, but be unable to open it. By copying the file from the uSD to the Mac HD I could then import the data to an application called ImageJ on a Mac (although other Mac applications would still fail) and then resave the file from ImageJ to another folder on the Mac. I have never actually ruined a card simply by removing it while writing... occasionally I have had cards that Windows wouldn't see... but the Mac would. Trashing the corrupted file on the Mac allows Windows to see and reformat the card.
What I did to try to avoid this problem was to close everything as often as possible in between writes. On my system, I was recording GPS data to the uSD about once a second... and mirroring the data to the screen, so I simply wait for the write to be over on the screen before removing the card... a green LED lit up when everything is closed would be a similar visual indicator[noparse]:)[/noparse]
Maybe Rokiki could design a system to pass a mild electrical shock to the finger when the card is writing...
Hi rjo_
thanks for this tip. For me, however, my Mac could not see any of the files, only the SD card itself. So far nothing I've tried has brought the cards back from the dead. I'm hoping rokicki's discovery of the pwrite problem might also yield a solution to saving these "zombie-fied" SD cards.
As for providing electric arcs to the body when touching circuits, that sounds like my department.
Mark
The filename and extension MUST be all capital letters for the file to be opened by Windows. If not, then the file may be visible but Windows can't open it. I suspect it could be the same for MACs.
JDForth avoids this problem by automatically converting the file names to uppercase before writing them into the directory structure on disk.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Carl Jacobs
JDForth - Forth to Spin Compiler http://www.jacobsdesign.com.au/software/jdforth/jdforth.php
Includes: FAT16 support for SD cards. Bit-bash Serial at 2M baud. 32-bit floating point maths.·Fib(28) in 0.86 seconds. ~3x faster than spin, ~40% larger than spin.
Thank you Carl.
Rich