Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.

C2000 Flash FAQ

From Texas Instruments Wiki
Jump to: navigation, search

Introduction

This wiki page is dedicated to present answers/solutions to the common issues/questions associated with using the internal flash memory of the following C2000 MCUs:

TMS320F28M35x

TMS320F28M36x

TMS320F2837xD

TMS320F2837xS

TMS320F2807x

TMS320F28004x


This covers questions from the Flash ECC, ECC test mode, Linker ECC and Flash API.

C2000 Flash ECC, ECC test mode, Linker ECC

1. Do we need to program ECC for the Flash?

Answer. Yes, it is a must to program ECC for the Flash and OTP. ECC-check is enabled at reset. Hence, if ECC is not programmed, ECC errors will occur. Double bit ECC errors will cause NMI on C28x and bus fault on M3/M4.


2. Do we need to program ECC even if my application disables ECC-check?

Answer. BootROM code does not disable ECC-check. Hence, even if the user application disables ECC at some point in its code, ECC errors still occur when the bootROM jumps to the application code since ECC is disabled only at a later stage in the user application. This will cause a continuous reset cycle and hence application code never gets executed.


3. Do we need to disable ECC-check when programming Flash or OTP?

Answer. In general, there is no need to disable ECC-check during Flash or OTP programming. However, ECC programmed by TI for the TI-OTP is incorrect in TMS320F28M35x Rev0 and TMS320F2837xD devices – Hence, TI released an errata item asking to disable ECC-check when programming Flash or OTP. You can re-enable the ECC-check after Flash programming is over.


4. Is it a must to enable the ECC-check for Flash/OTP reads or fetches?

Answer. It depends on the safety requirements of your application. Enabling ECC-check generates an interrupt for single-bit errors (when the threshold is met) and NMI/bus-fault for uncorrectable errors as mentioned in the above FAQ. Hence, TI suggests enabling ECC-check. Note that ECC must be programmed irrespective of whether ECC-check is enabled or disabled.


5. What do you mean by enabling or disabling ECC-check? Is it same as using Fapi_AutoEccGeneration when programming Flash/OTP using Flash API?

Answer. No, they are different things. You use Fapi_AutoEccGeneration to generate and program ECC when using Flash API to program Flash/OTP. ECC-check is related to the read path of the Flash/OTP. When it is enabled, SECDED logic will check if there are any single or uncorrectable errors in the code/data that is fetched/read from Flash or OTP.


6. How do you enable or disable ECC-check?

Answer. You can use ECC_ENABLE register. Check TRM for its description.


7. Can ECC catch more than two bit errors?

Answer. It can catch only a max of two bit errors.


8. Can SECDED logic correct double bit errors?

Answer. No, it can’t. It can only correct single bit errors before data is given to CPU.


9. Does SECDED logic correct the single bit error in Flash/OTP as well?

Answer. No, it will give the corrected data to CPU but it will not correct the error in the Flash. User application has to erase and program the Flash if the error in the Flash has to be corrected.


10. Does FMC catch errors in the ECC space as well?

Answer. Yes, SECDED logic uses the 64-bit aligned address and the corresponding 64-bit data and 8-bit ECC value to evaluate the correctness of the data read from Flash/OTP.


11. Can we read ECC space to catch errors?

Answer. No, reading the ECC space does not cause SECDED logic to catch errors. Application should read the main array Flash/OTP to catch errors.


12. Do the debugger reads go through the SECDED logic and get corrected?

Answer. No. Debugger shows the Flash data (including errors) as is. Debugger reads do not trigger SECDED logic to evaluate ECC.


13. Are there any cases where ECC does not get evaluated for Flash/OTP reads when ECC check is enabled?

Answer. Yes, SECDED logic skips ECC evaluation when all the 64-bits of data and the corresponding 8-bit ECC value are either all 1s or all 0s. Also, ECC is not evaluated for DCSM link-pointer locations in OTP. Also, avoid using last 128-bits of the Flash bank when prefetch is enabled in the FMC – This is to avoid ECC errors.


