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.

In article <81236047-701e-4679-80d8-837639fc1389
@m37g2000yqf.googlegroups.com>, thetalkingblob@gmail.com says...
> 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.
> 
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

On Mar 22, 5:29 pm, Mark Borgerson <mborger...@comcast.net> wrote:
> In article <81236047-701e-4679-80d8-837639fc1389
> @m37g2000yqf.googlegroups.com>, thetalkingb...@gmail.com says...
>
> > 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.
>
> How much slower is the read?   Are you talking about microsecononds,
> milliseconds, or seconds?
Seconds, but that's because I dump all the response bytes and some
sector reads ( command + rx block + status ) to the UART.
>
> 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?
>
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.

> What does your OS do on a reboot?  Is the reboot the result
> of a power cycle or simply a processor reset?
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.
>
> Are you using a fixed delay between commands, or are you polling
> for  a proper response before sending the next command?
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.
>
> 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

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.

In article <75f19f53-981e-41b6-a96b-23baf7684272
@v20g2000yqv.googlegroups.com>, thetalkingblob@gmail.com says...
> On Mar 22, 5:29 pm, Mark Borgerson <mborger...@comcast.net> wrote:
> > In article <81236047-701e-4679-80d8-837639fc1389
> > @m37g2000yqf.googlegroups.com>, thetalkingb...@gmail.com says...
> >
> > > 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.
> >
> > How much slower is the read?   Are you talking about microsecononds,
> > milliseconds, or seconds?
> Seconds, but that's because I dump all the response bytes and some
> sector reads ( command + rx block + status ) to the UART.

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.
> >
> > 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?
> >
> 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.
> 
> > What does your OS do on a reboot?  Is the reboot the result
> > of a power cycle or simply a processor reset?
> 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.
> >
> > Are you using a fixed delay between commands, or are you polling
> > for  a proper response before sending the next command?
> 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.
> >
> > 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
> 
> 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.
> 

Mark Borgerson

On Mar 22, 10:48 pm, Mark Borgerson <mborger...@comcast.net> wrote:
> In article <75f19f53-981e-41b6-a96b-23baf7684272
> @v20g2000yqv.googlegroups.com>, thetalkingb...@gmail.com says...
>
>
>
> > On Mar 22, 5:29 pm, Mark Borgerson <mborger...@comcast.net> wrote:
> > > In article <81236047-701e-4679-80d8-837639fc1389
> > > @m37g2000yqf.googlegroups.com>, thetalkingb...@gmail.com says...
>
> > > > 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.
>
> > > How much slower is the read?   Are you talking about microsecononds,
> > > milliseconds, or seconds?
> > Seconds, but that's because I dump all the response bytes and some
> > sector reads ( command + rx block + status ) to the UART.
>
> 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?
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.
>
> 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.
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.
>
> 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.
I'll look into that one...

>
>
>
>
>
> > > 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?
>
> > 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.
>
> > > What does your OS do on a reboot?  Is the reboot the result
> > > of a power cycle or simply a processor reset?
> > 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.
>
> > > Are you using a fixed delay between commands, or are you polling
> > > for  a proper response before sending the next command?
> > 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.
>
> > > 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
>
> > 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.
>
> Mark Borgerson