TMS570LC4357 - initialization of the Flash ECC section

Hi Jiri,

 Are you trying to fill the unused erased flash memory with ECC because you are creating a bootloader to allow firmware update? Or you just want a way to fill the unused flash memory  with the corresponding ECC as part of the .out program image?

If your goal is the first case then what you are doing is what I will do too by first calculating ECC and then issue the program command to only program the ECC area. 

 If your goal is the second case then there is another way to handle this in the linker command file. In the linker command you can use the -vfill option so that the ECC will be calculated for the unused area and the .out file will contain the ECC for you to load into the flash memory.

Below is an example of the linker command file to do it. Once you have the .out generated, you want to make sure in CCS you disable the auto-ECC since the .out already contains the ECC.

/*----------------------------------------------------------------------------*/
/* Linker Settings                                                            */

--retain="*(.intvecs)"

/* USER CODE BEGIN (1) */
/* USER CODE END */

/*----------------------------------------------------------------------------*/
/* Memory Map                                                                 */

MEMORY
{
/* USER CODE BEGIN (2) */
#if 0
/* USER CODE END */
    VECTORS (X)  : origin=0x00000000 length=0x00000020
    FLASH0  (RX) : origin=0x00000020 length=0x001FFFE0
    FLASH1  (RX) : origin=0x00200000 length=0x00200000
    STACKS  (RW) : origin=0x08000000 length=0x00001500
    RAM     (RW) : origin=0x08001500 length=0x0007EB00

/* USER CODE BEGIN (3) */
#endif
    VECTORS (X)  : origin=0x00000000 length=0x00000020 vfill = 0xffffffff
    FLASH0  (RX) : origin=0x00000020 length=0x001FFFE0 vfill = 0xffffffff
    FLASH1  (RX) : origin=0x00200000 length=0x00200000 vfill = 0xffffffff
    STACKS  (RW) : origin=0x08000000 length=0x00001500
    RAM     (RW) : origin=0x08001500 length=0x0002EB00

    ECC_VEC (R)  : origin=0xf0400000 length=0x4 ECC={ input_range=VECTORS }
    ECC_FLA0 (R) : origin=0xf0400000 + 0x4 length=0x3FFFC ECC={ input_range=FLASH0 }
    ECC_FLA1 (R) : origin=0xf0440000 length=0x40000 ECC={ input_range=FLASH1 }
/* USER CODE END */
}

/* USER CODE BEGIN (4) */
ECC
{
   algo_name : address_mask = 0xfffffff8
   hamming_mask = R4
   parity_mask = 0x0c
   mirroring = F021
}
/* USER CODE END */


/*----------------------------------------------------------------------------*/
/* Section Configuration                                                      */

SECTIONS
{
/* USER CODE BEGIN (5) */
/* USER CODE END */
    .intvecs : {} > VECTORS
    .text   align(8) : {} > FLASH0 | FLASH1
    .const  align(8) : {} > FLASH0 | FLASH1
    .cinit  align(8) : {} > FLASH0 | FLASH1
    .pinit  align(8) : {} > FLASH0 | FLASH1
    .bss     : {} > RAM
    .data    : {} > RAM
    .sysmem  : {} > RAM
	

/* USER CODE BEGIN (6) */
/* USER CODE END */
}

/* USER CODE BEGIN (7) */
/* USER CODE END */


/*----------------------------------------------------------------------------*/
/* Misc                                                                       */

/* USER CODE BEGIN (8) */
/* USER CODE END */
/*----------------------------------------------------------------------------*/

Hi Charles,

I am sorry for my imprecise definition of the question - yes, the 1st option you have described is my primary goal.

Also the 2nd option could be also considered - and your suggestion can be merged with the hint made by Anthony: "For example it doesn't seem necessary to fill the entire 4M if you code is fitting in 384K..."

Anyway, I would prefer the 1st way - in our process and our use, it seems to be more systematical (== the better way).

Charles,

just a thought (maybe the crazy one) - could a change (an extension) of the F021 API functions be considered?

The function Fapi_issueAsyncCommandWithAddress() is determined for erasing any sector. It would be great to add another command type (Fapi_FlashStateCommandsType) that would erase the entire sector and calculate ECC bits for all the cells (64 bits of data) of this sector.

Thanks for your great support,

Best regards,

Jiri

Hi Jiri,
I have two comments.

1. What I suggested is -vfill, not -fill so that the final binary is not 4MBytes. Please take at look at this wiki page about vfill vs fill. processors.wiki.ti.com/.../LAUNCHXL2_570LC43:_LinkerECCRecommendation_-_VFILL_vs._FILL

2. Sorry that at this moment there is no plan to upgrade F021 library. However, I can take your suggestion as a feedback to the library team.

Hi Charles,

thanks for your hints!

I have missed to mention the very important fact - we are using GCC environment instead of CCS ;-) Well, a similar solution could be found within the GCC world as well - but honestly spoken, the Byte filling of a generated HEX file is quite limiting feature - not only due to the huge size of the HEX file; e.g. if you consider something like a multi-application environment...

What a pity, that there is no plan to release a new F021 API version in the near (?) future - the above mentioned option of Fapi_issueAsyncCommandWithAddress() could be useful especially for the new Cortex-Rx generation as TMS570LC4357 is (ECC enabled by default).

Cheers,

Jiri

Hi Jiri,

I should just add that for production - you should make sure the entire flash (used or unused) has been programmed with valid ECC.
Erased flash does not have valid ECC. And on the LC4357 especially ECC is always enabled so if there are ECC errors due to flash that was left erased - this could cause problems in your end application. We don't know how to tell you exactly that the CPU won't fetch something from this area of flash because it's got some features for getting data it *thinks* it might need ahead of time... even if the program flow results in it not actually needing this data. I think the CPU covers this by masking errors if the data isn't actually used but at the system level if you hit the flash in an area the ECC has an error it'll still trigger the ESM even if the CPU itself doesn't take an abort. And you don't want that.