14. Can we use ECC space for application code/data?

Answer. No. Fetches are not allowed to Flash ECC space. TI suggests to always program ECC and hence this space can’t be used for application code or data.


15. Can we get ECC algorithm?

Answer. It is provided in the appendix of the Flash API reference guide (for each device) available in C2000Ware.


16. What is the suggested threshold value for single-bit Flash ECC errors?

Answer. It depends on the needs of the application. If the user application can’t tolerate any errors, then of course, a threshold of zero has to be used. Also, Flash technology used in these devices is very reliable. Based on the field empirical data, no fails are reported for this concern. Hence, a threshold of 0 can be used. However, for some C2000 devices, there is an errata (Advisory C28x Flash: A Single-Bit ECC Error May Cause Endless Calls to Single-Bit-Error Interrupt Service Routine) that requires the user application to set the threshold to a value greater than or equal to 1. Please check errata for more details.


17. How many SECDED modules are there in the FMC?

Answer. There are two SECDED modules. Flash read bus width is 128-bits (aligned). There is a dedicated SECDED module for evaluating ECC of the lower 64-bits and upper 64-bits separately.


18. When is the ECC evaluated for the data read/fetched from Flash?

Answer. ECC is evaluated when a read or fetch is done from Flash and before the data is placed in the flash prefetch buffer and cache.


19. Is ECC check available for the cache and prefetch buffer as well?

Answer. No.


20. What are the benefits of using ECC over CRC?

Answer. Both have their own advantages and disadvantages. CRC can be done on the entire Flash image at regular intervals – this takes CPU bandwidth. ECC is analyzed for every read or fetch of the Flash right when the Flash is accessed – this does not take CPU bandwidth. For that matter, even entire Flash bank can be read at regular intervals with ECC enabled to catch any errors if needed. However, ECC can catch a max of two-bit errors.


21. How is ECC calculated?

Answer. An 8-bit ECC value is calculated for every 64-bit data aligned on a 64-bit boundary in the Flash main array. Address of the corresponding 64-bit data is also included in the ECC calculation. Algorithm used for ECC calculation is provided in the appendix of the Flash API reference guides.


22. How can I calculate ECC to program?

Answer. When using Flash API in the application to program Flash, you can pass “Fapi_AutoECCGeneration” as the programming mode parameter for the program function. When this mode is used, API calculates ECC for the user-provided address (aligned on a 64-bit memory boundary) and the corresponding 64-bit data. API programs the calculated ECC along with the main array data when using this mode. If not for a program operation, user application can also calculate ECC using the Fapi_calculateEcc() function provided in the Flash API library. Note that this function uses the SECDED hardware logic in the FMC to calculate the ECC. Note that this function needs a left-shifted (by 1 bit position) address when used 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.

If the user wants to calculate ECC on a host device and not on the target MCU, then ECC calculation algorithm provided in the appendix of the Flash API guides can be used.

When TI Flash tools are used, a setting for “AutoEccGeneration” option is provided, which when enabled (enabled by default unless user disables it) will use the Fapi_AutoEccGeneration option when programming the executable in the Flash/OTP using the API. 3rd party Tools like CodeSkin, Elprotronic, Data I/O and others also use the Fapi_AutoEccGeneration mode to generate and program the ECC for the Flash image.

TI compiler tools offer option to generate ECC at the link step. This requires using special ECC specifier and directive in the linker command file. Using these, ECC for the Flash image can be appended in the executable image. When linker generated ECC is part of the executable image, user should make sure to disable the “AutoEccGeneration” option in the TI Flash tools since ECC is already part of the executable image. When linker generated ECC option is used, there is a provision to insert intentional errors at the selected addresses/offsets at selected bit positions. Please refer to “Error Correcting Code Testing (--ecc Options)” topic in “Linker Description” chapter of the “TMS320C28x Assembly Language Tools” user’s guide for C28x and “ARM Assembly Language Tools” user’s guide for M3/M4.


