 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Pete Smith
Joined: 17 Sep 2003
Posts: 55
Location: Chester, UK
|
| OT: Possible to kill MMC card through software |
 Posted: Fri Apr 09, 2004 5:27 pm |
 |
|
Hi all.
I've been having some fun with my FAT code, which turned out to be a problem with my MMC code.
I'm using an 8k FRAM split into 512 byte chunks to buffer data to/from the MMC device.
On occasion, I'd find that there was corrupted data on the card, made up of old data.
I tracked this down to data not being written back to the card. This in turn was being caused by the card being put into write mode (command 0x58), but never responding to the command.
I "got round" this by re-issuing the command, and it all seemed to work (according to my debug!)
The problem now is that I can't access the card at all, either in my device, or in 1 of 2 different USB card readers.
As far as my device goes, it initialises the device as an MMC device in SPI mode, but all it can then read from the device is 0xFF.
I realised that I wasn't putting the card back into a sleep state (chip select & clock lines high) before trying to enter write mode again.
One other thing was that yesterday, the card was getting quite awkward to read. The activity light on the reader would come on once (should be a short on and then a long on). I'd put this down to getting superglue (cyano-acrylate) fumes on it, after putting the card into the device when there was glue around. This caused similar symptoms. A rub down with some fine wire-wool removed the glue. It would normally work after 2-4 removal/replace cycles.
The "dead" card will now only cause a single flash on the reader.
Does this sound like my code has killed the card, or is it possible that static damage/something else was causing the not being able to read, and occasional write failures?
Any ideas? A replacement card doesn't seem to show the same corrupted/missing data as the original. However, the fact that the device powers up points to the fact that the card is at least powering up and entering SPI mode.
I'm leaving it for 8 hours or so (from now, until the Dr Who omnibus tomorrow morning  ) to soak test. It should save ~32Mb of data in that time, which would show errors with the previous card. I'm logging all data to pick up any write failures.
Thanks,
Pete. |
|
 |
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Sat Apr 10, 2004 8:45 am |
|
|
Very rarely I have had one of these cards fail for hardware. They are however jast as vunerable to the same curruptions as hard drives get. If the boot sector of the HDD gets currupted the drive is unusable without a low level format same with the MMC. If using FAT there are further vunerablities in the allocation tables and directory entries. Try a low level format ( fdisk is what's needed but it is not available for MMC). I've used disk recovery software running under windows to reform a corrupted MMC boot sector.
WinHex might also work. |
|
|
Pete Smith
Joined: 17 Sep 2003
Posts: 55
Location: Chester, UK
|
|
| Posted: Sun Apr 11, 2004 2:25 am |
|
|
| Douglas Kennedy wrote: | Very rarely I have had one of these cards fail for hardware. They are however jast as vunerable to the same curruptions as hard drives get. If the boot sector of the HDD gets currupted the drive is unusable without a low level format same with the MMC. If using FAT there are further vunerablities in the allocation tables and directory entries. Try a low level format ( fdisk is what's needed but it is not available for MMC). I've used disk recovery software running under windows to reform a corrupted MMC boot sector.
WinHex might also work. |
Thanks. I've tried WinHex, but Windows can't even see the drive.
I also have had cards in the past which have had corrupted boot sectors (due to a maths problem, which put data over the boot sector  ), but that card would still read/write data, it was a FAT corruption issue. To get round it, I filled the first sector with zeroes. The PC reader then realised it was unformatted, and offered to format it for me. This then gave more problems, because I'd written my firmware for the card as it arrived (which was actually partitioned). Windows removed the partition information, and just gave me a single partition with no table - so my code fell over!
When I put my device into diagnostic mode, the card powers up, it goes into SPI mode, and sending the ID commands sends _some_ data back (so the card functionsl on some electrical level), but if I then try to read the card, I only receive 0xFF, and if I try to write to the card (this is a low level write, not FAT based), then the software falls over, because the card doesn't respond to the write command.
If I then replace this card with another card, and run the test above, it works perfectly.
I suppose the card may have been put into write-protect mode somehow, but given it was giving me sporadic write failures above a certain address (and the previous and subsequent cards _don't_), I'm not sure the card is (or even should be) recoverable.
Thanks for the advice,
Pete. |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Sun Apr 11, 2004 10:29 am |
|
|
This may well be that you have a defective card...I'm sure you already aware of these issues but here they are just in case
You have to poll the card for the token before sending it the data to write.
The write can't cross a 512 sector boundary without the write being split up first.
There is variability in the number times you have to poll the cards before they return the token that permits the next action ( such as read or write). There is no minimum time certain you can wait before initiating an I/O command I believe you must poll until you get the permission. The controller on the MMC has its own things to do and won't give you I/O clearance until it is ready. On average the poll is answered right away but rarely the MMC card needs some major error (eg bad sector ) correction type stuff so the behind the scene built in MMC controller starts rearranging the card and can't accept another I/O request for the next few polls and returns not ready until done.
The "tiny softees" ( I don't want to mention their actual name since to do so requires a lot of legal disclosure ) have an imperfect way of deciding based on the geometry described in the boot sector to determine if a 12 bit or 16 bit file allocation table format is needed. It is certian below 16 mb and certain above 16mb but not as definite around 16mb. This would affect the ability to see the disk in windows but I suspect winhex would still see it as a 80h type device |
|
|
Pete Smith
Joined: 17 Sep 2003
Posts: 55
Location: Chester, UK
|
|
| Posted: Sun Apr 11, 2004 1:27 pm |
|
|
| Douglas Kennedy wrote: | This may well be that you have a defective card...I'm sure you already aware of these issues but here they are just in case
You have to poll the card for the token before sending it the data to write.
The write can't cross a 512 sector boundary without the write being split up first.
There is variability in the number times you have to poll the cards before they return the token that permits the next action ( such as read or write). There is no minimum time certain you can wait before initiating an I/O command I believe you must poll until you get the permission. The controller on the MMC has its own things to do and won't give you I/O clearance until it is ready. On average the poll is answered right away but rarely the MMC card needs some major error (eg bad sector ) correction type stuff so the behind the scene built in MMC controller starts rearranging the card and can't accept another I/O request for the next few polls and returns not ready until done.
The "tiny softees" ( I don't want to mention their actual name since to do so requires a lot of legal disclosure ) have an imperfect way of deciding based on the geometry described in the boot sector to determine if a 12 bit or 16 bit file allocation table format is needed. It is certian below 16 mb and certain above 16mb but not as definite around 16mb. This would affect the ability to see the disk in windows but I suspect winhex would still see it as a 80h type device |
Thanks for the additional advice...
I realise the card doesn't always return control instantly. The specs say 8 cycles, but TBH, quite a few times, I have to wait 16 cycles before I get control (this is controlled via a define in my code, so it's easy to change!)
The card is a FAT16 formatted 64Mb card.
I originally thought that my code was at fault, because the initial code (worked perfectly!) was streamlined to make it look & feel a little more straightforward (eg rather than writing a byte & then manually calculating the pages etc, I wrote a f_putc() function, which makes code look neater.
It was only at this point (along with new hardware) that the problem showed itself. The original code has been running solidly for 6 months with no problems, other than a strangely formatted FAT16 card that my code could only write to 0x200 out of 0x800 bytes - giving 3/4 of the data as crap. A re-format under WinXP solves the problem.
I'd put it down to my code/hardware being at fault (because code space is tight, I never really put full error checking in - I never assumed a write wouldn't happen!), Until the card died completely, I thought the problem was me! New card, new hardware, new code=problems. Another new card=all working.
FWIW, plugging the card into the reader, and letting WinHEX have a go gives "An error occurred while accessing "Drive H:".
I realise about the 512 byte boundaries too. I'm using a FRAM to give 4 1 sector buffers, so if I need to do any R/W I/O to the card, the FRAM takes it all. Once I move outside the boundaries of the current page, it transparently pages the memory back to the card, and then pages the new sector in.
Once I've dug through all the other bugs in my code (!) I'm going to do a separate application which just tries to write all zeroes to the device, and see how it responds (on a byte transferred level).
Thanks again,
Pete. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
