SD card problems

stevenmess2004

My sd card holder broke again awhile ago and I finally got around to making another one. And now the sd card isn't working... Before I go putting another one card in there is it safe? As far as I can see the power is wired up to the right places and the right polarity (checked with multimeter) and there are no shorts between any of the pins. Now before I tried the card with the propeller it basically caused finder on my mac to crash when I tried to delete some files on it (possible indication that the card died?).

When I run the test.spin included with fsrw2.5 it times out on line 209 (or around there, I may have deleted some white space) in mb_rawb_spi.spin which is

repeat while send_cmd_slow( ACMD41, 0, $E5 )

If I'm reading the code properly than by then the card has already responded with a 1 as part of the setup sequence so does that mean that the wiring is fine and the card is just dead?

MagIO2

If your wiring is ok, then it should be impossible to fry a SD card. Of course you can destroy the content (for example the FAT and the CLUSTER-table). With the wrong changes in the cluster-table the deletion might be impossible. So, first I'd try to format the old card. (Can it be formatted with FAT32 on a MAC?).

What card is it? Brand? Size? Really a SD card? ( I think there is a old card format [noparse][[/noparse]?MultiMediaCard?] with the same format and usually SD card readers can read them, but they don't understand the ACMDxx commands.

heater

Impossible to fry perhaps but odd things have happened to my SD cards.
For example I have one that has some write protected blocks at the beginning now. I can read write any other blocks using dd under Linux but cannot format the thing.
If anyone knows how to remove write protection from SD blocks I'd be very interested.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Peter Jakacki

The PROGRAM_CSD command (SD specifications) allows temporary and permanent write-protection to be set for "groups" the size of which is read from the CSD register (bits 31..38). If the permanent bit has been set then it's permanent. Although I have written low-level drivers on other micros I am just using fsrw on the Prop and I'm not sure off the top of my head whether you can access this easily from the routines although the lower level spi routines must do so during card initialization prior to mounting.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

rokicki

Well, first try with a different card. That's the bare minimum.

If finder crashes with a bad SD card, that's pretty bogus on finder's part. But in any case, yes, it sounds like that
card had its filesystem structure destroyed.

Note that even with all the best efforts on fsrw's part, a buggy program can corrupt fsrw's variables causing the
card to have inconsistent data structures. (The hardware of the card is fine, but the filesystem is broken). In
such a case, the only fix is a reformat (with data loss).

I would be very surprised if somehow fsrw, even when corrupted, would be able to set the necessary card bits
to "write protect" some sectors. But this should be easy to investigate and/or correct, using the SD spec and
some of the low-level sdspi routines to query/update the card. At some point, though, you have to decide if
it's worth the investigation, or perhaps a new card should just be purchased. But if this problem does recur, it
should be investigated.

Note that some older versions of fsrw would create "bad" empty files; if you created an empty file, or a program
crashed before filling out the first sector of a new file, the card would indeed have an inconsistent structure.
This inconsistent structure was consistent for fsrw, and for some other programs, but not all, and may cause
the sort of thing you saw (crash on deletion). The recent fsrw's (probably 2.3 and later, but it's in the change
list) do not have this problem.

heater

I already decided not to spend time investigating my card with protected blocks. I have other cards and not much time. I was really fishing for some existing utility for Linux or Windows that allows checking and modifying this kind of protection. The only thing I have found so far is an SD formatting utility, from Panasonic I think, which just fails saying some blocks are write protected.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

stevenmess2004

Well, I tried with a new card and it worked fine. The old card was a DSE 1GB card. Here's hoping it doesn't happen again [noparse]:)[/noparse]

The finder didn't actually crash, just the delete process froze and then it wouldn't close... On a windows machine explorer froze and then wouldn't restart. So the mac slightly won...