23. When using ECC specifier and directive in the linker command file, is there a provision in CCS project settings to insert errors?

Answer. Yes, go to project build settings -> Build -> C2000 Linker -> Advanced Options -> Linker Output.

You will notice below options:

(i) --ecc:data_error option

• Inserts error at given address (address can be in main array or ECC space)

• For inserting error in ECC space, you should know the ECC address

• Enter the address (or symbol+offset) where you want to insert error, page, 16-bit bitmask to insert error

(ii) --ecc:ecc_error option

• Inserts error in ECC memory corresponding to given main array address

• For inserting error in ECC space, you don’t need ECC address

• Enter the main array address where you want to insert error at its corresponding ECC memory location, page, bitmask (width is 8bit) to insert error.


24. Can I program Main Array data and ECC memory separately?

Answer. You can program the Main Array data and ECC separately. However, each 64-bit dataword and the corresponding ECC word may only be programmed once per write/erase cycle. Hence, note that all the 64-bits of the data (aligned on the 64-bit boundary) must be programmed at the same time. And also, all the 8-bits of ECC must be programmed at the same time. As mentioned in the API reference guides, this is true even when data and ECC are programmed together - 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/erase cycle.

In case of 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 as required by the DCSM operation.

– The DCSM Zx-LINKPOINTER3 value in the DCSM OTP may be programmed 1 bit at a time, as required by the DCSM operation.


25. Why is that ECC should not be programmed for Link-pointer locations?

Answer. Link-pointer locations need to be programmed 1 bit at a time whenever the ZoneSelect Block gets updated. Once ECC is programmed for any 64-bit data location, that location cannot be programmed again (even to program a 1 to 0) since ECC value would change for the new data value and it is not possible to change the ECC value without an erase. Hence, ECC should not be programmed for Link-pointer locations in order to allow it for later updates.


26. Will Flash API fail if I use Fapi_AutoEccGeneration or Fapi_DataAndEcc or Fapi_EccOnly modes for programming the Link-pointer locations?

Answer. No, instead API will use Fapi_DataOnly mode to avoid programming ECC for the Link-pointer locations. Users have to exercise caution here – When user application or the Flash tools send the link-pointer address as the starting address for program operation, Flash API programs only the data but not the ECC. Hence, when the address provided to the API for program operation is link-pointer address, the length (number of words/bytes) of the data provided to the API should be such that the start address of program plus length should not go beyond the link-pointer locations. If not, Flash API will skip programming ECC for the non-link-pointer locations as well. This will cause ECC errors when application either reads or fetches from those locations for which ECC is not programmed. Hence, in applications, link-pointers should be maintained in a separate structure/section so that when the executable image is streamed by the Flash tools, only the link-pointer related address gets the Fapi_DataOnly mode for programming by the API.


27. How can we notify CPU about the ECC errors?

Answer. Make sure to enable ECC-check by writing a value of 0xA in ECC_ENABLE register. This is the reset value for this register. This will enable SECDED logic to evaluate the data fetched/read from the Flash for the validity. Configure PIE to allow FLASH_CORRECTABLE_ERROR (INT12.11) interrupt from SECDED. Uncorrectable errors (double-bit errors or address-bit errors) will be notified via NMI/BUS FAULT (C28x/ARM) in C2000 devices.


28. What all info is logged when a single bit error is caught by the SECDED logic?

Answer. Please check “Single-Bit Data Error” topic in ‘Flash and OTP Memory” chapter of the TRM.


29. What all info is logged when an uncorrectable error is caught by the SECDED logic?

Answer. Please check “Uncorrectable Error” topic in ‘Flash and OTP Memory” chapter of the TRM.


30. Why is my application stuck in an endless loop of the Single-bit error ISR when a single-bit error is caught?

Answer. Please make sure the error threshold is configured for a value >= 1. Threshold value of ‘0’ can cause this behavior in some devices. Please check errata advisory “Flash: A Single-Bit ECC Error May Cause Endless Calls to Single-Bit-Error ISR”.


