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.

Implementation for Fapi_issueBankEraseCommand()

Part Number: TMS320F280039C
Other Parts Discussed in Thread: C2000WARE

Dear Champs,

I am asking this for our customer.

In the flash API, there is a new command "Fapi_issueBankEraseCommand()" and it has sample implementation below.

In C:\TI\c2000\C2000Ware_4_00_00_00\driverlib\f28003x\examples\flash\flashapi_ex1_programming.c, there are codes below.

oReturnCheck = Fapi_issueBankEraseCommand((uint32 *)u32CurrentAddress, 0x001F);

// Wait until FSM is done with bank erase operation
while (Fapi_checkFsmForReady() != Fapi_Status_FsmReady)
{
//
// Initialize the Erase Pulses to zero after issuing max pulses
//
if(HWREG(FLASH0CTRL_BASE + FLASH_O_ACC_EP) > MAX_ERASE_PULSE)
{
EALLOW;

//
// Enable Flash Optimization
//
HWREG(FLASH0CTRL_BASE + FLASH_O_OPT) = OPT_ENABLE;

HWREG(FLASH0CTRL_BASE + FLASH_O_ERA_PUL) =
HWREG(FLASH0CTRL_BASE + FLASH_O_ERA_PUL) &
~(uint32_t)FLASH_ERA_PUL_MAX_ERA_PUL_M;

//
// Disable Flash Optimization
//
HWREG(FLASH0CTRL_BASE + FLASH_O_OPT) = OPT_DISABLE;

EDIS;
}
}

Questions:

1) Why is it using "while()" to check the FSM status? The user is concerned if it will become an infinite loop or if it may cause long time here. Can the user change it to "if()"?

That is, after oReturnCheck = Fapi_issueBankEraseCommand((uint32 *)u32CurrentAddress, 0x001F);

the user run other non-flash-API related codes and then back to here to check if (Fapi_checkFsmForReady() != Fapi_Status_FsmReady).

If true, then do the same below codes once. If false, then it goes out to run other non-flash-API related codes and then goes back in a while and repeat this if (Fapi_checkFsmForReady() != Fapi_Status_FsmReady) again.

//
// Initialize the Erase Pulses to zero after issuing max pulses
//
if(HWREG(FLASH0CTRL_BASE + FLASH_O_ACC_EP) > MAX_ERASE_PULSE)
{
EALLOW;

//
// Enable Flash Optimization
//
HWREG(FLASH0CTRL_BASE + FLASH_O_OPT) = OPT_ENABLE;

HWREG(FLASH0CTRL_BASE + FLASH_O_ERA_PUL) =
HWREG(FLASH0CTRL_BASE + FLASH_O_ERA_PUL) &
~(uint32_t)FLASH_ERA_PUL_MAX_ERA_PUL_M;

//
// Disable Flash Optimization
//
HWREG(FLASH0CTRL_BASE + FLASH_O_OPT) = OPT_DISABLE;

EDIS;

Do you think it works too? Or do you have any concern that the code has to wait by "while()" and repeat above again and again?

2) The code is driverlib based. Because the user does not use driverlib but use bit-field codes only, would you please provide the above codes in bit-field codes?

That is, changing HWREG to bit-field based codes?

Wayne Huang

  • Wayne,

    1) As you know, while loop is used after every flash operation (program, sector erase, async command etc.).  It is not specific to Bank erase.  It is to allow the flash operation to get to completion.  Instead of a while loop, if user wants to come back and check via an ISR (timer) or through linear code, that is not a problem.  Note that the flash operations are bounded by a limit (max allowed program/erase pulse counts) - hence there is no infinite loop risk.  However, if needed, user can always keep a timeout for the operation (as per the data sheet flash parameter spec).  

    For bank erase, the code in the while loop (the driverlib code you quoted) is needed to bring the flash state machine out of the bank erase in case of a real erase failure.  It is mentioned in the flash API guide.  Hence, user should include that code as part of the if condition (while loop or not).  

         

    2) We did not define a bit-field structure for these registers.  The header file (flash_programming_f28003x.h) provided in the C2000Ware flash API example has these registers defined using #defines.  As long as the HWREG is defined (maybe they can pull it in to this header if needed?), it should work fine.  Adding this does not mean they have to move to driverlib for the entire application.

    Please note:  I am out of office and my colleague will monitor this thread for you.

    Thanks and regards,
    Vamsi