Debugger and FSRW not playing well :(

omgitsaliv55

Hey everyone,

I'm doing a project where I need to read and write to SD, SDHC, and/or MMC cards. I'm actually writing my own FAT32 object for the project, as the latest FSRW FAT16/32 driver isn't adequate for everything I need it to do (on top of this I'd like to actually learn how FAT works [noparse]:D[/noparse] ). I have, however, been using the sdspiqasm object that FSRW uses because re-writing that would just be reinventing the wheel.

Unfortunately, I'm running into a problem where when my board is plugged into the computer and I am using a Type 2 SD card the SD driver freezes up EVERY OTHER power cycle (so flipping the power switch off and back on solves the problem, but if I do it again it freezes up). After hours of debugging, I found that sdspiqasm was reporting card timeouts.

The problem doesn't occur when I use Type 1 SD cards, SDHC cards, or MMC cards, OR when I unplug the Propeller from the computer. Simply pushing reset also doesn't induce it...the power must be cycled.

Here is what I need to know:

Is there anything that happens between the Propeller and the computer that would cause timing issues every other power cycle?

Any and all help is appreciated, as this is making development difficult!

Thanks!

Mike Green

No. There is no memory of what goes on the previous power cycle. When you cycle power to the Propeller, all of the cogs and the hub are reset. Hub registers should become zero if you wait long enough. There's no spec on how long that takes. The cogs are completely initialized when they're started for the first time. I don't know how the Type 2 SD cards initialize themselves on power on.

omgitsaliv55

Thanks Mike! This is good to know, but also asserts that the problem is unrelated to PC connection. If this were true then the problem would occur regardless of any connection to a PC which is not at all whats going on. I can even have the Prop Plug plugged in but disconnected from the PC without the problem being triggered.

I should note that I did modify the sdspiqasm code to not perform an abort everytime a problem is found, but rather simply return an error code to my FAT32 object. That way the program doesn't just stop if, say, no SD card was inserted. I did test to make sure that my modifications weren't causing the error by using an unmodified version of the program and found that it made no difference.

I'll poke around more and see what I find

lonesock

omgitsaliv55 said...
...I have, however, been using the sdspiqasm object that FSRW uses because re-writing that would just be reinventing the wheel...

sdspiqasm is quite old. I recommend using the "safe_spi.spin" block driver from the latest FSRW 2.6 release.

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

omgitsaliv55

That actually is what I'm using. I figured safe_spi was just an updated version of sdspiqasm, since it did most of the same stuff just with SDHC and MMC support. Now that you mention it though, I am curious to know if the actual sdspiqasm (1.6 version) has this problem as well.

mpark

Sounds like the same problem YorkBW had:
http://forums.parallax.com/showthread.php?p=824166

Turned out that "off" wasn't really off. The USB connection was supplying just enough power to keep the SD card confused.