31. How can I make sure that the SECDED logic blocks are working correctly at run time?

Answer: Application can use the ECC test mode explained in the “SECDED Logic Correctness Check” topic in the ‘Flash and OTP Memory” chapter of the TRM. In this mode, application can insert errors in the ECC test mode registers (provided for address, data and ECC) and see whether SECDED logic blocks are able to catch the errors or not. When this test mode is enabled, Flash gets bypassed and any reads to Flash address will be made to ECC test mode registers. Address, data and ECC configured in the ECC test mode registers are sent to SECDED logic for evaluation. By using this method, user application can check SECDED logic at the runtime without actually inserting errors in the Flash memory space. Please remember that this mode should be used by executing the code out of RAM since Flash gets bypassed when this mode is enabled.

If application requires that the errors should be evaluated from direct Flash reads (and not from ECC test mode registers), then linker ecc options can be used to insert errors in the Flash image before programming in the Flash. Please refer to “Error Correcting Code Testing (--ecc Options)” topic in “Linker Description” chapter of the “TMS320C28x Assembly Language Tools” user’s guide for C28x and “ARM Assembly Language Tools” user’s guide for M3/M4.

For applications that use Flash API in their firmware upgrade solution, Flash API has a ECC calculation (Fapi_calculateEcc()) function to calculate ECC for a given address and data. User application can use this to calculate ECC. Errors can be inserted in the data and/or ECC as needed by the application. Modified data and ECC can be then programmed in the Flash using Fapi_DataAndEcc mode as the parameter for the Fapi_issueProgrammingCommand().


32. When using ECC test mode, does NMI occur for an uncorrectable error?

Answer. Yes, if NMI is enabled.


33. When using ECC test mode, does Single bit error interrupt occur for a single-bit error?

Answer. Yes, if the interrupt is enabled.


34. When ECC test mode is enabled, do we need to have the ECC enabled (ECC_ENABLE register) for SECDED logic to evaluate the ECC?

Answer. No, SECDED logic evaluates ECC even if the ECC is disabled.


35. When ECC test mode is used in Concerto, why is the single bit error interrupt or the NMI occur continuously when the ECC_TEST_EN bit is enabled after inserting errors?

Answer. ECC test mode, when enabled, will continuously evaluate the test mode registers for errors in every cycle and hence, single-bit error interrupt and/or NMI will occur continuously until the ECC test mode is disabled. To avoid the continuous interrupts, disable the ECC test mode (ECC_TEST_EN = 0) in the flash single-bit error ISR and in the NMI ISR.


36. When using ECC test mode in F2837xD, F2837xS and F28004x devices, why do we have both ECC_TEST_EN and DO_ECC_CALC bits?

Answer. ECC_TEST_EN bit enables ECC test mode by routing address, data and ECC from ECC test mode registers to the SECDED logic blocks. DO_ECC_CALC bit triggers SECDED logic to evaluate the address, data, ECC in FADDR_TEST, FDATAx_TEST and FECC_TEST registers for ECC errors for a single cycle.


37. Are there any advantages of using linker generated ECC than that of AutoEccGeneration?

Answer. Aim of both methods is to generate ECC for the Flash/OTP image. AutoEccGeneration is simple in usage, since users do not have to make any changes to their linker cmd file to use this. However, there are few advantages when ECC is generated as part of the link step:

(i) Some safety applications may require generating the ECC without using the SECDED hardware logic in the target MCU. The source of ECC generation and the source of ECC evaluation should be different for such applications. Linker generated ECC satisfies this requirement since ECC is generated by the compiler during link-step and not by the SECDED logic in the MCU.

(ii) Some customers would like to provide the entire application image to a third party for programming their devices. In such scenarios, customers want to include a checksum for the entire image including the ECC space. Linker generated ECC satisfies this since ECC values are also part of the executable image. Once, third parties program the image in the Flash, customers can run the checksum for the entire Flash image.

