Below is a FAQ on Flash ECC usage for these devices: TMS320F28M35x, TMS320F28M36x, TMS320F2837xD, TMS320F2837xS, TMS320F2807x, TMS320F28004x, TMS320F28002x, TMS320F2838x.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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. Note that all the memory ranges should be multiple of 128-bits (since ECC for every 128-bit aligned data is reflected at one address in ECC memory map).
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: address_mask = 0x1FFFFC
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. Please note that program of ECC generated by the linker is supported only on F28004x, F2838x, F28002x and onwards. It is not supported in F28M35x/36x and F2837x/F2807x devices.
41. 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 (preferable is 128-bit alignment since most of the flash programmers program 128-bits at-a-time) in the linker command file for your code project.
Here is an example for C28x (For ARM, ALIGN(16) should be used):
SECTIONS
{
.text : > FLASH, PAGE= 0, ALIGN(8) /* Here ALIGN(8) makes sure that .text section starts on a 128-bit aligned memory address*/
.cinit: > FLASH, PAGE = 0, ALIGN(8)
.const: > FLASH, PAGE = 0, ALIGN(8)
.econst: > FLASH, PAGE = 0, ALIGN(8)
.pinit: > FLASH, PAGE= 0, ALIGN(8)
.switch: > FLASH, PAGE= 0, ALIGN(8)
}
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 (128-bit alignment is preferable since most of the programmers program 128-bits at-a-time).
42. Is ECC image appended to any output format?
Answer: No. Linker ECC generation is supported only for the .out format. Hex tool does not append the ECC section when converting the .out to hex format.
--
Vamsi Gudivada
C2000 System Software Engineering