This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/RM44L520: Flash initialization with CCS & XDS200 debugger is not setting Flash ECC correctly

Part Number: RM44L520


Tool/software: Code Composer Studio

I've been tasked to enable ECC for our flash memory.  In sys_startup.c just after RAM ECC is enabled with    _coreEnableRamEcc_() - I enable flash ECC with     _coreEnableFlashEcc_();

CCS is set to erase all of flash, and target settings are set to auto ECC generation.   But after CCS loads this bootloader application, the ECC fails when this blank memory is first read.

I see CCS erasing all of flash, but it is not generating the correct ECC. 


Our software version# is read out of flash just after main, before the F01 Flash API is used.  For now I've moved the enabling of flashecc until our bootloader and app have been updated.

This thread is similar to my situation, but it is closed now.

https://e2e.ti.com/support/microcontrollers/hercules/f/312/p/887304/3284317?tisearch=e2e-sitesearch&keymatch=rm44%252520flash%252520ecc#3284317

Processor:  RM44L520,  I also use TMS570 too but I have not tried enabling flash ecc yet.

CCS:  10.1.1

Debugger:  Blackhawk USB200/XDS200 JTAG

  • Hello Chris,

    When you erase the main flash (bank 0 or bank 1), the corresponding ECC memory is also erased. If Flash ECC is enabled, any read operation to erased main flash will trigger an ECC error since the erase state of the Flash is not a valid ECC condition.

    You can use generate ECC for the whole main flash using linker cmd file.

    Please use guideline in this link to generate ECC using linker cmd file:

  • In CCS, in the debug properties - there is a flash setting that generates autoECC.  I'll add the linker settings as you suggested, but I would not expect I would have to do this.

  • Check out the vfill (virtual fill) option to be defined in the linker command file for the Flash memory region. This allows you to generate the correct ECC for the unused (erased) Flash memory region, so that accesses to erased Flash do not generate ECC errors.

    Note that in some cases, you might want to have an ECC error generated as an access to erased (usually unused) Flash memory is considered to be a CPU code execution error. You could even fill the unused Flash region with a value that would generate a known exception such as an undefined instruction exception. The size of the .out file and the time taken to program this code will be larger (depending on the amount of unused Flash in your application).