SD/MMC issue with FemtoBasic
Oldbitcollector (Jeff)
Posts: 8,091
I've noticed an interesting issue with FemtoBASIC and the SD/MMC card.
{set the scene}
I've been developing with on a PC across the room from my Protoboard setup,
saving the new programs in binary format onto the SD card, (Under WindowsXP)
then moving the SD over to my project, bootng to Femto, and using SPIN "FILE
to boot the new item.
This works well, except I've spotted some sort of issue happening...
When I do a "FILES" from Femto, I see duplicated listings over and over again.
Seems that each time I save a file from the XP box to the SD card, the directory
table is replicated. This doesn't show on the Windows box, even a DOS dir looks
normal. This problem replicates as each time a file is saved from the Windows box.
On Femto, "files" starts to look something like this...
FILE 1 FILE 2 FILE 3
FILE 4 FILE 5
FILE 1 FILE 2 FILE 3
FILE 4 FILE 5
FILE 1 FILE 2 FILE 3
FILE 4 FILE 5
I've been reformatting the SD, and putting the files back on after a few duplications
occur, (Or whenever I get sick of seeing duplication.)
Which direction should I look on this? I wonder if Windows file/save is causing the issue.
Oldbitcollector
{set the scene}
I've been developing with on a PC across the room from my Protoboard setup,
saving the new programs in binary format onto the SD card, (Under WindowsXP)
then moving the SD over to my project, bootng to Femto, and using SPIN "FILE
to boot the new item.
This works well, except I've spotted some sort of issue happening...
When I do a "FILES" from Femto, I see duplicated listings over and over again.
Seems that each time I save a file from the XP box to the SD card, the directory
table is replicated. This doesn't show on the Windows box, even a DOS dir looks
normal. This problem replicates as each time a file is saved from the Windows box.
On Femto, "files" starts to look something like this...
FILE 1 FILE 2 FILE 3
FILE 4 FILE 5
FILE 1 FILE 2 FILE 3
FILE 4 FILE 5
FILE 1 FILE 2 FILE 3
FILE 4 FILE 5
I've been reformatting the SD, and putting the files back on after a few duplications
occur, (Or whenever I get sick of seeing duplication.)
Which direction should I look on this? I wonder if Windows file/save is causing the issue.
Oldbitcollector
Comments
1st..
Format the SD/MMC in a dos window using:
FORMAT X: /fs:fat /a:1024
{no volume label}
Then I copy my files to SD from a folder on
my hard drive. (At least 5 files should do the trick)
Now, checking the "FILES" in Femto reveals
a perfect listing.
Take the SD back to the PC, save a binary
to the memory stick directly from the Propeller tool.
Take the SD back to FemtoBASIC, and now
you have two files listings, back to back.
If you overwrite the binary file from the Propeller Tool,
and go back to Femto, now you have three listings...
The only fix has been to copy all the files off the
SD, reformat the SD using the original format
command and go agsin...
----
I also noticed that tonight, after I had 30 files
on the SD/MMC, it didn't seem to matter whether
I reformatted the memory stick. Problem doesn't
go away until reduce the number of files.
and then send me a full image of the SD card (the one that femtobasic claims has "duplicate" files)? You can
snarf the image on a linux box using dd, and you can gzip it, and you can upload the file to
http://tomas.rokicki.com/cgi-bin/upload.pl and let me know.
BTW if you don't have a small SD card, that's fine; if you do a full format before running this test the image
should compress to almost nothing anyway.
If you don't have access to linux, or you can't do this for some reason, we can figure out a different way to
debug things.
(I'll try the steps you outline tonight when I get home, just in case I can reproduce them here.)
Thanks for the bug report!
Are you inserting the SD card hot? (It really shouldn't matter, but . . . it's good to know anyway).
It's really odd that you can get duplicated entries like that, especially if you can get three or more.
Get me a dd of the SD card when it's showing that behavior on FB and I'll do two things:
1. Verify the disk format/directory under linux (using a hex dump), and
2. Make a direct duplicate of that card here and see if my femtobasic does the same thing.
These will go a long way towards understanding the problem.
I don't have a linux box setup to read SD media, so I may have to grab a copy of KNOPPIX and see I can DD it from there.
Yes, I'm doing pulling/inserting it hot in both locations.
(Shouldn't make a difference, but mileage may vary)
Oldbit
If you are pulling/inserting it hot, I would definitely add at least a pair of capacitors across the power
supply to the SD card as close to the card as you can; the insertion current spike can be significant.
The pair should be the usual suspects; perhaps a .1uF ceramic or tantalum, and a 10uF electrolytic.
I doubt this is the problem, but you never know.
If after seeing this multiple incarnations of a file, you power cycle the prop system, does it still persist?
(This will tell us if the problem is on the card itself or in the propeller's memory.)
Also, this is not related to your problem, but if you format with a 8K cluster instead of 1K, you'll get
somewhat better performance.
Finally, could you attach the full archive of the femtobasic you are using? I just want to make sure
I debug against as close to what you are running as possible.
Post Edited (rokicki) : 4/3/2007 3:34:30 PM GMT
If I understand things, you are not writing to the card at all on the propeller side. Is that correct?
:: Yes, the problem occures without writing to the card on the propeller side, although
the card is written to from both places.
If you are pulling/inserting it hot, I would definitely add at least a pair of capacitors across the power
supply to the SD card as close to the card as you can; the insertion current spike can be significant.
:: Point taken.. Will also test this tonight, inserting the card with power off.
:: This should eliminate that as a factor.
If after seeing this multiple incarnations of a file, you power cycle the prop system, does it still persist?
:: IIRC, yes the problem persists after a reboot. So it's not the prop.
Also, this is not related to your problem, but if you format with a 8K cluster instead of 1K, you'll get
somewhat better performance.
::Yes, I was feeling wasteful because I figured there was no way
::I'd ever use 64MB on my Propeller. [noparse]:)[/noparse] Actually, I'm already close to 1/2 meg.
Finally, could you attach the full archive of the femtobasic you are using? I just want to make sure
I debug against as close to what you are running as possible.
::Will do tonight..
Oldbitcollector
Sorry if I've offended someone with my formatting...
Successfully uploaded file.
Got 47190 bytes.
md5 sum is 756250f96b4a11ed54f9904e6a3d2a5f 11390-upload.tst .
Oldbitcollector
further progress. Booting into knoppix should do it.
SecureDigital routines when working on a card with a lot of files and a small cluster size. The bug has
been fixed, and there is a new version of fsrw-and-friends at http://tomas.rokicki.com/fat16work/
Other than the version number change (from 1.4 to 1.5) and the date change, the only difference is
this in nextfile:
*************** *** 526,531 **** --- 528,535 ---- t := pfillbuf if (t < 0) return t + if (((floc >> SECTORSHIFT) & ((1 << clustershift) - 1)) == 0) + fclust++ at := @buf + bufat if (byte[noparse][[/noparse]at] == 0) return -1This does mean of course that all the variations of femtobasic also need to be
updated.
While I'm here I will note that Paul Baker was successfully running the secure digital card at
ESC with no pullup resistors at all---just four wires connected from the propeller to the SD
card. While I don't recommend this for industrial designs, simply because I was taught to
always pull up unconnected CMOS inputs, don't let the fact that you don't have the resistors
keep you from experimenting with the SD card.
Oldbit