TMS570LS3137: UNIFLASH fails flashing application with embedded ECC

Hello Silbvano,

If using linker cmd to generate ECC, when loading the code to flash:

1. Auto ECC Generation Must be unchecked
2. Perform Blank Check before Program Load Must be unchecked
3. Flash Verification Settings Must be 'None'

The flash bank width is 144 bits wide including 128 data bits and 16 ECC bits. In either standard read mode or pipeline read mode, 128 bits data and 16 bits ECC is read at a time.

If "AUTO ECC Generation" is enabled, the CCS loader will generate 16-bit ECC for every 128-bit data, and program those 144 bits data to flash at a time.

If using Linker to generate ECC, the ECC data is generated using obj files at link stage and ECC data is placed in out file. When loading data, the loader will program the whole data section first, then ECC section. If the data verification is enabled, the written data (plus 16 bits ECC) will be read back every 128-bit write-operation for verification, but the ECC data has not programmed at this moment. So the ECC error will be generated, and the error pin will set too.

Dear Wang,

thanks for your replay.

Using the suggested settings, the download runs, but after that a the "Verify Image" fails. It seams that the ECC section hasn't been correctly programmed anyway.

Hallo Wang,

Yes of course I did. My procedure was:

1) Erase the Flash   -> SUCCESS

2) target power off /power on

3) Load image without any verification  ("no" blank check,  "none" verification)    ->SUCCESS

4) target power off /power on

5) Verify Image -> ERROR

So my question is: removing above steps 4 and 5,  how can I get evidence that what is chip flash is what I have in program file?

Thank you very much

Best Regards

Silvano Battisti

Hello,

Checked your linker cmd file. You don't map .intvecs to VECTORS in SECTIONS of your linker cmd file. 

I did a test of verifying a image (ECC generated throught linker cmd) on uniflash, and it works well:

Dear Wang,

Thank you for your reply. I really appreciate your feedback. I'm so sorry for bothering you.

Yes you are in right the vector wasn't included. It is a very dummy project. I wasn't really interested in a running project but something to download instead of my final application (that has the same flashing issue).  

Anyway, I've added the missing in link command file. But the result doesn't change: failure.

I see your test on the TMS570LC43 family works. Is it a dummy test project? If it is a dummy project could you post it to me so I can try adapting to my TMS family? How written above, I'm not really interested in a running project but in something to flash by JTAG using Uniflash.

My concern is about something missing or wrong in the download session configuration for Uniflash.

Thank you very much again for your support.

Best Regards

Silvano Battisti

PS: I've attached the last test project4186.TestUniflash_R02.zip

You can find the project used for my test (TMS570LC4357 CAN bootloader):

https://git.ti.com/hercules_examples

Dear Wang,

thanks for your example projects.

I build the ls31_can_boot application. I have got the issue.  Moreover I try a build of lc43_can_boot application (after resizing the flash in command link file). I've got the issue again.

Notice that the failure happen on a "virgin" device. You must erase the flash of the micro, power off, power on and than load the application. When you download the application again (on a programmed device) the issue doesn't trigger.

Step to have the issue:

1) Erase the flash  -> SUCCESS

2) Power off

3) Power on

4) Load Application without any verification -> SUCCESS

5) Verify Application -> FAILURE

6) Load Application without any verification -> SUCCESS

7) Verify Application -> SUCCESS

Remark that my CPU is a TMS570LS3137

Can you help me understanding what is happen?

Thank you very much

Best Regards

Silvano Battisti

Hello,

Can you please dump the memory content at 0xF0400E9A and 0x000074D0 (LC4357 device) and 0xF0401358 and 0x00009AC0 (LS3137) of failed and successful verification?

I tested on LC43x launchpad, but I don't have board for LS3137. 

Dear Wang,

Thank you very much for your support

Best Regards

Silvano Battisti

Look at the attached files:

LC43.zip includes the ELF program, the whole dump of ECC bank 0  in failure the dump of whole ECC bank 0 in success and the dump of program limited at 0x10000 bytes.

LS31.zip includes the ELF program, the whole dump of ECC bank 0  in failure the dump of whole ECC bank 0 in success and the dump of program limited at 0x10000 bytes.

Here the difference in ECC at verification failure address 0xF0400E9A including corresponding program flash address.
  -> ECC origin offset 0xE9A
  -> Corresponding program offset = 0xE9A * 8 = 0x74D0

It appears that at "virgin" programming, the ECC stops to be written at the end of the programming address.   I.E. the uniflash stops programming ECC for the bank 0 "filled" region.

Here the difference in ECC at verification failure address 0xF040135B including corresponding program flash address.
  -> ECC origin offset 0x135B
  -> Corresponding program offset = 0x135B * 8 = 0x9AD8

Same as above.

3252.lc43.zip

2772.ls31.zip

Hello,

It looks like that the fill portion is not programmed. Do you see the same issue with CCS? 

Dear Wang,

Yes it is. The fill portion wasn't programmed. 

To be honest I can appreciate only the ECC part of the filled portion because of filled with 0xFF that's the erase value.

Thank you again for your support

Best Regards

Silvano Battisti

Hello,

We need help from CCS team. I don't know why the vfilled portion is not programmed sometimes.