Micro SD card / MSP430 interface: write problem

Hi everyone,

I have interfaced a Micro SD card to a MSP430 microcontroller using the
SPI mode. Everything worked perfectly fine but I recently had problems
when writing too often into my files.

Here is my setup. As I said the card (SDHC 4Go) is directly connected to
the microcontroller via its USCI (SPI) peripheral. I have written the
basic SD access (register read / write, basically to find if a card is a
SDSC or SDHC, page read / write). I have followed the reduced SD
spécification to do so (CRC activated, waiting after any operation for
the card to leave the 'busy' state). On top of that I have implemented a
FAT32 filesystem driver that is able to create / delete, read / write
any file on the root directory (not directory handling, only short
filenames).

Here is my problem: sometimes (I'm not able to give specific detail on
'when' because it varies a lot in time and frequency), complete sectors
of my create files are filled with zeroes...

I have investigated on my filesystem implementation because it seemed
obvious that the problem what there. But it turned out that I have
managed to reproduce that bug only writing pages using the low level SD
access. For exemple if i write 4000 pages of 512 bytes filled with 0xAA
bytes, I get 2 to 10 pages filled with 0x00.

Does anyone encountered this kind problem? I would be so grateful if
someone could give me at least a hint on how to solve that bug because
I'm wasting my last week investigating on that.

Regards,

Christophe

In article <4af5a261$0$29577$>,
says...
> Hi everyone,
>
> I have interfaced a Micro SD card to a MSP430 microcontroller using the
> SPI mode. Everything worked perfectly fine but I recently had problems
> when writing too often into my files.
>
> Here is my setup. As I said the card (SDHC 4Go) is directly connected to
> the microcontroller via its USCI (SPI) peripheral. I have written the
> basic SD access (register read / write, basically to find if a card is a
> SDSC or SDHC, page read / write). I have followed the reduced SD
> spécification to do so (CRC activated, waiting after any operation for
> the card to leave the 'busy' state). On top of that I have implemented a
> FAT32 filesystem driver that is able to create / delete, read / write
> any file on the root directory (not directory handling, only short
> filenames).
>
> Here is my problem: sometimes (I'm not able to give specific detail on
> 'when' because it varies a lot in time and frequency), complete sectors
> of my create files are filled with zeroes...
>
> I have investigated on my filesystem implementation because it seemed
> obvious that the problem what there. But it turned out that I have
> managed to reproduce that bug only writing pages using the low level SD
> access. For exemple if i write 4000 pages of 512 bytes filled with 0xAA
> bytes, I get 2 to 10 pages filled with 0x00.
>
> Does anyone encountered this kind problem? I would be so grateful if
> someone could give me at least a hint on how to solve that bug because
> I'm wasting my last week investigating on that.
>

My experience with SD cards and the MSP430 has led me to believe that
almost all errors are related to the timing of operations. In
particular, the time for the SD card to indicate that it is ready
for a new write increases drastically when the card's internal
processor decides it is time to erase a new block of the flash so
that new data can be written. On one set of cards, this happened
at 32KB intervals. At that point, the time to write a block
(after waiting for the card to indicate it is not busy) would bump
up from a few milliseconds to over 50 mSec. The delay probably
depends on the speed rating of the card.

My technique for debugging these issues was to toggle an I/O bit
at the start and end of the write function and observe the
timing.

Of course, the other possibility is that your write routine isn't
sending what you think it is. Perhaps you could repeat your
test, but insert code in the routine that writes the buffer to
check to make sure it isn't writing a buffer full of zeros.
A wayward buffer pointer might cause something like this.

Mark Borgerson

