SPRUJE7A January   2025  – July 2025 F29H850TU , F29H859TU-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Introduction
    1. 1.1 Differences From C28x
    2. 1.2 Function Listing Format
  5. 2F29H85x Flash API Overview
    1. 2.1 Introduction
    2. 2.2 API Overview
    3. 2.3 Using API
      1. 2.3.1 Initialization Flow
        1. 2.3.1.1 After Device Power Up
        2. 2.3.1.2 On System Frequency Change
      2. 2.3.2 Building With the API
        1. 2.3.2.1 Object Library Files
        2. 2.3.2.2 Distribution Files
      3. 2.3.3 Key Facts for Flash API Usage
  6. 3API Functions
    1. 3.1 Initialization Functions
      1. 3.1.1 Fapi_initializeAPI()
    2. 3.2 Flash State Machine Functions
      1. 3.2.1  Fapi_setActiveFlashBank()
      2. 3.2.2  Fapi_setupBankSectorEnable()
      3. 3.2.3  Fapi_issueAsyncCommandWithAddress()
      4. 3.2.4  Fapi_issueBankEraseCommand()
      5. 3.2.5  Fapi_issueProgrammingCommand()
      6. 3.2.6  Fapi_issueAutoEcc512ProgrammingCommand()
      7. 3.2.7  Fapi_issueDataAndEcc512ProgrammingCommand()
      8. 3.2.8  Fapi_issueDataOnly512ProgrammingCommand()
      9. 3.2.9  Fapi_issueEccOnly64ProgrammingCommand()
      10. 3.2.10 Fapi_issueAsyncCommand()
      11. 3.2.11 Fapi_checkFsmForReady()
      12. 3.2.12 Fapi_getFsmStatus()
    3. 3.3 Read Functions
      1. 3.3.1 Fapi_doBlankCheck()
      2. 3.3.2 Fapi_doVerify()
      3. 3.3.3 Fapi_doVerifyByByte()
    4. 3.4 Informational Functions
      1. 3.4.1 Fapi_getLibraryInfo()
    5. 3.5 Utility Functions
      1. 3.5.1 Fapi_flushPipeline()
      2. 3.5.2 Fapi_calculateEcc()
      3. 3.5.3 Fapi_isAddressEcc()
      4. 3.5.4 Fapi_getUserConfiguration()
      5. 3.5.5 Fapi_setFlashCPUConfiguration()
      6. 3.5.6 Fapi_issueProgBankMode()
  7. 4SECCFG and BANKMGMT Programming Using the Flash API
    1. 4.1 BANKMGMT Programming
    2. 4.2 SECCFG Programming
  8. 5Allowed Programming Ranges for All Modes
  9. 6Recommended FSM Flows
    1. 6.1 New Devices From Factory
    2. 6.2 Recommended Erase Flow
    3. 6.3 Recommended Bank Erase Flow
    4. 6.4 Recommended Program Flow
  10. 7References
  11.   A Flash State Machine Commands
  12.   B Typedefs, Defines, Enumerations and Structure
    1.     B.1 Type Definitions
    2.     B.2 Defines
    3.     B.3 Enumerations
      1.      B.3.1 Fapi_FlashProgrammingCommandsType
      2.      B.3.2 Fapi_FlashBankType
      3.      B.3.3 Fapi_FlashStateCommandsType
      4.      B.3.4 Fapi_StatusType
      5.      B.3.5 Fapi_ApiProductionStatusType
      6.      B.3.6 Fapi_BankID
      7.      B.3.7 Fapi_FLCID
      8.      B.3.8 Fapi_BankMode
      9.      B.3.9 Fapi_CPU1BankSwap
      10.      B.3.10 Fapi_CPU3BankSwap
      11.      B.3.11 Fapi_FOTAStatus
      12.      B.3.12 Fapi_SECVALID
      13.      B.3.13 Fapi_BankMgmtAddress
    4.     B.4 Structures
      1.      B.4.1 Fapi_FlashStatusWordType
      2.      B.4.2 Fapi_LibraryInfoType
  13.   Revision History

2.3.3 Key Facts for Flash API Usage

Here are some important facts about API usage:

  • Names of the Flash API functions start with a prefix “Fapi_”.
  • Flash API does not configure the PLL. The user application must configure the PLL as needed and pass the configured CPUCLK value to Fapi_initializeAPI() function (details of this function are given later in this document).
  • Flash API does not check the PLL configuration to confirm the user input frequency. This is up to the system integrator - TI suggests to use the DCC module to check the system frequency. For an example implementation, see the F29H85x SDK driverlib clock configuration function.
  • Flash API does not configure the SSU registers or obtain the flash semaphore. User applications must configure them as needed. For details of these registers, see the F29H85x and F29P58x Real-Time Microcontrollers Technical Reference Manual.
  • Always configure waitstates as per the device-specific data manual before calling the Flash API functions. The Flash API issues an error if the waitstate configured by the application is not appropriate for the operating frequency of the application.
  • Flash API execution is interruptible. There cannot be any read/fetch access from the Flash bank on which an erase/program operation is in progress. Therefore, the Flash API functions, the user application functions that call the Flash API functions, and any ISRs (Interrupt service routines) must be executed from RAM or the flash bank on which there is no any active erase/program operation in progress. For example, the above mentioned conditions apply to the entire code-snippet shown below in addition to the Flash API functions. The reason for this is because the Fapi_issueAsyncCommandWithAddress() function issues the erase command to the FSM, but it does not wait until the erase operation is over. As long as the FSM is busy with the current operation, the Flash bank being erased cannot be accessed.
//
// Erase Sector
//
oReturnCheck = Fapi_issueProgrammingCommand(Fapi_EraseSector, u32Index,
                                   0, u32UserFlashConfig);

//
// Wait until the Flash erase operation is over
//
while(Fapi_checkFsmForReady(u32Index, u32UserFlashConfig) == Fapi_Status_FsmBusy);
  • Flash API does not configure (enable/disable) watchdog. The user application can configure watchdog and service it as needed.
  • The Main Array flash programming must be aligned to 64-bit address boundaries (alignment on 128-bit address boundary is suggested) and each 64-bit word may only be programmed once per write/erase cycle.
  • It is permissible to program the data and ECC separately. However, each 64-bit dataword and the corresponding ECC word may only be programmed once per write/erase cycle.
  • Note that there cannot be any access to the Flash bank on which the Flash erase/program operation is in progress.
  • Verification/blank check operations cannot be performed by default when in SSUMODE2 or SSUMODE3. If a user wants to perform a verify/blank check operation in SSUMODE2 or SSUMODE3, the user must provide the necessary read APR permissions. For details on SSU configuration, see the F29H85x and F29P58x Real-Time Microcontrollers Technical Reference Manual.
  • The Flash state machine also internally performs a verify operation after an erase/program pulse to validate the success of the operation. Successive program/program verify loops (or erase/erase verify loops) using the provided functions are done as needed to verify proper erase/programming. If the flash Wrapper state machines fail to completely program or erase all target bits in the flash within the number of program/erase pulses configured in the maximum pulse count setting, the FAILVERIFY bit is set in the STATCMD register.