(iii) Apart from these, linker provides options to insert errors in the Flash/ECC space so that application can read those error-inserted addresses to check the health of the SECDED logic at run time.


38. Are there any disadvantages of using linker generated ECC than that of AutoEccGeneration?

Answer. Program time is more when linker generated ECC is used since Main Array and ECC space are programmed separately. When AutoEccGeneration is used, both MainArray and ECC space are programmed at the same time. Also, linker command file needs some changes in order to enable linker-generated ECC.


39. What are the changes that we need to make in the linker command file to generate ECC during the link-step?

Answer. Below steps should be followed in changing the linker command file to be able to generate and append ECC to the executable file as a separate section during link-step.

(i) Define ECC memory range for every Flash memory range defined in the MEMORY segment of the linker command file. For example, see below sample linker command file contents. FLASH_A is the Flash Sector A memory range. Corresponding ECC memory range is FLASH_A_ECC. ECC memory range for all the Flash/OTP ranges should be defined in the same way.


Memory

{

PAGE 0: /* Program Memory */

FLASH_A  : origin=0x80000, length=0x2000, vfill = 0xFFFF

FLASH_B  : origin=0x82000, length=0x2000, vfill = 0xFFFF

PAGE 1: /* Data Memory */

FLASH_C  : origin=0x84000, length=0x2000, vfill = 0xFFFF

FLASH_D  : origin=0x86000, length=0x2000, vfill = 0xFFFF


FLASH_A_ECC  : origin=0x1080000, length=0x400, ECC = { /* ECC Specifier */

                                                      input_range = FLASH_A,
                                                      input_page  = 0,
                                                      algorithm   = C2000_Algo,
                                                      fill        = true
                                                     } /* End of ECC Specifier */

FLASH_B_ECC  : origin=0x1080400, length=0x400, ECC = {

                                                      input_range = FLASH_B,
                                                      input_page  = 0,
                                                      algorithm   = C2000_Algo,
                                                      fill        = true
                                                     }

FLASH_C _ECC : origin=0x1080800, length=0x400, ECC = {

                                                      input_range = FLASH_C,
                                                      input_page  = 1,
                                                      algorithm   = C2000_Algo,
                                                      fill        = true
                                                     }

FLASH_D_ECC  : origin=0x1080C00, length=0x400, ECC = {

                                                      input_range = FLASH_D,
                                                      input_page  = 1,
                                                      algorithm   = C2000_Algo,
                                                      fill        = true
                                                     }

} /* End of MEMORY */


SECTIONS

{


/* Allocate sections to memory areas */


} /* End of SECTIONS */


ECC {


C2000_Algo: parity_mask = 0xFC Mirroring = F021


} /* End of ECC Directive */


(ii) Along with the memory attributes like origin and length, you might have noticed that there is an “ECC” specifier in the ECC memory range definition. Linker needs this to realize that it is an ECC memory range defined for a particular Flash Main array definition.

(iii) The first parameter in the ECC specifier is “input_range” - this should point to the corresponding Flash Main array memory range for a given ECC memory range. For example, FLASH_A is the input_range for FLASH_A_ECC memory.

(iv) The second parameter in the ECC specifier is “input_page” - this should point to the PAGE of the corresponding Flash Main array memory range for a given ECC memory range. For example, FLASH_A is defined in PAGE 0. Hence, the input_page for FLASH_A_ECC should be 0.

(v) The third parameter in the ECC specifier is “algorithm” - this is a name that you would choose (can be any name) and is defined later in the command file using the ECC directive (after the SECTIONS segment is defined). In above example, the name of the Algo is chosen as C2000_Algo.