Mark Borgerson a écrit :
> In article <4af5a261$0$29577$>,
> says...
>> Hi everyone,
>>
>> I have interfaced a Micro SD card to a MSP430 microcontroller using the
>> SPI mode. Everything worked perfectly fine but I recently had problems
>> when writing too often into my files.
>>
>> Here is my setup. As I said the card (SDHC 4Go) is directly connected to
>> the microcontroller via its USCI (SPI) peripheral. I have written the
>> basic SD access (register read / write, basically to find if a card is a
>> SDSC or SDHC, page read / write). I have followed the reduced SD
>> spécification to do so (CRC activated, waiting after any operation for
>> the card to leave the 'busy' state). On top of that I have implemented a
>> FAT32 filesystem driver that is able to create / delete, read / write
>> any file on the root directory (not directory handling, only short
>> filenames).
>>
>> Here is my problem: sometimes (I'm not able to give specific detail on
>> 'when' because it varies a lot in time and frequency), complete sectors
>> of my create files are filled with zeroes...
>>
>> I have investigated on my filesystem implementation because it seemed
>> obvious that the problem what there. But it turned out that I have
>> managed to reproduce that bug only writing pages using the low level SD
>> access. For exemple if i write 4000 pages of 512 bytes filled with 0xAA
>> bytes, I get 2 to 10 pages filled with 0x00.
>>
>> Does anyone encountered this kind problem? I would be so grateful if
>> someone could give me at least a hint on how to solve that bug because
>> I'm wasting my last week investigating on that.
>>
>
> My experience with SD cards and the MSP430 has led me to believe that
> almost all errors are related to the timing of operations. In
> particular, the time for the SD card to indicate that it is ready
> for a new write increases drastically when the card's internal
> processor decides it is time to erase a new block of the flash so
> that new data can be written. On one set of cards, this happened
> at 32KB intervals. At that point, the time to write a block
> (after waiting for the card to indicate it is not busy) would bump
> up from a few milliseconds to over 50 mSec. The delay probably
> depends on the speed rating of the card.
>
> My technique for debugging these issues was to toggle an I/O bit
> at the start and end of the write function and observe the
> timing.
>
> Of course, the other possibility is that your write routine isn't
> sending what you think it is. Perhaps you could repeat your
> test, but insert code in the routine that writes the buffer to
> check to make sure it isn't writing a buffer full of zeros.
> A wayward buffer pointer might cause something like this.
>
> Mark Borgerson
>

Thanks Mark for your answer,

I did print my buffer before sending it, it is correctly filled, but
when I do outputs on the serial interface, write errors do not occur.
Generally speaking, they do no occur if I add delays (by adding printf,
or anything that is a bit time consuming). It seems to corroborate what
you say. If I understand well, you say that even if the card is telling
me it is not busy it might actually be? Is there any mean to know that?
(other than waiting for XXX ms) I've seen that it is possible to
pre-erase block, would it help? For the record, I do write operation
about 1 to 5 times per second (512 bytes blocks).

Christophe

Mark Borgerson a écrit :
> In article <4af5a261$0$29577$>,
> says...
>> Hi everyone,
>>
>> I have interfaced a Micro SD card to a MSP430 microcontroller using the
>> SPI mode. Everything worked perfectly fine but I recently had problems
>> when writing too often into my files.
>>
>> Here is my setup. As I said the card (SDHC 4Go) is directly connected to
>> the microcontroller via its USCI (SPI) peripheral. I have written the
>> basic SD access (register read / write, basically to find if a card is a
>> SDSC or SDHC, page read / write). I have followed the reduced SD
>> spécification to do so (CRC activated, waiting after any operation for
>> the card to leave the 'busy' state). On top of that I have implemented a
>> FAT32 filesystem driver that is able to create / delete, read / write
>> any file on the root directory (not directory handling, only short
>> filenames).
>>
>> Here is my problem: sometimes (I'm not able to give specific detail on
>> 'when' because it varies a lot in time and frequency), complete sectors
>> of my create files are filled with zeroes...
>>
>> I have investigated on my filesystem implementation because it seemed
>> obvious that the problem what there. But it turned out that I have
>> managed to reproduce that bug only writing pages using the low level SD
>> access. For exemple if i write 4000 pages of 512 bytes filled with 0xAA
>> bytes, I get 2 to 10 pages filled with 0x00.
>>
>> Does anyone encountered this kind problem? I would be so grateful if
>> someone could give me at least a hint on how to solve that bug because
>> I'm wasting my last week investigating on that.
>>
>
> My experience with SD cards and the MSP430 has led me to believe that
> almost all errors are related to the timing of operations. In
> particular, the time for the SD card to indicate that it is ready
> for a new write increases drastically when the card's internal
> processor decides it is time to erase a new block of the flash so
> that new data can be written. On one set of cards, this happened
> at 32KB intervals. At that point, the time to write a block
> (after waiting for the card to indicate it is not busy) would bump
> up from a few milliseconds to over 50 mSec. The delay probably
> depends on the speed rating of the card.
>
> My technique for debugging these issues was to toggle an I/O bit
> at the start and end of the write function and observe the
> timing.
>
> Of course, the other possibility is that your write routine isn't
> sending what you think it is. Perhaps you could repeat your
> test, but insert code in the routine that writes the buffer to
> check to make sure it isn't writing a buffer full of zeros.
> A wayward buffer pointer might cause something like this.
>
> Mark Borgerson
>

Hi,

I have read once again the SD simplified specification and Samsung
MicroSD Card datasheet, it seems that there is a flag called
READY_FOR_DATA in the card status (not in SD Status register) that
indicates the card accepts write operations. It seems to be accessible
in the R1 response but only in SD Mode, I have not seen any mean to
access this bit in SPI mode, does anyone know how to have this information?

Christophe

