Death of my uSD card...

[anotherstevest]

Greetings,

I've been successfully running the Olinuxino Maxi with a uSD card pre-loaded with Archlinux (via Mouser) for a while.  I've periodically imaged it onto an Ubunto laptop (but not recently enough...).  I now appear to have killed it (it won't boot, the debug term shows repeating hex (0x80502008) just as it does with no card installed, and ubunto won't read it in the normal manner).

This uSD card was not one with the hologram.  The Maxi card is rev. B.  I *have* been power cycling with the serial debug attached and active.  Is that what killed it?  (I *thought* this was ok given I don't have a hologram on my uSD).  Are there known ways to kill the uSD that should be avoided?  I would like, very much, to not kill another one.

Any insight is appreciated!

Thanks,
Steve.

[jlumme]

As with all flash based memories, they wear out. Though the cycle count is high on these cards nowadays.. I have killed one SD card on beagleboard before, but it was running for about a year daily, and all the dmesg etc logs were writing on the card..

Anyway, if you have a "production machine", you might want to consider limit the amount of logging etc is written to the disk, or if it's connected to the network, maybe map a network drive and send your normal execution logs there...

[picmaster]

Try to list the available partitions on the microSD card:

Code Select Expand

sudo fdisk -l
This command lists all partitions on all available block devices. Here's what I see for my 4GB microSD:

Code Select Expand


Disk /dev/sdb: 3974 MB, 3974103040 bytes
123 heads, 62 sectors/track, 1017 cylinders
Units = cylinders of 7626 * 512 = 3904512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x21dc654e

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1           5       19034   53  OnTrack DM6 Aux3
/dev/sdb2               6         556     2100963   83  Linux

Look for a device with expected storage size (something like 4, 8GB, etc). Then try to manually mount the second partition (in my case it was /dev/sdb2) somewhere in your PC filesystem:

Code Select Expand


sudo mount /dev/sdb2 /mnt/tmp

...and see if there are any errors during mounting. You can also check the contents of the mounted partition. This way you can save any important information from the card to your Ubuntu box. If there's nothing important on the microSD, you can try to write clean boot/root partitions, and even re-create the partition table if it's damaged. If you consistently can't write in the MBR & partitions even with the Ubuntu, then maybe it's time to get new microSD and rethink your strategy with writing data to the FLASH memory.

Just FYI - it's practically possible to rework your Linux boot scripts in order to use the SD-card in read-only mode (I've done this with the Debian-based Olinuxino because in my application I can't shutdown cleanly the OS, the power is just removed and this causes issues with the FS), but such approach also adds some complexity later when used this way.

Hope this helps. Regards!

[Kean]

Steve,

I think the mention of only the hologrammed uSD cards being affected by the serial connected with power off is incorrect.  I've had a uSD (without the hologram) fail which I'm pretty sure was due to that problem, but no more issues since I started putting a schottky diode in-line with my serial debug cables.

FYI, the schotty diode avoids voltage leakage back through the debug receive line, which can be just enough to power up the CPU which attempts access to the uSD, but not enough power that the uSD can run properly - and it can corrupt its flash.

Also, I think many uSD cards (in fact most flash devices) are made so cheaply now that you should consider them "consumable".

Kean