micro SD persistently slower after programming and reboot

A micro SD (sandisk 1GB) running in SPI mode, under linux, is (re)programmed by writing a 2MB image with dd and then the system is rebooted. Typically the sequence is:

dd if=firmware.bin of=/dev/sda1 sync ; sync; sync reboot

The anomaly is that every so often after reboot the microSD appears to be locked into some mode where I can only read my binary image correctly, in /dev/sda1, by increase the time between initiating commands ( the delay was obtained by dumping response bytes from the SPI to the UART ). Note that I'm already writing additional 0xff to the SPI in order to generate extra clock cycles in the microSD.

Note that the content in the micro SD appears correct. I can read correct content with a USB card reader.

Any help is appreciated.

Reply to
thetalkingblob
Loading thread data ...

How much slower is the read? Are you talking about microsecononds, milliseconds, or seconds?

Is the delay in the read routine after you set the card into SPI mode, or does it occur when you first set the card into SPI mode?

What does your OS do on a reboot? Is the reboot the result of a power cycle or simply a processor reset?

Are you using a fixed delay between commands, or are you polling for a proper response before sending the next command?

I've found a lot of variability in the response time of cards from the same manufacturer and the same size. I wonder if it is due to some internal housekeeping that the card's processor does at startup.

Mark Borgerson

Reply to
Mark Borgerson

Seconds, but that's because I dump all the response bytes and some sector reads ( command + rx block + status ) to the UART.

It's only while I'm reading a specific partition. I have an MBR and two partitions; the MBR is read without delay and appears to be read correctly from my observation so far; the seconds partition which is a file system is accessible without any 'extra' delays. It's the first partition that is written with the 'dd' command prior to the reboot.

There's a re-init of the SPI/SD and then it's typically a soft reboot ( processor reset ). Another vendor's microSD seems to require a restart when there's SDI/SDO activity on another chip select - I'm not clear on that one.

Polling for a proper status and sending an extra 0xff after it's received. Also, before any command, dummy 0xFF bytes are sent a couple of times.

The odd thing is that when these microSDs become locked-up in this 'slower' mode ; they may eventually become 'un-locked' after several accesses with the aforementioned read delays inserted.

Reply to
comp.arch.embedded

Does that mean that your OS doesn't have interrupt-driven UART IO? Is it actually waiting a UART byte or block transmit time between accesses to the SD card?

If you wait more than about 250mSec between accesses to the SD card, it may go back into the low-power mode. Most of the SanDisk cards I've used seem to have the default 250mSec timeouts on access.

On some of the SD card drivers I've seen, if the CPU can't get a good response after a number of tries, it goes all the way back to the initialization of the SPI mode. If that's happening the delays can be very long.

Mark Borgerson

Reply to
Mark Borgerson

The UART is only when the debugging is activated. Normally, with debugging off, there's nothing going onto the UART. It's while the debugging is on that the problem goes away.

Shouldn't it pop out of low-power mode once a command is issued to it? There should be a larger access time for the first command in order to take out of low-power mode.

I'll look into that one...

Reply to
comp.arch.embedded

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.