In article <4af7e1dd$0$11637$>,
says...
> Mark Borgerson a écrit :
> > In article <4af5a261$0$29577$>,
> > says...
> >> Hi everyone,
> >>
> >> I have interfaced a Micro SD card to a MSP430 microcontroller using the
> >> SPI mode. Everything worked perfectly fine but I recently had problems
> >> when writing too often into my files.
> >>
> >> Here is my setup. As I said the card (SDHC 4Go) is directly connected to
> >> the microcontroller via its USCI (SPI) peripheral. I have written the
> >> basic SD access (register read / write, basically to find if a card isa
> >> SDSC or SDHC, page read / write). I have followed the reduced SD
> >> spécification to do so (CRC activated, waiting after any operation for
> >> the card to leave the 'busy' state). On top of that I have implementeda
> >> FAT32 filesystem driver that is able to create / delete, read / write
> >> any file on the root directory (not directory handling, only short
> >> filenames).
> >>
> >> Here is my problem: sometimes (I'm not able to give specific detail on
> >> 'when' because it varies a lot in time and frequency), complete sectors
> >> of my create files are filled with zeroes...
> >>
> >> I have investigated on my filesystem implementation because it seemed
> >> obvious that the problem what there. But it turned out that I have
> >> managed to reproduce that bug only writing pages using the low level SD
> >> access. For exemple if i write 4000 pages of 512 bytes filled with 0xAA
> >> bytes, I get 2 to 10 pages filled with 0x00.
> >>
> >> Does anyone encountered this kind problem? I would be so grateful if
> >> someone could give me at least a hint on how to solve that bug because
> >> I'm wasting my last week investigating on that.
> >>
> >
> > My experience with SD cards and the MSP430 has led me to believe that
> > almost all errors are related to the timing of operations. In
> > particular, the time for the SD card to indicate that it is ready
> > for a new write increases drastically when the card's internal
> > processor decides it is time to erase a new block of the flash so
> > that new data can be written. On one set of cards, this happened
> > at 32KB intervals. At that point, the time to write a block
> > (after waiting for the card to indicate it is not busy) would bump
> > up from a few milliseconds to over 50 mSec. The delay probably
> > depends on the speed rating of the card.
> >
> > My technique for debugging these issues was to toggle an I/O bit
> > at the start and end of the write function and observe the
> > timing.
> >
> > Of course, the other possibility is that your write routine isn't
> > sending what you think it is. Perhaps you could repeat your
> > test, but insert code in the routine that writes the buffer to
> > check to make sure it isn't writing a buffer full of zeros.
> > A wayward buffer pointer might cause something like this.
> >
> > Mark Borgerson
> >
>
> Hi,
>
> I have read once again the SD simplified specification and Samsung
> MicroSD Card datasheet, it seems that there is a flag called
> READY_FOR_DATA in the card status (not in SD Status register) that
> indicates the card accepts write operations. It seems to be accessible
> in the R1 response but only in SD Mode, I have not seen any mean to
> access this bit in SPI mode, does anyone know how to have this information?
>

Have you tried your code on a SanDisk micro SD card? I have found that
different manufacturers have very different delays before the card is
ready.

In my SD_Send_Command code, I execute the following check whenever the
LAST operation was a write
i = 0;
SD_CS_ON; // macro to set CS bit low
do { // Check for card busy
if(i++ > 30000) break;
uc = Get_SD_SPI(); // get a byte from the SPI
} while(uc == 0); // uc stays zero while card busy
......
// more code to actually send the command



At the processor and SPI clock speed I am using, 30,000 times
through this loop is about 100 milliseconds.


At one time, I added code to keep track of the loop count in
this routine. IIRC, it was normally under 20, but would bump
up to the 30,000 limit at times.

I also have code that checks for valid responses to commands.
If I don't get a valid response, I increment a soft error count
and try the command again---including the wait for the card
to be not busy. I generally see two or three of these soft
errors in an hour----indicating that the write command timed
out. If I get 5 consecutive soft errors, I increment a hard
error count, power down the card, reinitialize and start
over with the command. This can take almost a second. Thankfully,
I have not had any hard errors in the last few months.


Mark Borgerson

