Fixed; the top post now has fsrw22.zip which fixes this bug and also makes FAT scanning faster. (The latter
significantly helps the case of writing a file when the volume has a lot of space already, and also speeds up
all the "pwrite" numbers by a nontrivial percentage).
We were definitely aiming for the MIT license for OBEX compatibility (and the fact that it is my favorite license is nice too . If we messed up on the text, I apologize. I will add an explicit comment "Licensed under the MIT License" to my code, might be tomorrow before I get to it, though, sorry. Tom, feel free to step in and modify my code before then if you wish.
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
The license is the explicit text that was posted several years ago as the "standard"
license to use for all ObEx code. I thought it was the MIT license.
Here's a v2.2 test with a 1GB card with 32K clusters.
Waiting for key press to start tests
Mount tests first
First mount.
Succeeded; stopping cog.
Second mount.
Succeeded.
Reading block 0 (should be a boot block)
Read finished; checking for boot block signature
Boot block checks out; unmounting
Third mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Boot block checks out; writing it back
Write finished; unmounting
Fourth mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Block layer seems to check out
Now speed tests
How fast can we write, sequentially?
Raw write 3968 kB in 2405 ms at 1649 kB/s
Do a single non-sequential write...Done
How fast can we read, sequentially?
Raw read 3968 kB in 3919 ms at 1012 kB/s
Now the filesystem tests
Trying to mount
Mounted.
How fast can we write using pwrite?
fsrw pwrite 992 kB in 2142 ms at 463 kB/s
How fast can we read using pread?
fsrw pread 992 kB in 1477 ms at 671 kB/s
How fast can we write using pputc?
FSRW pputc 127 kB in 3803 ms at 33 kB/s
How fast can we read using pgetc?
FSRW pgetc 127 kB in 3195 ms at 39 kB/s
Repeating all the speed results:
Clock: 96000000 ClusterSize: 4096 ClusterCount: 247506
Raw write 3968 kB in 2405 ms at 1649 kB/s
Raw read 3968 kB in 3919 ms at 1012 kB/s
fsrw pwrite 992 kB in 2142 ms at 463 kB/s
fsrw pread 992 kB in 1477 ms at 671 kB/s
FSRW pputc 127 kB in 3803 ms at 33 kB/s
FSRW pgetc 127 kB in 3195 ms at 39 kB/s
All done!
Mike Green said...
Here's a v2.2 test with a 1GB card with 32K clusters.
...
Clock: 96000000 ClusterSize: 4096 ClusterCount: 247506
Raw write 3968 kB in 2405 ms at 1649 kB/s
Raw read 3968 kB in 3919 ms at 1012 kB/s
fsrw pwrite 992 kB in 2142 ms at 463 kB/s
fsrw pread 992 kB in 1477 ms at 671 kB/s
FSRW pputc 127 kB in 3803 ms at 33 kB/s
FSRW pgetc 127 kB in 3195 ms at 39 kB/s
Thanks for testing, Mike! Could you do me a favor and check the cluster size again? The quoted test is reporting a 4KB cluster size.
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
I have to provide OMU with a filesystem, the problem is that FAT is not at all useful for unix and it is written in Spin and I will call it from assembler. All that is simply messy, calling spin from assembler using the wait for "command" method. So I was thinking of integrating the block driver together with the filesystem, at least reading to load the kernel image. Now my dilemma is which kind of filesystem ?. I'm doing most of this development in Mac OSX so the only alternative would be Apple's UFS if I get enough info about it... If I were in linux it would be ext2 or maybe minix. While there is a ext2 implementation for Mac OSX it proved unstable when the filesystem was uncleanly unmouted, something that seems to happen quite often with thumb drives, even if I use the unmount command every time ! [noparse]:([/noparse]
Scratch what I said, I will implement a filesystem in 68K assembly/C and use the propeller to only provide blocks.
Now a question: The size of the card is never checked. What happens if the fs is bigger than the card size ?. Block numbers are never checked for validity.
Gosh Ale I forgot about your 68000/Prop and OMU. How is it going?
Why not write one big contiguous file to a FAT formatted card to hold the OMU file system?. Like Cluso does for CP/M.
Or Kye has an SD driver with support for partitions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Well it is not going that fast as I have to develop the Propeller parts: Video (text) is working, ROM emulation too.
IO prop is well a bit skinny: Serial does not seem to work yet, keyboard does and SD well I'm implementing it now.
On the 68K side I'm doing a loader for kernel but without the rest it just cannot progress.
The hardware works, the soft needs. I am on it. I want to see it working. With 4 megs RAM loads can be done if I get a working loader... let's see. I'll post progress as soon as something is working (morethan prinitng on a monitor...)
I just noticed something very strange... The new fsrw hangs on "mount_explicit" unless the SD is first mounted with the old version!
What it the world is causing that?
I need to make sure I'm using the right versions of files here...
Rayman said...
I just noticed something very strange... The new fsrw hangs on "mount_explicit" unless the SD is first mounted with the old version!
What it the world is causing that?
I need to make sure I'm using the right versions of files here...
Hi, Rayman.
To be clear, if you cycle the power on the board or eject/re-insert the card and run our test code it hangs? I think the only reasons it could really hang in the block layer are:
1: I have a waitcnt...I can't think it would be an issue unless you were using RCSLOW
2: Maybe the cog did not start for some reason?
3: A command timeout is failing (e.g. readblock or writeblock)
I'm attaching a special version of mb_spi.spin. It gives extra clock pulses to the card on init, and it has extra checks to trap the cog not initializing in a timely fashion. You should see _some_ kind of response within 8 seconds. Please use the fsrw.spin from the fsrw22.zip, and this mb_spi.spin file. Please try the test.spin after a power cycle, and then a few more times back to back. If that fails please post the log (unless it just hangs again!), and i it succeeds please try it then in your PSM audio test app.
thanks, and sorry about this,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Test results for fsrw2.2. Parallax Demo Board @ 80Mhz
Kodak 2GB MicroSD Card #1
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3215 ms at 1234 kB/s
Raw read 1920 kB in 2093 ms at 917 kB/s
fsrw pwrite 2016 kB in 3228 ms at 624 kB/s
fsrw pread 2016 kB in 3292 ms at 612 kB/s
FSRW pputc 63 kB in 2136 ms at 29 kB/s
FSRW pgetc 63 kB in 1895 ms at 33 kB/s
All done!
***********************************************
Kodak 2GB MicroSD Card #2
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62294
Raw write 3968 kB in 3241 ms at 1224 kB/s
Raw read 1920 kB in 2093 ms at 917 kB/s
fsrw pwrite 2016 kB in 3236 ms at 623 kB/s
fsrw pread 2016 kB in 3286 ms at 613 kB/s
FSRW pputc 63 kB in 2269 ms at 27 kB/s
FSRW pgetc 63 kB in 1890 ms at 33 kB/s
All done!
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3258 ms at 1217 kB/s
Raw read 1920 kB in 2094 ms at 917 kB/s
fsrw pwrite 2016 kB in 3181 ms at 633 kB/s
fsrw pread 2016 kB in 3289 ms at 612 kB/s
FSRW pputc 63 kB in 2136 ms at 29 kB/s
FSRW pgetc 63 kB in 1895 ms at 33 kB/s
All done!
I'll rerun tests at 100Mhz later today.
NOTE: This test did require pullups (used 20K). I could only get it to run about 1 out of 20 tries without them.
(The older fsrw_speed.spin (4_1_2009) work every time without the pullups.)
That's what I'm seeing... Somehow something needs initializing by the old code before the new one will work...
Guess I didn't notice before because the app in EEPROM starts the old fsrw...
Tried you file, but still hangs on trying to mount...
PRI busy_slow : r
' send out a multiple of 8 clocks
read_32_slow
text.str(string("j"))
' then check
repeat while r <> $FF
r := read_slow
text.str(string("k"))
if( (cnt - SPI_block_index) > (clkfreq << 2) )
text.str(string("l"))
crash( ERR_CARD_BUSY_TIMEOUT )
Added some text output to trace the problem...· I see a lot of k's flying by and then one l...
I can get to work by skipping the busy check like this:
PRI busy_slow : r
' send out a multiple of 8 clocks
read_32_slow
text.str(string("j"))
' then check
return <------------------ It works if we don't really check...
NOTE: This test did require pullups (used 20K). I could only get it to run about 1 out of 20 tries without them.
(The older fsrw_speed.spin (4_1_2009) work every time without the pullups.)
Jim
Thanks, Jim. I am currently tristating the pins between when the Spin code does the initialization, and when it hands those pins off to assembly engine for data transfer. I will work out a more robust handshake which does not require the tristating in the interim.
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Rayman said...
I can get to work by skipping the busy check like this:
PRI busy_slow : r
' send out a multiple of 8 clocks
read_32_slow
text.str(string("j"))
' then check
return <------------------ It works if we don't really check...
Ouch! If the card is ready to accept a command it should be outputting all 1's.Can you do me a favor? Change the "busy_slow" routine to look like this:
PRI busy_slow : r
' send out a multiple of 8 clocks
text.dec( read_32_slow )
text.str(string("j"))
' then check
repeat while r <> $FF
r := read_slow
text.dec( r )
text.str(string(","))
if( (cnt - SPI_block_index) > (clkfreq << 2) )
text.str(string("T"))
crash( ERR_CARD_BUSY_TIMEOUT )
That should log all the values that come back (though there may be a billion of them in 4 seconds). Hopefully whatever is coming back from the card will give me a clue as to what state the card is in. If the log is huge, could you zip it up and email it to my gmail account (same username as on this board)?
Is the timeout occurring the very first time the CMD0 is issued? If the app is aborting, the test output log should have a list of Commands and Responses, that would be helpful to browse. If the first CMD0 is causing the hang, then there will be no Command => Response log.
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Hmm...· That's probably my issue too!· I don't have any pull-ups...
lonesock said...
hover1 said...
NOTE: This test did require pullups (used 20K). I could only get it to run about 1 out of 20 tries without them.
(The older fsrw_speed.spin (4_1_2009) work every time without the pullups.)
Jim
Thanks, Jim. I am currently tristating the pins between when the Spin code does the initialization, and when it hands those pins off to assembly engine for data transfer. I will work out a more robust handshake which does not require the tristating in the interim.
Tried that code and it filled the screen with zeros...
Sorry, I don't have an easy way to do a log file (without the SD card [noparse]:)[/noparse]
Is the timeout occurring the very first time the CMD0 is issued? If the app is aborting, the test output log should have a list of Commands and Responses, that would be helpful to browse. If the first CMD0 is causing the hang, then there will be no Command => Response log.
OK, here's the update: Attached to this post I'm including a new version of mb_spi.spin, which I'm asking anyone who can to try out. Here's what's different.
-- There are extra debug checks (long aligned raw block access, etc.), so this version will be slower (maybe about 10% slower)
-- I worked over the handing of the reins (pins) from the Spin init sequence to the PASM block driver, no tristating, so hopefully it works without pullup resistors now (thanks for the heads-up, Jim!)
-- I modified the send command structure for Rayman, hopefully it works now
-- I modified the "stop" behavior of the block layer to specifically exit the current multiblock mode. Some cards simply refuse to be re-initialized if the card's state was interrupted during a read or write in multiblock mode. Of the 7 cards I have available for testing, 6 will re-init using the current sequence, but one will not. Adding in this exit code is probably just common courtesy for the card [noparse][[/noparse]8^). (btw, I could not find any documentation on re-initializing a card left in multiblock mode. The recommended procedure in both the SD and MMC specs just don't work, hence the current init sequence which attempts in special cases to stop read and write modes). Anyway, now if you call mb_spi's stop routine, or fsrw's unmount routine, the block layer will leave the card in a nice pristine state.
Thanks for your patience, everyone. If this test version works on everybody's setup, then I'll start stripping out the extraneous debug info and bring the speed back up.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
OK, here's the update: Attached to this post I'm including a new version of mb_spi.spin, which I'm asking anyone who can to try out. Here's what's different.
-- There are extra debug checks (long aligned raw block access, etc.), so this version will be slower (maybe about 10% slower)
-- I worked over the handing of the reins (pins) from the Spin init sequence to the PASM block driver, no tristating, so hopefully it works without pullup resistors now (thanks for the heads-up, Jim!)
-- I modified the send command structure for Rayman, hopefully it works now
-- I modified the "stop" behavior of the block layer to specifically exit the current multiblock mode. Some cards simply refuse to be re-initialized if the card's state was interrupted during a read or write in multiblock mode. Of the 7 cards I have available for testing, 6 will re-init using the current sequence, but one will not. Adding in this exit code is probably just common courtesy for the card [noparse][[/noparse]8^). (btw, I could not find any documentation on re-initializing a card left in multiblock mode. The recommended procedure in both the SD and MMC specs just don't work, hence the current init sequence which attempts in special cases to stop read and write modes). Anyway, now if you call mb_spi's stop routine, or fsrw's unmount routine, the block layer will leave the card in a nice pristine state.
Thanks for your patience, everyone. If this test version works on everybody's setup, then I'll start stripping out the extraneous debug info and bring the speed back up.
Test Results - Proto Board - 100Mhz - NO PULLUPS· (My first 100 MHz Program!!) PNY 2 GB MicroSD
Clock: 100000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 2855 ms at 1389 kB/s
Raw read 3968 kB in 3493 ms at 1135 kB/s
fsrw pwrite 2016 kB in 2710 ms at 743 kB/s
fsrw pread 2016 kB in 2649 ms at 760 kB/s
FSRW pputc 127 kB in 3435 ms at 36 kB/s
FSRW pgetc 127 kB in 3054 ms at 41 kB/s
All done!
*********************************************** Kodak 2GB MicroSD #1
Clock: 100000000 ClusterSize: 32768 ClusterCount: 62294
Raw write 3968 kB in 2915 ms at 1361 kB/s
Raw read 3968 kB in 3494 ms at 1135 kB/s
fsrw pwrite 2016 kB in 2695 ms at 747 kB/s
fsrw pread 2016 kB in 2647 ms at 761 kB/s
FSRW pputc 127 kB in 3578 ms at 35 kB/s
FSRW pgetc 127 kB in 3049 ms at 41 kB/s
*********************************************** Kodak 2GB MicroSD #2
Clock: 100000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 2866 ms at 1384 kB/s
Raw read 3968 kB in 3493 ms at 1135 kB/s
fsrw pwrite 2016 kB in 2597 ms at 776 kB/s
fsrw pread 2016 kB in 2653 ms at 760 kB/s
FSRW pputc 127 kB in 3438 ms at 36 kB/s
FSRW pgetc 127 kB in 3054 ms at 41 kB/s
Flawless @ 100 MhZ!!!· YipEEE
Jim
lonesock said...
Hi, All.
OK, here's the update: Attached to this post I'm including a new version of mb_spi.spin, which I'm asking anyone who can to try out. Here's what's different.
Thanks for your patience, everyone. If this test version works on everybody's setup, then I'll start stripping out the extraneous debug info and bring the speed back up.
Comments
significantly helps the case of writing a file when the volume has a lot of space already, and also speeds up
all the "pwrite" numbers by a nontrivial percentage).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
license to use for all ObEx code. I thought it was the MIT license.
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Now a question: The size of the card is never checked. What happens if the fs is bigger than the card size ?. Block numbers are never checked for validity.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Why not write one big contiguous file to a FAT formatted card to hold the OMU file system?. Like Cluso does for CP/M.
Or Kye has an SD driver with support for partitions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
IO prop is well a bit skinny: Serial does not seem to work yet, keyboard does and SD well I'm implementing it now.
On the 68K side I'm doing a loader for kernel but without the rest it just cannot progress.
The hardware works, the soft needs. I am on it. I want to see it working. With 4 megs RAM loads can be done if I get a working loader... let's see. I'll post progress as soon as something is working (morethan prinitng on a monitor...)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
What it the world is causing that?
I need to make sure I'm using the right versions of files here...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Post Edited (Rayman) : 7/19/2009 1:01:18 PM GMT
To be clear, if you cycle the power on the board or eject/re-insert the card and run our test code it hangs? I think the only reasons it could really hang in the block layer are:
1: I have a waitcnt...I can't think it would be an issue unless you were using RCSLOW
2: Maybe the cog did not start for some reason?
3: A command timeout is failing (e.g. readblock or writeblock)
I'm attaching a special version of mb_spi.spin. It gives extra clock pulses to the card on init, and it has extra checks to trap the cog not initializing in a timely fashion. You should see _some_ kind of response within 8 seconds. Please use the fsrw.spin from the fsrw22.zip, and this mb_spi.spin file. Please try the test.spin after a power cycle, and then a few more times back to back. If that fails please post the log (unless it just hangs again!), and i it succeeds please try it then in your PSM audio test app.
thanks, and sorry about this,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Test results for fsrw2.2. Parallax Demo Board @ 80Mhz
Kodak 2GB MicroSD Card #1
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3215 ms at 1234 kB/s
Raw read 1920 kB in 2093 ms at 917 kB/s
fsrw pwrite 2016 kB in 3228 ms at 624 kB/s
fsrw pread 2016 kB in 3292 ms at 612 kB/s
FSRW pputc 63 kB in 2136 ms at 29 kB/s
FSRW pgetc 63 kB in 1895 ms at 33 kB/s
All done!
***********************************************
Kodak 2GB MicroSD Card #2
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62294
Raw write 3968 kB in 3241 ms at 1224 kB/s
Raw read 1920 kB in 2093 ms at 917 kB/s
fsrw pwrite 2016 kB in 3236 ms at 623 kB/s
fsrw pread 2016 kB in 3286 ms at 613 kB/s
FSRW pputc 63 kB in 2269 ms at 27 kB/s
FSRW pgetc 63 kB in 1890 ms at 33 kB/s
All done!
****************************************************
PNY 2GB MicroSD Card
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3258 ms at 1217 kB/s
Raw read 1920 kB in 2094 ms at 917 kB/s
fsrw pwrite 2016 kB in 3181 ms at 633 kB/s
fsrw pread 2016 kB in 3289 ms at 612 kB/s
FSRW pputc 63 kB in 2136 ms at 29 kB/s
FSRW pgetc 63 kB in 1895 ms at 33 kB/s
All done!
I'll rerun tests at 100Mhz later today.
NOTE: This test did require pullups (used 20K). I could only get it to run about 1 out of 20 tries without them.
(The older fsrw_speed.spin (4_1_2009) work every time without the pullups.)
Jim
Post Edited (hover1) : 7/19/2009 4:17:12 PM GMT
That's what I'm seeing... Somehow something needs initializing by the old code before the new one will work...
Guess I didn't notice before because the app in EEPROM starts the old fsrw...
Tried you file, but still hangs on trying to mount...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
tmp := send_cmd_slow( CMD0, 0, $95 )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
PRI busy_slow : r ' send out a multiple of 8 clocks read_32_slow text.str(string("j")) ' then check repeat while r <> $FF r := read_slow text.str(string("k")) if( (cnt - SPI_block_index) > (clkfreq << 2) ) text.str(string("l")) crash( ERR_CARD_BUSY_TIMEOUT )Added some text output to trace the problem...· I see a lot of k's flying by and then one l...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
PRI busy_slow : r ' send out a multiple of 8 clocks read_32_slow text.str(string("j")) ' then check return <------------------ It works if we don't really check...▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
PRI busy_slow : r ' send out a multiple of 8 clocks text.dec( read_32_slow ) text.str(string("j")) ' then check repeat while r <> $FF r := read_slow text.dec( r ) text.str(string(",")) if( (cnt - SPI_block_index) > (clkfreq << 2) ) text.str(string("T")) crash( ERR_CARD_BUSY_TIMEOUT )That should log all the values that come back (though there may be a billion of them in 4 seconds). Hopefully whatever is coming back from the card will give me a clue as to what state the card is in. If the log is huge, could you zip it up and email it to my gmail account (same username as on this board)?
Is the timeout occurring the very first time the CMD0 is issued? If the app is aborting, the test output log should have a list of Commands and Responses, that would be helpful to browse. If the first CMD0 is causing the hang, then there will be no Command => Response log.
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Sorry, I don't have an easy way to do a log file (without the SD card [noparse]:)[/noparse] ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
OK, here's the update: Attached to this post I'm including a new version of mb_spi.spin, which I'm asking anyone who can to try out. Here's what's different.
-- There are extra debug checks (long aligned raw block access, etc.), so this version will be slower (maybe about 10% slower)
-- I worked over the handing of the reins (pins) from the Spin init sequence to the PASM block driver, no tristating, so hopefully it works without pullup resistors now (thanks for the heads-up, Jim!)
-- I modified the send command structure for Rayman, hopefully it works now
-- I modified the "stop" behavior of the block layer to specifically exit the current multiblock mode. Some cards simply refuse to be re-initialized if the card's state was interrupted during a read or write in multiblock mode. Of the 7 cards I have available for testing, 6 will re-init using the current sequence, but one will not. Adding in this exit code is probably just common courtesy for the card [noparse][[/noparse]8^). (btw, I could not find any documentation on re-initializing a card left in multiblock mode. The recommended procedure in both the SD and MMC specs just don't work, hence the current init sequence which attempts in special cases to stop read and write modes). Anyway, now if you call mb_spi's stop routine, or fsrw's unmount routine, the block layer will leave the card in a nice pristine state.
Thanks for your patience, everyone. If this test version works on everybody's setup, then I'll start stripping out the extraneous debug info and bring the speed back up.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
All done!
Nice work Jonathan!
Haven't got a chance to do 100 Mhz tests yet.
Jim
PNY 2 GB MicroSD
Clock: 100000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 2855 ms at 1389 kB/s
Raw read 3968 kB in 3493 ms at 1135 kB/s
fsrw pwrite 2016 kB in 2710 ms at 743 kB/s
fsrw pread 2016 kB in 2649 ms at 760 kB/s
FSRW pputc 127 kB in 3435 ms at 36 kB/s
FSRW pgetc 127 kB in 3054 ms at 41 kB/s
All done!
***********************************************
Kodak 2GB MicroSD #1
Clock: 100000000 ClusterSize: 32768 ClusterCount: 62294
Raw write 3968 kB in 2915 ms at 1361 kB/s
Raw read 3968 kB in 3494 ms at 1135 kB/s
fsrw pwrite 2016 kB in 2695 ms at 747 kB/s
fsrw pread 2016 kB in 2647 ms at 761 kB/s
FSRW pputc 127 kB in 3578 ms at 35 kB/s
FSRW pgetc 127 kB in 3049 ms at 41 kB/s
***********************************************
Kodak 2GB MicroSD #2
Clock: 100000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 2866 ms at 1384 kB/s
Raw read 3968 kB in 3493 ms at 1135 kB/s
fsrw pwrite 2016 kB in 2597 ms at 776 kB/s
fsrw pread 2016 kB in 2653 ms at 760 kB/s
FSRW pputc 127 kB in 3438 ms at 36 kB/s
FSRW pgetc 127 kB in 3054 ms at 41 kB/s
Flawless @ 100 MhZ!!!· YipEEE
Jim
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.