This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Hard fault on Flash API Fapi_doVerifyByByte

While writing to flash on the M3 core of a Concerto F28M36x (the ControlCard dev board), I get a repeatable hard fault after writing to an certain address.

The code that causes it looks like this:

#define FLASHAPI_FUNCTION_CALL_START()  {HWREG(SYSCTL_MWRALLOW) = 0xA5A5A5A5;IntMasterDisable();}
#define FLASHAPI_FUNCTION_CALL_END()    {HWREG(SYSCTL_MWRALLOW) = 0x00000000;IntMasterEnable();}

static Fapi_StatusType prog(uint32_t address, uint8_t* data, uint8_t dataLen)
{
    Fapi_StatusType ret = FLASH_STAT_OK;

    FLASHAPI_FUNCTION_CALL_START();

    ret = Fapi_issueProgrammingCommand(
            (uint32 *) address, data, (uint8_t) dataLen, 
            0, 0, Fapi_AutoEccGeneration);
    );

    while(Fapi_checkFsmForReady() == Fapi_Status_FsmBusy);

    FLASHAPI_FUNCTION_CALL_END();

    if (ret)
        return ret;

    /* This line is reached, and the flash is programmed */

    FLASHAPI_FUNCTION_CALL_START();

    Fapi_FlashStatusWordType fasw;
    ret = Fapi_doVerifyByByte((uint8 *) address, dataLen, data, &fasw);

    FLASHAPI_FUNCTION_CALL_END();

    /* This line is not reached */
    return ret;
}

It works for several writes before it hard faults, and the fault is always when writing address 0x0021006c with a length of 4 bytes. The write does succeed - the flash has been written when the debugger is paused. Other writes from 0x00210000 up to 0x0021006c also have succeeded, and verified OK.

An erase is done before any of the writing. The presence of the interrupt lock around the verify call makes no difference.

Cutting out the verify works, and the entire process goes fine for all following writes (many kB) if there is no verify.

What could be causing this to hard-fault on this particular address? 6c + 4 doesn't cross a 32-bit word, 16-byte flash line, or flash bank boundary, and all writes up to this point succeed.

  • I figured this out: it's because I was writing Fapi_AutoEccGenerationand writing to each 8-byte word twice (once for the first 4 and once for the last 4). This doesn't work, because programming the ECC for the first 4 bytes affects the whole ECC byte, which can then not be programmed again by the second write.

    Inspecting FMSTAT with Fapi_getFsmStatus() shows INVDAT and CSTAT bits are set after the write.

    Handling the writes so that they are always 8-byte aligned fixes the issue.

  • John,

    Thanks for the update! Glad to hear you've found a solution.

    Elizabeth