Mark Borgerson a écrit :
> In article <4af7e1dd$0$11637$>,
> says...
>> Mark Borgerson a écrit :
>>> In article <4af5a261$0$29577$>,
>>> says...
>>>> Hi everyone,
>>>>
>>>> I have interfaced a Micro SD card to a MSP430 microcontroller using the
>>>> SPI mode. Everything worked perfectly fine but I recently had problems
>>>> when writing too often into my files.
>>>>
>>>> Here is my setup. As I said the card (SDHC 4Go) is directly connected to
>>>> the microcontroller via its USCI (SPI) peripheral. I have written the
>>>> basic SD access (register read / write, basically to find if a card is a
>>>> SDSC or SDHC, page read / write). I have followed the reduced SD
>>>> spécification to do so (CRC activated, waiting after any operation for
>>>> the card to leave the 'busy' state). On top of that I have implemented a
>>>> FAT32 filesystem driver that is able to create / delete, read / write
>>>> any file on the root directory (not directory handling, only short
>>>> filenames).
>>>>
>>>> Here is my problem: sometimes (I'm not able to give specific detail on
>>>> 'when' because it varies a lot in time and frequency), complete sectors
>>>> of my create files are filled with zeroes...
>>>>
>>>> I have investigated on my filesystem implementation because it seemed
>>>> obvious that the problem what there. But it turned out that I have
>>>> managed to reproduce that bug only writing pages using the low level SD
>>>> access. For exemple if i write 4000 pages of 512 bytes filled with 0xAA
>>>> bytes, I get 2 to 10 pages filled with 0x00.
>>>>
>>>> Does anyone encountered this kind problem? I would be so grateful if
>>>> someone could give me at least a hint on how to solve that bug because
>>>> I'm wasting my last week investigating on that.
>>>>
>>> My experience with SD cards and the MSP430 has led me to believe that
>>> almost all errors are related to the timing of operations. In
>>> particular, the time for the SD card to indicate that it is ready
>>> for a new write increases drastically when the card's internal
>>> processor decides it is time to erase a new block of the flash so
>>> that new data can be written. On one set of cards, this happened
>>> at 32KB intervals. At that point, the time to write a block
>>> (after waiting for the card to indicate it is not busy) would bump
>>> up from a few milliseconds to over 50 mSec. The delay probably
>>> depends on the speed rating of the card.
>>>
>>> My technique for debugging these issues was to toggle an I/O bit
>>> at the start and end of the write function and observe the
>>> timing.
>>>
>>> Of course, the other possibility is that your write routine isn't
>>> sending what you think it is. Perhaps you could repeat your
>>> test, but insert code in the routine that writes the buffer to
>>> check to make sure it isn't writing a buffer full of zeros.
>>> A wayward buffer pointer might cause something like this.
>>>
>>> Mark Borgerson
>>>
>> Hi,
>>
>> I have read once again the SD simplified specification and Samsung
>> MicroSD Card datasheet, it seems that there is a flag called
>> READY_FOR_DATA in the card status (not in SD Status register) that
>> indicates the card accepts write operations. It seems to be accessible
>> in the R1 response but only in SD Mode, I have not seen any mean to
>> access this bit in SPI mode, does anyone know how to have this information?
>>
>
> Have you tried your code on a SanDisk micro SD card? I have found that
> different manufacturers have very different delays before the card is
> ready.
>
> In my SD_Send_Command code, I execute the following check whenever the
> LAST operation was a write
> i = 0;
> SD_CS_ON; // macro to set CS bit low
> do { // Check for card busy
> if(i++ > 30000) break;
> uc = Get_SD_SPI(); // get a byte from the SPI
> } while(uc == 0); // uc stays zero while card busy
> .....
> // more code to actually send the command
>
>
>
> At the processor and SPI clock speed I am using, 30,000 times
> through this loop is about 100 milliseconds.
>
>
> At one time, I added code to keep track of the loop count in
> this routine. IIRC, it was normally under 20, but would bump
> up to the 30,000 limit at times.
>
> I also have code that checks for valid responses to commands.
> If I don't get a valid response, I increment a soft error count
> and try the command again---including the wait for the card
> to be not busy. I generally see two or three of these soft
> errors in an hour----indicating that the write command timed
> out. If I get 5 consecutive soft errors, I increment a hard
> error count, power down the card, reinitialize and start
> over with the command. This can take almost a second. Thankfully,
> I have not had any hard errors in the last few months.
>
>
> Mark Borgerson

I added exactly the same kind of code after reading the samsung
datasheet on micro SD (the description of SPI protocol is far more
detailed than in the simplified SD specification). I have not seen any
write problem ever since. But has Dijkstra said, test can only show the
presence of bug not their absence

Thank you again for your advice I'll keep in mind your system for error
recovery, this might be useful

Christophe

don a écrit :
> Christophe Braillon wrote:
>>
>> I added exactly the same kind of code after reading the samsung
>> datasheet on micro SD
>
> Is this data sheet online somewhere ?
>
> Google has not turned it up for me. :-(
>
> Thanks
>
> don

I found it here:
http://www.mt-system.ru/documents/mi...sion%200.3.pdf

Christophe

A simple method is this: Arm yourself with the data sheet and a logic analyzer (+ what else you need).

Check each and every specification of the datasheet one by one. Prove to yourself (and document it) that your system does the right thing according to the SD datasheet.

Eventually you will find the error. Most likely something you did :-)

BTW: This is not different from normal egineering practice for good quality engineering :-)

And if you manage to prove and document that you do everything exactly by the book - you have a good case when you go to the manufacturer for technical support...