"Intentional Crash" hit in SD simulator?

[schveiguy]

I just was simulating my project, and hit this code in fnSimSD_write:

    case SD_CARD_INIT:
        if ((ucTxByte == 0x40) || (ucTxByte == 0x42) || (ucTxByte == 0x43) || (ucTxByte == 0x46) || (ucTxByte == 0x47) || (ucTxByte == 0x48) || (ucTxByte == 0x50) || (ucTxByte == 0x77) || (ucTxByte == 0x69) || (ucTxByte == 0x7a) || (ucTxByte == 0x58) || (ucTxByte == 0x51) || (ucTxByte == 0x49)) { // all expected commands
            ucCommand = ucTxByte;
            iArguments = 0;
            iSD_Card_State = SD_CARD_ARGUMENTS;
            break;
        }
        else if (ucTxByte != 0xff) {                                     // accept idle line, which is used when poll for busy
            *(unsigned char *)0 = 0; // <==== here
        }
        break;


This code died on the line that attempts to write 0 into the NULL address. ucTxByte is 0. It seems to be the second byte in a message from the function fnSendSD_command, with this code:

            for ( ; iCommandState < 6; iCommandState++) {                // command content is always 6 bytes in length
                WRITE_SPI_CMD(ucCommand[iCommandState]);                 // send the command and arguments
                WAIT_TRANSMISSON_END();                                  // wait until transmission complete
                READ_SPI_DATA();                                         // read to clear the flag
            }                                                            // fall through intentional after sending the command

So the call stack indicates we are on the WRITE_SPI_CMD line, and the iCommandState is 1 (ucCommand[0] is 'Q')

More in the call stack:

 case _READING_MEMORY:
        {
            unsigned char ucResult;
            while ((iActionResult = fnSendSD_command(fnCreateCommand(READ_SINGLE_BLOCK_CMD17, ulSector), &ucResult, 0)) == CARD_BUSY_WAIT) {}
            if (iActionResult < 0) {
                SET_SD_CS_HIGH();
                iMemoryOperation &= ~_READING_MEMORY;                    // read operation has completed
                return iActionResult;
            }

In this case, ulSector is 30446.

One thing I should note is that I updated my utFat code but did not delete the simuated SDcard.bin file. Is that the problem?

-Steve

[mark]

Steve

I don't think that there is any problem with utFAT versions and the SDcard.bin file but to be sure you could make a backup of your file (simply rename it will work) and then reformat the card and see whether there is a difference.

Also I wouldn't expect this exception to be hit unless the first byte in a (pre-defined) command that is being sent is a non-supported one. The commands used haven't changed since the first utFAT version.

What it looks like is that there is code calling fnSendSD_command() - for example

fnSendSD_command(ucGO_IDLE_STATE_CMD0, &ucResult, 0)

but the first parameter buffer content is invalid (specificalyl the first byte). For example,:

static const unsigned char ucGO_IDLE_STATE_CMD0[6]      = {GO_IDLE_STATE_CMD0, 0x00, 0x00, 0x00, 0x00, CS_GO_IDLE_STATE_CMD0};

When this is called the first byte is 0x40 (one of the supported commands). Most commands are consts and so the first byte should always be correct, assuming no data corruption somewhere.

The way to debug this would be as follows:
- set a break point in fnSendSD_command() and start the simulation.
- watch how often the routine is called without the exception and each time check the buffer const unsigned char ucCommand[6] and the location of the code it was called from in mass_storage.c.
- each time the buffer should have the expected content (valid first byte) and when there is a problem you can identify at which stage of mounting or at which action during use it takes place at.

Generally I would also do a rebuild of the entire project in case this is due to something not being build correctly after changing files.

Regards

Mark

[schveiguy]

Hi Mark,

Examining it some more yesterday, the 'Q' was hex 0x51, which is the CMD17 as the code suggests. The full message was 0x51 0x0 0x0 0x76 0xee 0x0, which is what the call to fnCreateCommand should create.

An interesting thing, however, is that the state the code was in when it processed the 0x51 byte is not something I can deduce. Whatever it was, the 0x51 caused it to go into the SD_CARD_INIT state. You will notice that if it was in INIT state, and it received 0x51, it would have set the state to SD_CARD_ARGUMENTS, so it wouldn't be in the SD_CARD_INIT state for the first 0 byte.

I have saved a backup copy of my SD_CARD.bin, in case you want it. I've erased the bin file and am just going to proceed with a fresh file. If it happens again, I will repost. This is the first time I have seen it or my colleague has seen it. So I'm not sure if it will happen again.

Thanks

-Steve

[mark]

Hi Steve

I have never encountered this error so I will first wait until you confirm that it is repeatable after starting with a new SD card.

Regards

Mark