Below is a FAQ on Flash API usage for these devices: TMS320F28M35x, TMS320F28M36x, TMS320F2837xD, TMS320F2837xS, TMS320F2807x, TMS320F28004x, TMS320F28002x, TMS320F2838x, TMS320F280013x, TMS320F280015x and TMS320F28P65x devices.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Please use the below Flash API FAQ along with the device specific Flash API reference guide.
(a) F28M35x and F28M36x Flash API (V1.53) reference guide link: http://www.ti.com/lit/pdf/spnu595
(b) F2837xS Flash API (V1.55) reference guide link: http://www.ti.com/lit/pdf/spnu630
(c) F28004x Flash API (V1.56.01) reference guide link: http://www.ti.com/lit/pdf/spnu628
(d) F2837xD and F2807x Flash API (V1.54) reference guide link: http://www.ti.com/lit/pdf/spnu629
(e) F28002x (V1.57) reference guide link: http://www.ti.com/lit/pdf/spnu631
(f) F2838x (V1.60) reference guide link: http://www.ti.com/lit/pdf/spnu632
(g) F28003x (V 1.58) reference guide link: http://www.ti.com/lit/pdf/spruj27
(h) F28P65x (V3.x) reference guide available at: C2000Ware_X_XX_XX_XX\libraries\flash_api\f28p65x\docs
(i) F280013x and F280015x (V2.x) Flash API reference guide link: https://www.ti.com/lit/pdf/spruj96
Note for F2807x users: The sample implementations (examples) provided in SPNU629 use 200MHz CPUCLK frequency since that document is primarily made for TMS320F2837xD devices. TMS320F2807x users should not use more than 120MHz of CPUCLK as mentioned in the data manual.
1. Can you give a brief overview of how to use the prominent Flash API functions?
Answer. Below steps provide a general overview. Some changes are required based on the device that you use. For example, in TMS320F2837xS, Fapi_initializeAPI() and Fapi_setActiveFlashBank() functions should be called whenever the target flash bank is changed, since there are two FMCs (in some part-numbers of this family). However, in TMS320F28004x, these functions do not have to be called when the target bank is changed since there is only one FMC. Please refer to the Flash API reference guide provided for your device in the C2000Ware for particular details.
a. Configure PLL
b. Copy the Flash initialization code from Flash to RAM
c. Copy the Flash API from Flash to RAM
d. Initialize Flash wait-states, fall back power mode, performance features and ECC
e. Grab the ownership of the Flash pump using pump semaphore (not applicable for some devices - ex. TMS320F28004x).
f. EALLOW (C28x) or MWRALLOW (ARM) should be executed before calling Flash API functions to allow writes to protected registers. This is required for Concerto, F2837xD and F2807x devices.
g. EDIS should be executed after calling Flash API functions to disallow writes to protected registers. This is required for Concerto, F2837xD, F2837xS and F2807x devices.
h. Initialize the Flash API by providing the Flash register-base address and operating frequency
Fapi_initializeAPI(F021_CPUx_BASE_ADDRESS,CLK_FREQUENCY);
i. Initialize the Flash bank and FMC for erase and program operations
Fapi_setActiveFlashBank(Fapi_FlashBankX);
j. Erase Flash sectors
Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector, uint32 *pu32StartAddress);
k. Do blank check
Fapi_doBlankCheck(uint32 *Address, uint32 u32Length, Fapi_FlashStatusWordType *poFlashStatusWord);
l. Program the Flash using AutoEccGeneration mode (other modes can also be used as needed)
Fapi_issueProgrammingCommand(uint32 *Address, uint16 *Buffer, uint16 BufferLength, 0, 0, Fapi_AutoEccGeneration)
m. Verify that the Flash is programmed correctly
Fapi_doVerify(uint32 *Address, uint32 u32Length, uint32 *pu32CheckValueBuffer, Fapi_FlashStatusWordType *poFlashStatusWord);
2. Why are the above Flash API functions different than that of some other C2000 devices like F2802x, F2803x, F2805x, F2806x, F2833x?
Answer. Flash wrapper (or the Flash Module Controller, FMC) is different in these devices. FMC in F28M35x, F28M36x, F2837xD, F2837xS, F2807x, F28004x devices support ECC, 128-bit programming, faster erase and program etc. API for these devices takes benefit of these features.
3. What are the common debug tips that we can consider when Flash API fails to erase or program?
Answer. Please check below items:
(i) Make sure that the PLL is configured properly for the required system frequency
(ii) Make sure that the Flash wait-states are configured correctly as per the datasheet
(iii) Make sure that the Flash initialization routine is executed from RAM. Copy the Flash initialization routine from Flash to RAM.
(iv) Make sure to execute EALLOW (C28x) or MWRALLOW (Concerto ARM) before calling Flash API functions. This is applicable for F28M35x, F28M36x, F2837xD, F2837xS, F2807x devices.
(v) Make sure to not execute the Flash API and functions that call Flash API from the Flash bank on which the current erase/program operation is targeted. In Single bank devices, these should be executed from RAM. In dual bank devices, these functions should be executed from RAM or the bank on which the current erase/program operation is not targeted. When the application is designed to execute the Flash API (and the functions that call Flash API) from RAM, copy these functions from Flash to RAM before executing them.
(vi) Above is applicable for the functions in Fapi_UserDefinedFunctions.c file as well. Note that this file is not provided for some devices (ex – F28004x) since it is not needed for those devices.
(vii) Make sure to grab Flash pump semaphore for the core or FMC, where applicable. Note that there is no pump semaphore in F2837xS Single bank devices and F28004x devices.
(viii) Make sure to configure FLSEM register (called as SECZONEREQUEST in Concerto) for the respective security zone (where applicable).
(ix) Make sure to execute the Flash API from the same security zone as that of the Flash sector on which the current erase or program operation is targeted.
(x) Make sure to include EALLOW (for C28x) or MWRALLOW (Concerto ARM) before the return statement in Fapi_serviceWatchdogTimer(), if this function is used to service the watchdog timer.
(xi) Make sure that the voltage supply is able to meet the data manual specification during the Flash operations. This prevents the device from power-starving. If this is not taken care, flash/OTP corruption may happen.
(xii) Make sure to check the FMSTAT register after each of the erase and program operations to identify any failures.
(xiii) After erase operation is over, use Fapi_doBlankCheck() to check whether the sector is erased or not.
(xiv) After program operation is over, use Fapi_doVerify() to check whether the data is programmed correctly or not. Note that 32-bits is the minimum that can be checked using this function.
4. Why and when should Fapi_initializeAPI() be called?
Answer. After the device is first powered up, this function should be called once with appropriate parameters to initialize the Flash API internal state variables before any other Flash API operation is performed. This function should also be called if the System frequency or RWAIT is changed after this function is initially called. Also, for F2837xS devices, since there are the two FMCs for a single core, this function should be called whenever the target bank (and hence FMC) is changed for Flash operations. Note that Flash wait-states should be configured before calling this function.
5. Why and when should Fapi_setActiveFlashBank() be called?
Answer. This function initializes the FMC for further operations to be performed on the bank. This function is required to be called after the Fapi_initializeAPI() function and before any other Flash API operation is performed. For a given FMC, there is no need to call this function more than once, unless the System frequency or RWAIT are changed after this function is initially called. Also, for F2837xS devices, since there are two FMCs for a single core, this function must also be called whenever the target bank (Bank0 or Bank1) is changed. For F28004x devices, there is only one FMC in spite of two banks and hence this function does not need to be called when the target bank is changed.
6. Can we erase the entire bank with a single call of Fapi_issueAsyncCommandWithAddress()?
Answer. No, this function can erase only sector at a time. In order to erase multiple sectors, this function has to be called with each sector’s address provided as the parameter. Note that the least memory range that can be erased is a sector - it is not possible to erase a part of the sector.
7. Does Fapi_issueAsyncCommandWithAddress() support any command other than Fapi_EraseSector?
Answer. No. Use only erase sector command (Fapi_EraseSector) with this function. Bank erase is not supported in C2000 devices.
8. Does Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector, xx) function call return after completing the sector erase operation?
Answer. No, this function issues an erase command to the Flash State Machine for the user-provided sector address. This function does not wait until the erase operation is over; it just issues the command and returns back. Hence, this function always returns success status when the Fapi_EraseSector command is used. The user application must wait for the FMC to complete the erase operation before accessing the Flash bank on which the erase operation is performed. The Fapi_checkFsmForReady() function can be used to monitor the status of an issued command.
9. If the Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector, xx) does not wait for the erase operation completion, how do we know whether the erase operation succeeded or not?
Answer. The user application must check the FMSTAT value when FSM has completed the erase operation. FMSTAT indicates if there is any failure occurrence during the erase operation. The user application can use the Fapi_getFSMStatus() function to obtain the FMSTAT value. See device specific Flash API reference guide provided in C2000Ware for FMSTAT details. Also, the user application should use the Fapi_doBlankCheck() function to verify that the Flash is erased.
10. How many bits can be programmed at a time using Fapi_issueProgrammingCommand()?
Answer. Due to architectural reasons, FSM (in FMC) can program only within a 128-bit aligned memory at a time and not across two 128-bit aligned memory ranges. Hence,
(i) if the address is 128-bit aligned, then a max of eight 16-bit words (128-bits) can be programmed at a time.
(ii) if the address is “128-bit aligned address+1”, then a max of seven 16-bit words can be programmed at a time.
(iii) if the address is “128-bit aligned address+2”, then a max of six 16-bit words can be programmed at a time.
(iv) if the address is “128-bit aligned address+3”, then a max of five 16-bit words can be programmed at a time.
(v) if the address is “128-bit aligned address+4”, then a max of four 16-bit words can be programmed at a time.
(vi) if the address is “128-bit aligned address+5”, then a max of three 16-bit words can be programmed at a time.
(vii) if the address is “128-bit aligned address+6”, then a max of two 16-bit words can be programmed at a time.
(viii) if the address is “128-bit aligned address+7”, then a max of one 16-bit words can be programmed at a time.
Example: Consider an address that is 128-bit (8*16-bit) aligned; Say 0x80000 (0x80000 mod 8 = 0).
(i) If the address given for programming is 0x80000, a max of 8*16-bits can be programmed
(ii) If the address given for programming is 0x80001, a max of 7*16-bits can be programmed
(iii) If the address given for programming is 0x80002, a max of 6*16-bits can be programmed……..
(iv) If the address given for programming is 0x80007, a max of 1*16-bits can be programmed
Again, only addresses within a 128-bit aligned memory range can be programmed at a time. In order to program multiple 128-bit aligned memory ranges, this function should be called to program each range separately.
Note that the minimum number of bits that can be programmed is 1 at any address. API allows programming less than 64-bits to allow program of DCSM link-pointer locations 1 bit at a time.
Even though API allows to program less than 64-bits, it is very important to know that the main array flash programming must be aligned to 64-bit address boundaries and each 64-bit word may only be programmed once per write or erase cycle - This means that all the bits in a given 64-bit aligned memory of main array flash should be programmed at a time. The DCSM OTP programming must be aligned to 128-bit address boundaries and each 128-bit word may only be programmed once. The exceptions are:
– The DCSM Zx-LINKPOINTER1 and Zx-LINKPOINTER2 values in the DCSM OTP should be programmed together, and may be programmed 1 bit at a time (using Fapi_DataOnly mode) as required by the DCSM operation.
– The DCSM Zx-LINKPOINTER3 values in the DCSM OTP may be programmed 1 bit at a time (using Fapi_DataOnly mode), as required by the DCSM operation.
In some devices, a few other user-configurable fields may share the 64-bit aligned memory with the link-pointer. In such scenario, if users want to program those fields separately, they can program using the Fapi_DataOnly command. However, if they want to program the entire 64-bit value together, the user needs to read the link-pointer value and program it along with the other field's value.
11. Does Fapi_issueProgrammingCommand() function call return after completing the program operation?
Answer. No, this function issues a program command to the Flash State Machine for the user-provided address and data. This function does not wait until the program operation is over; it just issues the command and returns back. Hence, the success status returned by this function should not be taken for a successful program operation. A success-status return from this function means that the address, data and/or ECC supplied by the user application meet the requirements of the program operation and that the program command is issued successfully. The user application must wait for the FMC to complete the program operation before accessing the Flash bank on which the program command is issued. The Fapi_checkFsmForReady() function can be used to monitor the status of an issued command.
12. If the Fapi_issueProgrammingCommand() function does not wait for the program operation completion, how do we know whether the program operation succeeded or not?
Answer. The user application must check the FMSTAT value when FSM has completed the program operation. FMSTAT indicates if there is any failure occurrence during the program operation. The user application can use the Fapi_getFSMStatus() function to obtain the FMSTAT value. See device specific Flash API reference guide provided in C2000Ware for FMSTAT details. Also, the user application should use the Fapi_doVerify() function to verify that the Flash is programmed correctly.
13. Why do you have different programming modes for Flash programming function (Fapi_issueProgrammingCommand())?
Answer. Four modes are available:
(i) Fapi_DataOnly: Programs only the data without ECC
(ii) Fapi_AutoEccGeneration: Programs 64-bit or 128-bit data along with the correct ECC generated by API
(iii) Fapi_DataAndEcc: Programs user provided data and ECC (must program either 64-bits or 128-bits at a time along with their ECC)
(iv) Fapi_EccOnly: Programs only ECC without data
Usage scenarios of above modes are provided in a table under the description of this function in the device specific Flash API reference guides provided in C2000Ware.
When using any of the above programming modes (except Fapi_EccOnly) for Flash main array, it is important to note that either 64-bits (aligned) or 128-bits (aligned) should be programmed at a time. When using Fapi_EccOnly mode, either 2 bytes (both LSB and MSB at a location in ECC memory) or 1 byte (LSB at a location in ECC memory) can be programmed.
When using any of the above programming modes (except Fapi_EccOnly) for the DCSM OTP, programming must be aligned to 128-bit address boundaries and each 128-bit word may only be programmed once. The exceptions are:
– The DCSM Zx-LINKPOINTER1 and Zx-LINKPOINTER2 values in the DCSM OTP should be programmed together, and may be programmed 1 bit at a time (using Fapi_DataOnly mode) as required by the DCSM operation.
– The DCSM Zx-LINKPOINTER3 values in the DCSM OTP may be programmed 1 bit at a time (using Fapi_DataOnly mode), as required by the DCSM operation.
14. When using Fapi_AutoEccGeneration mode, what is the minimum number of 16-bit words that can be programmed?
Answer. Four. Note that ECC gets generated for the entire 64-bit aligned memory range assuming 1s for holes. For example, if only one 16-bit word is provided, all the other three 16-bit words will be assumed as all 1s to calculate the ECC. Once ECC gets programmed for a given 64-bit aligned memory, the unprogrammed bits (1s) in that 64-bit word cannot be programmed later without a sector erase since ECC is already programmed for the 64-bit word. Hence, always program 64-bits (aligned) or 128-bits (aligned). This is applicable for Fapi_DataAndEcc mode as well.
We suggest programming 128-bits in one go for below reasons:
A) Flash wrapper can program 128-bits (aligned) at-a-time. Hence, to take advantage of this feature (saves program time), we suggest to program 128-bits in one go.
B) ECC is calculated for 64-bit aligned data and the corresponding address. Alignment of 128-bit guarantees the alignment of both upper and lower 64-bits.
C) There should not be more than two program commands for a given 128-bit aligned memory slice: However this is not applicable for the link-pointer and the JLM_enable locations (or any other fields that share the aligned 64-bit memory with the link-pointers).
15. When using Fapi_AutoEccGeneration mode, for a given 128-bit aligned memory, can I program lower 64-bits at one time and upper 64-bits at another time?
Answer. Yes, ECC gets programmed only for the 64-bits that you supply.
16. Can we enable interrupts while executing Flash API?
Answer. Yes, Flash API is interruptible. However, there should not be any access (fetches or reads) to the Flash bank on which an erase or program operation is in progress. Hence, ISR should be executed from RAM or from a Flash bank (on devices with dual bank per core) on which the current erase/program is not targeted.
17. Why is a NMI (due to double bit errors) occurring when Fapi_setActiveFlashBank() is called on F2837xD CPU2?
Answer. This function accesses TI-OTP for initializing FMC. ECC for the TI-OTP is programmed incorrectly for few devices (during a bounded date range) and hence NMI occurs (and the NMIFLG[FLUNCERR] will be set to 1) when this function is called with ECC enabled (ECC_ENABLE register). Hence, please disable ECC check (ECC_ENABLE = 0) before calling below API functions.
a. Fapi_setActiveFlashBank(Fapi_FlashBank0);
b. Fapi_getDeviceInfo();
c. Fapi_getBankSectors();
If ECC is not disabled, the device will execute the application NMI handler if it is defined. If an application NMI handler is not defined, the default NMI handler in Boot ROM will operate per the TMS320F2837xD Dual-Core Delfino Microcontrollers Technical Reference Manual (SPRUHM8) table “Boot ROM Exceptions and Actions”. ECC check can be enabled after the execution of above functions.
Except for CPU2 flash programming, there is no impact to other device functionality or normal main flash array ECC checking while executing the application out of Flash. TI sent a SIEP letter to customers explaining the same.
Sample code to disable ECC checking on CPU2 TI-OTP before using above Flash API functions is given below.
EALLOW;
// // At reset, ECC is enabled. Disable ECC before calling // Fapi_setActiveFlashBank() function on F2837xD CPU2 // Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0x0;
//
// Flush CPU pipeline
//
__asm(" RPT #7 || NOP");
//
// Fapi_setActiveFlashBank function sets the Flash bank and FMC
// for further Flash operations to be performed on the bank
//
oReturnCheck = Fapi_setActiveFlashBank(Fapi_FlashBank0);
if(oReturnCheck != Fapi_Status_Success)
{
//
// Check Flash API documentation for possible errors
//
Example_Error(oReturnCheck);
}
// // Re-enable the ECC // Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0xA;
//
// Flush CPU pipeline
//
__asm(" RPT #7 || NOP");
EDIS;
If the workaround is used there is no impact to flash programming and the material is fully functional. There is no long term reliability risk. In all cases, the Flash API uses a checksum to validate the TI-OTP contents when Fapi_setActiveFlashBank() is called (which will return an error code in the event of a checksum failure). The use of ECC checking on CPU2 TI-OTP during use of the above listed Flash API functions is not required to assure proper flash programming.
The APIs Fapi_getDeviceInfo() and Fapi_getBankSectors() do not perform a checksum of the TI-OTP, and could return incorrect data when called with ECC checking disabled if there are one or more bit errors in the TI-OTP (and in the case of Fapi_getBankSectors() an error code may also be returned). These functions are informational only however and do not affect flash programming. If there is concern about the validity of the return data, then Fapi_setActiveFlashBank() can be called first to check the integrity of the TI-OTP. As previously stated, it will return an error code if the checksum fails.
18. In order to erase or program a sector, can we execute Flash API from a different sector of the same flash bank?
Answer. No, Flash API functions and the application functions that call Flash API should not be executed from the same bank. They should be executed from RAM or other Flash bank (if another bank exists for the same core).
19. On Concerto and F2837xD, F2837xS and F2807x devices, how can we use the empty Fapi_serviceWatchdogTimer() function provided in the Fapi_UserDefinedFunctions.c file to service the watchdog during Flash API execution?
Answer. This function can be used to service the watchdog timer when using any of the Flash read functions like Fapi_doBlankCheck() and Fapi_doVerify(). Since these read functions take considerable amount of time to read the entire Flash (when used for entire bank), this watchdog service function is called by the API at regular intervals (whenever the address being read crosses the 256-word (16-bit word) aligned address boundaries). This function is provided in the Fapi_UserDefinedFunctions.c file. User has to write the code for it and compile it with the application. Users may modify this function as needed, but must ensure that they include EALLOW (or MWRALLOW for Concerto ARM) before the return statement at the end of this function so that Flash API can write to protected registers as needed.
Note that this function is called by the API only in the read functions. Since Flash API execution is interruptible, instead of using this function, user application can configure the watchdog and service it at regular interrupts (for example, by using a timer ISR) as needed. However, there should not be any read or fetch access from the Flash bank/OTP when an erase or program operation is in progress. Therefore, ISR should be executed from RAM when a Flash erase/program operation is active.
If the device is secured, note that this function should be executed from the same security zone as that of the Flash sector on which the current erase/program is targeted. This function should be executed from RAM or the bank on which the current erase/program is not targeted.
20. In Concerto and F2837xD devices, how do we use Fapi_setupBankSectorEnable() and Fapi_setupBankSectorEnable() provided in Fapi_UserDefinedFunctions.c file?
Answer. Users should not modify these functions and compile them as is, even though these functions are provided in the Fapi_User Defined Functions.c file. These functions are not merged into the library and are provided in the User-Defined section to maintain the same code across TI devices that share common code. These functions are merged into the library in subsequent devices. If the device is secured, note that these functions should be executed from the same security zone as that of the Flash sector on which the current erase/program is targeted. These functions should be executed from RAM or the bank on which the current erase/program operation is not targeted.
21. Why is the data buffer size is in 16-bit words for C28x Fapi_issueProgrammingCommand() and is in 32-bit words for Fapi_doVerify()?
Answer. Since Flash read bus-width is 128-bits, a 32-bit verify will balance the performance and flexibility and hence provided the 32-bit verify option. When you program only 16-bits, you can append the data with the other 16-bits of Flash data for verify or verify once 32 bits are programmed. Note that blank check is also performed using 32-bit word reads. Hence, user application should send the length in 32-bit words for verify and blank check functions.
22. When using Flash API in F2837xS dual bank devices, why do we need to switch the pump semaphore between the two banks when both banks are assigned for the same core?
Answer. Even though both banks are connected to the same core, each bank has its own FMC (unlike F28004x dual bank devices where there is only one FMC) and hence the pump semaphore should be used to connect the pump to the appropriate FMC for its erase/program operations. Also, for the same reason, Fapi_initializeAPI() and Fapi_setActiveFlashBank() functions should be called with appropriate parameters whenever the target Flash bank is changed for erase/program operations in F2837xS (this is not required in F28004x since there is only one FMC).
23. Why Fapi_getDeviceInfo() is not supported in F2837xS and F28004x devices?
Answer. Information like the number of banks, pins, memory size etc. is provided in the Data Manual for every PART NUMBER (PARTID). User application can infer these details without the need of this function.
24. Why Fapi_getBankSectors() is not supported in F2837xS and F28004x devices?
Answer. Information like start addresses of banks/sectors and size of sectors is provided in the Data Manual for every PART NUMBER (PARTID). User application can infer these details without the need of this function.
25. Why Fapi_doMarginRead() is not supported in F2837xS and F28004x devices? F2837xD API supports this function but suggests using only normal read mode – why?
Answer. In F2837xD, this function is used to return the data from the user chosen Flash memory range using a user chosen margin read mode. However, TI decided to not support read margin modes for further devices as empirical data for this Flash technology showed reliable Flash behavior. Hence, TI suggests users to use normal read mode in F2837xD. Later, when Flash API is released for F2837xS and F28004x devices, this function is removed since user applications can read the Flash themselves in normal mode (default).
26. What is the difference between Fapi_CalculateEcc() and CalcEcc()?
Answer. Some applications can't program the main array flash data and the corresponding ECC at the same time since the application will not have all the 64-bits of the data at the same time. In those scenarios, instead of using the Fapi_AutoEccGeneration mode, users will calculate the ECC at a later point of time. Fapi_CalculateEcc() can be handy in such scenarios. Fapi_CalculateEcc() uses the hardware SECDED logic in the device to generate the ECC.
Some applications have special safety considerations that require them to not use the hardware SECDED logic for ECC computation (and hence they don't use Fapi_AutoEccGeneration mode). CalcEcc() can be handy in such scenarios. CalcEcc() does not use the hardware SECDED logic to generate the ECC - instead as you can see in the flash API guide's appendix, it has the SW code to compute the ECC.
Fapi_CalculateEcc() takes very few cycles to generate the ECC since it uses the hardware logic. CalcEcc() takes more cycles as the ECC is computed in SW.
Some applications would like to insert intentional errors in the ECC values (or the main array flash data) - this is not possible when using Fapi_AutoEccGeneration mode. Instead, users can compute the ECC separately (using either Fapi_CalculateEcc() or CalcEcc() as per the application need) and program the data and ECC by inserting errors as needed.
Note when using Fapi_CalculateEcc() : For C28x, make sure the address provided for this function is left-shifted by 1 bit position. FMC expects a byte address for ECC calculation and hence is the left shift required when using this function for C28x in F28M35x, F28M36x, F2837xD, F2837xS and F2807x devices. For the rest of the devices, API takes care of left-shifting the address before calculating the ECC in this function.
27. When using Fapi_DataAndEcc programming mode, I understand that I can program either 64-bits (aligned) or 128-bits (aligned). If the start address is 64-bit aligned but not 128-bit aligned, then only four 16-bit words can be programmed at the same time. In this case, how should I provide the ECC byte (since C28x is 16-bit addressing mode)?
Answer. The LSB of pu16EccBuffer (4th parameter of the Fapi_issueProgrammingCommand()) corresponds to the lower 64-bits and the MSB of pu16EccBuffer corresponds to the upper 64-bits of the 128-bit aligned memory. Hence, fill the upper byte with the ECC value and leave the lower byte as 0xFF in the 16-bit ECC word passed to the Fapi_issueProgrammingCommand(). Note that the u16EccBufferSizeInBytes (5th parameter of the Fapi_issueProgrammingCommand()) should be initialized as 1 since only one byte of ECC is supplied in this case.
28. When using Fapi_EccOnly programming mode, can I program the lower ECC byte (ECC corresponding to lower 64-bits of a 128-bit aligned memory) and the upper ECC byte (ECC corresponding to upper 64-bits of a 128-bit aligned memory) separately or should I program both of them together at the same time?
Answer. This mode can program either 2 bytes (both LSB and MSB at a location in ECC memory) or 1 byte (LSB at a location in ECC memory). MSB alone cannot be programmed. If MSB has to be programmed, add existing LSB (in memory) to the ECC buffer and program both LSB and MSB together.
29. When using Fapi_EccOnly programming mode for Fapi_issueProgrammingCommand(), should we provide Flash main array address or the corresponding ECC address?
Answer. Flash main array address (corresponding to the ECC address) should be provided, even though ECC bytes are provided for program operation.
30. What is the use of Fapi_issueProgrammingCommandForEccAddresses() function?
Answer. Use this function when you want to program ECC data alone by providing ECC space address. Note that Fapi_issueProgrammingCommand() takes main array address whereas Fapi_issueProgrammingCommandForEccAddresses() takes ECC space address. This is useful when streaming an output file that has a separate ECC section (generated by Linker ECC options or anything method) which contains ECC address and ECC data. In such scenario, this function can be used to program the streamed ECC data using the ECC address directly – No need to convert the ECC address to main array address.
31. Why is the Fapi_issueProgrammingCommandForEccAddresses() function not provided in F2837xD, F2837xD and F2807x devices?
Answer. ECC space in these devices is in higher address space (more than 22-bits of address). When API is developed for these devices, far pointers are not yet available and hence this function is not supported. If you want to program ECC data at a known ECC address, you can remap the ECC address in to Flash main array address using Fapi_remapEccAddress() and then program using Fapi_issueProgrammingCommand() with Fapi_EccOnly mode.
32. In F28M35x and F28M36x devices, can we program M3 Flash bank by executing the Flash API on C28x core?
Answer. No, M3 Flash bank can be programmed only by executing the M3 Flash API from M3 RAM.
33. In F28M35x and F28M36x devices, can we program C28x Flash bank by executing the Flash API on M3 core?
Answer. No, C28x Flash bank can be programmed only by executing the C28x Flash API from C28x RAM.
34. In F2837xD devices, can we program CPU1 Flash bank by executing the Flash API on CPU2 core?
Answer. No, CPU1 Flash bank can be programmed only by executing the Flash API from CPU1 RAM.
35. In F2837xD devices, can we program CPU2 Flash bank by executing the Flash API on CPU1 core?
Answer. No, CPU2 Flash bank can be programmed only by executing the Flash API from CPU2 RAM.
36. How to copy the Flash API from Flash to RAM to execute it from RAM?
Answer. Please check the Flash API usage example provided in C2000Ware (controlSuite for Concerto devices). In the example project, you will notice that the Flash API functions are executed from RAM. Observe below from the example:
(a) Linker command file used in the example, allocates Flash API library to .TI.ramfunc section, which has a Flash load address and a RAM run address.
(b) Example's main function calls memcpy() to copy the contents of the above section from Flash to RAM before they get executed.
37. Can we use Flash API to program OTP?
Answer. Yes, as mentioned in the Flash API reference guides, OTP can be programmed by using Flash API. There is no any difference in the API function usage for programming Flash vs OTP. However, note that OTP can not be erased. Make sure to look at the device's data-manual and TRM to know the OTP memory map and the fields available in OTP for users to program or use. Along with that, in F2837xD, F2837xS, F2807x and F28002x devices, note that the DCSM OTP programming must be aligned to 128-bit address boundaries and each 128-bit word may only be programmed once. The exceptions are:
a. The DCSM Zx-LINKPOINTER1 and Zx-LINKPOINTER2 values in the DCSM OTP should be programmed together, and may be programmed 1 bit at a
time as required by the DCSM operation.
b. The DCSM Zx-LINKPOINTER3 value in the DCSM OTP may be programmed 1 bit at a time as required by the DCSM operation.
Also, note that reserved fields in OTP should not be programmed.
38. Apart from using the Flash API library, is there any other way to access Flash state machine's registers to program or erase Flash at run-time?
Answer. No, Flash API library is the only way to erase/program the Flash by the application.
39. Why is there not a depletion recovery algorithm provided for these devices? Is depletion applicable to flash in these devices?
Answer. In C2000 F05 flash devices, power loss during an erase can cause deep depletion making the device unrecoverable. That is not the case with these latest devices - Depletion is not applicable for the flash technology used in these new devices. Hence, we did not provide the depletion recovery algorithm. Also note that power failure during erase on these devices does not cause permanent lock (all 0s password). User can redo erase and continue with programming the flash. But, if power failure happens during program operation, it can corrupt the flash/OTP. If the corruption happens in such a way that all 0s are programmed in password locations, then the device is unrecoverable. If corruption does not result in all 0s password, then the device password locations can be read if the PASSWORDLOCK in OTP is not programmed yet. However, device may get unusable if the corruption occurs in other OTP fields like boot related fields or link-pointers (in DCSM devices) etc.
40. For the PCN20180523001.1 that TI has announced (TMS320F2837x uses "F65 process" flash to replace "F021 process" flash), do we need to use a new Flash API library?
Answer. No, Flash API library does not change. You can continue to use the same Flash API library (F021_API_F2837xD_FPU32.lib) provided in C2000Ware at C2000Ware_x_xx_xx_xx\libraries\flash_api\f2837xd\lib.
41. How can we program a field in USER OTP?
Answer. If you want to program anything in OTP (like BOOTCTRL) as part of your executable, you can define a constant variable (like Z1_BOOTCTRL_value shown below) and assign that variable to a section (like Z1_BOOTCTRL_section shown below) using #pragma DATA_SECTION directive.
#pragma DATA_SECTION (Z1_BOOTCTRL_value, "Z1_BOOTCTRL_section");
volatile const long Z1_BOOTCTRL_value = 0x00000C5A;
In the linker command file, you should define a memory map segment with the origin address and length (like Z1_BOOTCTRL_OTP shown below) so that you can map the section to it.
MEMORY
{
PAGE 1 :
Z1_BOOTCTRL_OTP : origin = 0x7801E, length = 0x2
}
SECTIONS
{
Z1_BOOTCTRL_section : > Z1_BOOTCTRL_OTP, PAGE = 1
}
If you want to program it once during development and don't need it to be part of your executable yet, you can use CCS On-Chip Flash Plugin GUI (CCS Debug view -> Tools -> On-chip Flash) to program the USER OTP fields.
42. This question is applicable only for the F28M35x and F28M36x devices. We programmed all 0s in the DCSM password locations in the flash by mistake. Is there anyway to unlock the device?
Answer. Unless you can execute the flash API from secure RAM to erase the sector in which all 0s password is programmed, the device can not be unlocked. It is permanently locked.
--
Vamsi Gudivada
C2000 System SW Engineering