SD Card – SD Card Not Accessible but Works in an Old Nokia

debianlinuxsd card

Background

I have two visually same 2GB microSD cards, both labeled
"SD-C02G JAPAN", under the "2GB microSD" logo.

My problem is that I can't read one of them in any device except an old
Nokia 5310 "XpressMusic". The phone is dying, by which I mean it's very hard to operate (dysfunctional keys, display going nuts), but the fact that
it can read/write the card leads me to believe that the card is not
broken (whatever that means).

(I'd like to believe that the card is dead and just toss it into the
garbage, but then I would have to live with questions like: why the old
Nokia still could read it?)

I should also mention that the card has probably been previously
encrypted by some technology in the Nokia phone (not the very same
machine, but another piece of the same model, which is dead now as
well.). ("Probably", because there are more cards in the house and
I know one of them has been encrypted, and since all other work
everywhere, I assume it was this one).

Methods / Outputs

Now other methods I tried with both cards (I'll mostly describe
the "bad" card behavior):

  • (A) two different Android phones, both telling that
    the card is not inserted at all, therefore not offering
    option to format

  • (B) A PC with Ubuntu 12.04 LTS (kernel 3.2.0-37-generic, x86_64)
    using a small Kingston USB-stick-sized microSD card reader

  • a laptop with Debian Wheezy (kernel 3.0.0.1-amd64), using

    • (C) same method as (B); lsusb tells me:

      Bus 001 Device 005: ID 14cd:121c Super Top microSD card reader

    • (D) a built-in, i.e. PCI SD reader (with help of microSD
      to SD adapter since the reader lacks a slot small
      enough); lspci tells me:

      15:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)

(A) does not give me any useful info, and as far as I can see (B) and
(C) behave the same. Therefore I will compare (C) and (D) with the
"good" and the "bad" card:

mkdosfs

With method (C) and "bad" card, mkdosfs says /dev/sdb: No medium
found. I did not try it with method (D); I find it pointless since the
device file does not exist at all. And I did not try with the "good"
card since I do not want to lose the data…

fdisk

  • When the "bad" card is mounted, (C) sudo fdisk -l /dev/sdb or
    (D) sudo fdisk -l /dev/mmcblk0 return nothing; in the latter case
    /dev/mmcblk0 does not exist.

  • For the "good" card, both outputs are as expected, after all
    the card is auto-mounted.

kern.log

  • method (C) and the "bad" card:

    usb 1-1: new high speed USB device number 7 using ehci_hcd
usb 1-1: New USB device found, idVendor=14cd, idProduct=121c
usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=2
usb 1-1: Product: Mass Storage Device
usb 1-1: Manufacturer: Generic
usb 1-1: SerialNumber: 812320090519
scsi9 : usb-storage 1-1:1.0
scsi 9:0:0:0: Direct-Access     USB Mass Storage Device        PQ: 0 ANSI: 0 CCS
sd 9:0:0:0: Attached scsi generic sg2 type 0
sd 9:0:0:0: [sdb] Attached SCSI removable disk

  • method (C) and the "good" card:

    usb 1-1: new high speed USB device number 8 using ehci_hcd
usb 1-1: New USB device found, idVendor=14cd, idProduct=121c
usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=2
usb 1-1: Product: Mass Storage Device
usb 1-1: Manufacturer: Generic
usb 1-1: SerialNumber: 812320090519
scsi10 : usb-storage 1-1:1.0
scsi 10:0:0:0: Direct-Access     USB Mass Storage Device        PQ: 0 ANSI: 0 CCS
sd 10:0:0:0: Attached scsi generic sg2 type 0
sd 10:0:0:0: [sdb] 3842048 512-byte logical blocks: (1.96 GB/1.83 GiB)
sd 10:0:0:0: [sdb] Write Protect is off
sd 10:0:0:0: [sdb] Mode Sense: 03 00 00 00
sd 10:0:0:0: [sdb] No Caching mode page present
sd 10:0:0:0: [sdb] Assuming drive cache: write through
sd 10:0:0:0: [sdb] No Caching mode page present
sd 10:0:0:0: [sdb] Assuming drive cache: write through
 sdb:
sd 10:0:0:0: [sdb] No Caching mode page present
sd 10:0:0:0: [sdb] Assuming drive cache: write through
sd 10:0:0:0: [sdb] Attached SCSI removable disk
FAT-fs (sdb): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!

  • method (D) and the "bad" card:

    mmc0: error -110 whilst initialising SD card
[...10 secs later...]
mmc0: Timeout waiting for hardware interrupt.
sdhci: =========== REGISTER DUMP (mmc0)===========
sdhci: Sys addr: 0x00000000 | Version:  0x00000400
sdhci: Blk size: 0x00000000 | Blk cnt:  0x00000000
sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
sdhci: Present:  0x01ff0001 | Host ctl: 0x00000001
sdhci: Power:    0x00000000 | Blk gap:  0x00000000
sdhci: Wake-up:  0x00000000 | Clock:    0x00000000
sdhci: Timeout:  0x00000009 | Int stat: 0x00000000
sdhci: Int enab: 0x00ff00c3 | Sig enab: 0x00ff00c3
sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
sdhci: Caps:     0x01e021a1 | Caps_1:   0x00000000
sdhci: Cmd:      0x00000102 | Max curr: 0x00000040
sdhci: Host ctl2: 0x00000000
sdhci: ===========================================
mmc0: Got command interrupt 0x00030000 even though no command operation was in progress.
sdhci: =========== REGISTER DUMP (mmc0)===========
sdhci: Sys addr: 0x00000000 | Version:  0x00000400
sdhci: Blk size: 0x00000000 | Blk cnt:  0x00000000
sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
sdhci: Present:  0x01ff0000 | Host ctl: 0x00000001
sdhci: Power:    0x00000000 | Blk gap:  0x00000000
sdhci: Wake-up:  0x00000000 | Clock:    0x00000000
sdhci: Timeout:  0x00000009 | Int stat: 0x00000000
sdhci: Int enab: 0x00ff00c3 | Sig enab: 0x00ff00c3
sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
sdhci: Caps:     0x01e021a1 | Caps_1:   0x00000000
sdhci: Cmd:      0x00000102 | Max curr: 0x00000040
sdhci: Host ctl2: 0x00000000
sdhci: ===========================================

    This repeats 4 times (including the 10s delay).

  • method (D) and the "good" card:

    mmc0: new high speed SD card at address ef87
mmcblk0: mmc0:ef87 SD02G 1.83 GiB 
 mmcblk0:
FAT-fs (mmcblk0): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!

Question

Can anybody explain what is wrong with this card? Or at least what
kern.log is showing?

Could the encryption corrupt the card? If so, why can't I simply
re-format it? (I'm OK with blasting the content.)

Or, what other methods of debugging would you suggest?

Best Answer

Short answer

The card is password-protected. (@derobert's guess is right.) And kernel modules do not provide useful pointers to this.

TL;DR:

I was suspecting this but I did not know that it's a SD-specific hardware feature; I thought that the Nokia simply encrypts the partition which I would be able to solve by action like mkdosfs /dev/sdb or such.

Too bad that:

  • it seems that this function is widely unsupported by current Linux modules (not even to the point of giving an useful error). Presumably this applies to mentioned Androids as well

  • the phone refuses to format the card and remove the password. You can either remove the password, but you need to know the old one, or format the card, but that will not remove the password

So maybe other firmware has option to wipe it completely, but this is another question for another forum.

Funny background note:

While I was attending to collecting the data above, my old man (user of the phone/cards, born '45), took the old-school approach and fixed the "dying" phone by cleaning it with piece of cloth and ethanol!

This magical-sealed-computer-driven-gadget age: 0 My dad: 1 ;-D

Point is that I am now able to verify that the password has been set (and compare to the "good" card). Who and how did it, will remain a mystery.

Related Question