(vi) The fourth parameter in the ECC specifier is “fill” – if you choose “true”, linker would generate ECC data for the holes in the initialized data of the input range. The default is "true". The data that is filled in the holes is specified by using the “vfill” attribute in the input_range. We suggest you to use 0xFFFF for C28x (0xFF for ARM) since default value of the Flash in erased state is all 1s. Note that the ECC will be generated for the holes assuming the provided “vfill” value but the “vfill” value (here 0xFFFF) will not make it in to the executable output file. This will help reduce the size of the executable. If you don’t want to generate ECC for the holes so that you can use that memory later at run time, you can choose “false” input for the “fill” parameter of the ECC specifier. Note that a “vfill” value (suggested as 0xFFFF) should be provided even in the case of a “fill = false” to fill any incomplete 64-bit data (aligned on a 64-bit memory boundary). If “vfill” value is not provided in this case, the compiler will assume 0s for the incomplete data in a 64-bit data. “vfill” value provided in case of “fill=false” case will not be used to fill any 64-bit holes that are completely unused. For more details on the VFILL usage, please refer to “Using the VFILL Specifier in the Memory Map” topic in the “Linker Description” chapter of the “TMS320C28x Assembly Language Tools” user’s guide for C28x and “ARM Assembly Language Tools” user’s guide for M3/M4.

(vii) A top level “ECC” directive should be added to the linker command file as shown at the end of the above given linker command file example to provide parameters for the algorithm that generates ECC data. The name of the algorithm can be any but should match the one that is specified in the ECC specifier. In the above example, name of the algorithm is chosen as C2000_Algo. Parameters provided for the algorithm should be as shown here in the example and they should not be modified by the user. They are the parameters for the ECC algorithm that the compiler uses to generate the ECC values.

(viii) When ECC specifier and the ECC directive are used in the linker command file, compiler will automatically generate the ECC and append it as separate data sections in the executable output.

(ix) Note that AutoEccGeneration in the Flash tools should be disabled when using the ECC specifier and the ECC directive in the linker command file.


40. How can we insert errors in the flash executable output using the linker ecc options?

Answer. Please refer to “Error Correcting Code Testing (--ecc Options)” topic in the “Linker Description” chapter of the “TMS320C28x Assembly Language Tools” user’s guide for C28x and “ARM Assembly Language Tools” user’s guide for M3/M4.


Flash API wiki

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

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.

(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.


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.


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.


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.


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. ECC obtained by using Fapi_CalculateEcc() seems to be incorrect – why?

Answer. 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 provided in Concerto and F28004x APIs?

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 F28004x 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. 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.


Flash Linker cmd file

1. Why do you use align directive (ALIGN(x)) in the linker cmd files provided in the C2000Ware examples?

Answer. Fapi_AutoEccGeneration mode (one of the Flash API programming modes) programs the supplied data portion in Flash along with automatically generated ECC. The ECC is calculated for 64-bit aligned address and the corresponding 64-bit data. Any data not supplied (within a given 64-bit aligned memory) is treated as 0xFFFF. Note that there are practical implications of this when writing a custom programming utility that streams in the output file of a code project and programs the individual sections one at a time into flash. If a 64-bit word spans more than one section (that is, contains the end of one section, and the start of another), values of 0xFFFF cannot be assumed for the missing data in the 64-bit word, when programming the first section. When you go to program the second section, you will not be able to program the ECC for the first 64-bit word since it was already (incorrectly) computed and programmed using assumed 0xFFFF for the missing values. One way to avoid this problem is to align all sections linked to flash on a 64-bit boundary in the linker command file for your code project.


Here is an example for C28x (For ARM, ALIGN(8) should be used):


SECTIONS

{

.text : > FLASH, PAGE= 0, ALIGN(4)

.cinit: > FLASH, PAGE = 0, ALIGN(4)

.const: > FLASH, PAGE = 0, ALIGN(4)

.econst: > FLASH, PAGE = 0, ALIGN(4)

.pinit: > FLASH, PAGE= 0, ALIGN(4)

.switch: > FLASH, PAGE= 0, ALIGN(4)


}

If you do not align the sections in flash, you would need to track incomplete 64-bit words in a section and combine them with the words in other sections that complete the 64-bit word. This will be difficult to do. So it is recommended to align your sections on 64-bit boundaries.