Why do we send some dumthe data before sending any command to a microSD card

microcontrollermicrosd

I am interfacing a microSD card with a microcontroller. The following code snippet is taken from Application note 189 (AN189), MMC DATA LOGGER EXAMPLE on page no. 30. The MMC_Command_Exec() basically implements the details to send the appropriate commands to the microSD card.

// Send the SEND_OP_COND command until
// the MMC indicates that it is no
// longer busy (ready for commands).
do
{
    SPI0DAT = 0xFF;
    while (!SPIF) {
    }
    SPIF = 0;
    card_status.i = MMC_Command_Exec(SEND_OP_COND,EMPTY,EMPTY);
}
while ((card_status.b[0] & 0x01))
    ;

I am not able to understand what is the need of sending FF (instruction SPI0DAT = 0xFF;) prior to sending the command using MMC_Commd_Exec?

I have checked that if I remove SPI0DAT = 0xFF;, and put a delay of 200 ms and even more then I never get a correct result.

Also, I can see at other places that this type of dummy data was not sent, for example:

// Read the Operating Conditions Register (OCR).
do
{
    card_status.i = MMC_Command_Exec(READ_OCR,EMPTY,pchar);
}
while (!(*pchar&0x80))
    ; // Check the card busy bit of the OCR

So the simple question is when to send and when not to send.

Best Answer

The SPI bidirectional protocol requires that any time the master might try to exchange a byte of data, the slave always be ready to take in a byte of data and spit one out. The master will feed the slave a byte on MOSI without regard for whether or not the slave is ready to do anything useful with it, and whatever the slave does on the MISO pin will be interpreted as a byte of data by the master whether or not the slave had anything useful it wanted to say.

To deal with this, many SPI chips define their behavior such that the first byte following a chip select will indicate whether the device is ready to do anything with a command request other than drop it on the floor. Effectively, the first thing the master does is ask "are you ready?" If the slave answers "no", the master may ask repeatedly as often as it wants until the slave says "yes". Such a design is fairly simple to implement on the slave side, and is fairly easy to use from the master side. Further, it's generally not to hard to subdivide the different kinds of operations a device can perform into steps which are small enough that once the slave is ready to begin performing a step, it will be able to exchange all the data with that step as fast as the master cares to clock it, without further delay.

One slight wrinkle in all of this is that some slaves may need pulses on the clock wire in order to perform certain operations. As a common example, many designs expect to latch all 8 bits of the next byte they're going to send before they receive the first clock pulse. If a device which is primed to send a byte that says "not ready" becomes ready, it would have no way of knowing whether a clock pulse might arrive just as it was getting ready to change the next byte it transmitted, causing that byte to contain a mix of old and new data. One way of avoiding such a danger is to have a device decide on the sixth clock cycle of each byte whether it's going to report itself as ready on the following byte. Even if the device becomes ready just as it receives the sixth cycle of a byte, by the time the eight cycle was received the device would have had a chance to make up its mind as to whether it thought it became ready before the sixth cycle (in which case the next byte should report "ready") or failed to do so (in which case it should report another "not ready" byte).

Related Topic