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.

Which F021 Flash API calls need to be called from RAM?

Expert 1226 points
Other Parts Discussed in Thread: TMS570LS0432, TMS570LS1224, TMS570LC4357

We're using the F021 Flash API on the Hercules TMS570LS0432 and TMS570LS1224 microcontrollers.

We're primarily using SPNU501H.pdf "F021 Flash API Version 2.01.01 Reference Guide", revised April 2015, as, well, our reference and guide for our development.

I understand that we need to be careful not to stall the CPU by attempting to read a flash memory location from the same flash bank that an erase or program command is currently being performed on.  As such, we:

  1. Run parts of our code from RAM, if that code is calling F021 API calls which erase or program the flash
  2. Disable interrupts before calling such F021 API calls
  3. Do not enable interrupts again until after both:
    1. The FMSTAT register indicates that the FSM is not busy
    2. We have called Fapi_flushPipeline()

I have a few questions:

First: is it necessary to both poll the FMSTAT register _and_ call Fapi_flushPipeline(), or does Fapi_flushPipeline() inherently take care of ensuring that the FSM has completed its work?  I notice that the recommended erase and program flows in the Reference Guide (figures 2 and 3) do not make any reference to Fapi_flushPipeline(), and only refer to the FMSTAT register.  (If we can do either one or the other then I'll probably do Fapi_flushPipeline() rather than my own polling loop.)

Second: the Reference Guide implies that _ALL_ F021 Flash API calls must be called from RAM (and, by implication, called with interrupts disabled, if any of our ISRs might access flash)--not just ones which erase or program the flash.

Is this correct?  If not, I would appreciate clear documentation on which F021 API calls need to be called from RAM (and, again, with interrupts disabled), and which ones can safely be run from code executing from flash.

Is it only the following calls?

  • Fapi_issueAsyncCommand() (Only for some, not all, of the commands?)
  • Fapi_issueAsryncCommandWithAddress() (Only for some, not all, of the commands?)
  • Fapi_issueProgrammingCommand()
  • Fapi_issueProgrammingCommandForEccAddress()

(For devices not using the L2FMC memory controller.)

Third: do the TMS570LS0432 or theTMS570LS1224 microcontrollers have the L2FMC memory controller?

Thank you!

  • 1. Polling FMSTAT and Fapi_flushPipeline() do two different things. The first is to make sure the flash state-machine has completed. The second is to make sure that the data you read is from the flash after the program or erase operation has completed, not something that was left in the flash wrapper pipeline. So yes, you must do both. The polling of FMSTAT is done in all of the synchronous commands. For the asynchronous commands it is done by using the macro FAPI_CHECK_FSM_READY_BUSY.
    2. All of the functions that program, erase, blank check or margin verify must be called from a bank other than the one in which code is being executed. If programming or erasing bank 0 of the TMS470LS0432 or the TMS470LS1224 then these routines must be in RAM.
    3. No, The TMS570LS0432 and TMS570LS1224 do not use the L2FMC. That flash wrapper is used by R5 cache based devices such as the TMS570LC4357.
  • Excellent, good to know. So, the majority of "supporting" F021 calls can be safely called from code running in flash, specifically including Fapi_initializeFlashBanks() and Fapi_enableMainBankSectors().

    We need to be very careful with how long we have interrupts disabled. The data sheet for the TMS570LS0432 lists the maximum time for wide word (144 bit) programming, and for sector erase. How can we determine the maximum time specifications for blank check and margin verify operations?
  • Unlike the program and erase functions, the blank check and verify functions will take a fixed amount of time (a function of clock speed, wait states and the size of the block being checked).