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.

TMS320F28377D: Flash API blank check/write verify

Part Number: TMS320F28377D
Other Parts Discussed in Thread: CONTROLSUITE

In the flash programming examples, it shows setup, erase and write of several sectors.  Consider the following two TI example code excerpts from \ti\controlSUITE\device_support\F2837xD\v210\F2837xD_examples_Dual\flash_programming\cpu01:
1)
    

//
    // Erase Sector B
    //
    oReturnCheck = Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector,
                   (uint32 *)Bzero_SectorB_start);

    //
    // Wait until FSM is done with erase sector operation
    //
    while (Fapi_checkFsmForReady() != Fapi_Status_FsmReady){}

    //
    // Verify that SectorB is erased.  The Erase step itself does a verify as
    // it goes.  This verify is a 2nd verification that can be done.
    //
    oReturnCheck = Fapi_doBlankCheck((uint32 *)Bzero_SectorB_start,
                                     Bzero_16KSector_u32length,
                                     &oFlashStatusWord);

2)

    // Example:  Program 0xFF bytes in Flash Sector B with out ECC
    // Disable ECC so that error is not generated when reading Flash contents
    // without ECC
    //
    Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0x0;

    for(i=0, u32Index = Bzero_SectorB_start;
       (u32Index < (Bzero_SectorB_start + WORDS_IN_FLASH_BUFFER)) &&
       (oReturnCheck == Fapi_Status_Success); i+= 8, u32Index+= 8)
    {
        oReturnCheck = Fapi_issueProgrammingCommand((uint32 *)u32Index,
                                                    Buffer+i,
                                                    8,
                                                    0,
                                                    0,
                                                    Fapi_DataOnly);


        while(Fapi_checkFsmForReady() == Fapi_Status_FsmBusy);

        if(oReturnCheck != Fapi_Status_Success)
        {
            //
            // Check Flash API documentation for possible errors
            //
            Example_Error(oReturnCheck);
        }

        //
        // Read FMSTAT register contents to know the status of FSM
        // after program command for any debug
        //
        oFlashStatus = Fapi_getFsmStatus();

        //
        // Verify the values programmed.  The Program step itself does a verify
        // as it goes.  This verify is a 2nd verification that can be done.
        //
        oReturnCheck = Fapi_doVerify((uint32 *)u32Index,
                                      4, Buffer32+(i/2),
                                      &oFlashStatusWord);


        if(oReturnCheck != Fapi_Status_Success)
        {
            //
            // Check Flash API documentation for possible errors
            //
            Example_Error(oReturnCheck);
        }
    }


 Two comments concern me:

1) "The Erase step itself does a verify as it goes.  This verify is a 2nd verification that can be done".  

2) "The Program step itself does a verify as it goes.  This verify is a 2nd verification that can be done."


Is there any value/added confidence in calling Fapi_doBlankCheck(...) or Fapi_doVerify(...)?  If so, can you clarify what?  

Thanks!

Stephen

  • Stephen,

    We noticed that customers get an extra level of confidence by doing CPU based verification after an erase and program operation and hence provided those functions.  Applications that require safety standards prefer reading the Flash (to confirm the contents) not only after Flash erase and program but also at regular intervals during run time (like a CRC check of the Flash contents).  These functions are helpful after a erase and program operation.

    Apart from this, it is advised to check the FSM status (using Fapi_getFsmStatus() function) after an erase and program operation to make sure that the FSM is able to successfully complete the Flash operation without any errors.

    Thanks and regards,

    Vamsi