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.

TMS320F280049: ECC checksum on UNIFLASH

Part Number: TMS320F280049
Other Parts Discussed in Thread: UNIFLASH

Hi Champs,

Could anyone tell me why ECC checksums are different for the following two cases?

Used tool: UNIFLASH
[Case 1]
 -  Read checksum after flash programming with an original out file generated by the compiler
    Flash (0x80000~0x8ffff) Checksum :0x2B5B
    ECC Checksum: 0xE475

[Case 2]
 - Read checksum after flash programming with an exported out file by UNIFLASH.
   Flash (0x80000~0x8ffff) Checksum :0x2B5B
   ECC Checksum: 0xEF30

 Flash checksum values are the same, but ECC checksum values are different. What can make this situation?

Thanks,
Steve

  • Steve,

    In both cases, did application execute fine as expected?  Or did Case2 application fail with any ECC errors?

    I will loop our Uniflash expert to discuss any differences between the compiled out and the uniflash exported out.

    Thanks and regards,
    Vamsi

  • Hi Steve,

    For Case 2, are you exporting the flash contents from Case 1 as a COFF file and then reflashing it?

    What is the exact version of UniFlash being used?

    Would it be possible to prove the *.out file being used? Please start a private E2E conversation with me if you do not wish to share publicly.

    Thanks

    ki

  • Both cases work fine as expected without any ECC errors.

    -Steve-

  • Yes. I exported the flash contents from Case 1. 
    UniFlash version is v6.1.0.2829.

    I've used our LED blinking example with F280049C controlCARD. Let me send you the files I used via email because a file insert on E2E does not work for me after the E2E major upgrade.Sob 

    Thanks,
    Steve

  • Thanks Steve. I got your e-mail and cc'ed you in my escalation e-mail to out UniFlash expert.

    Let me send you the files I used via email because a file insert on E2E does not work for me after the E2E major upgrade

    Does drag&drop to the reply editor field not work for you?

    Thanks

    ki

  • Steve,

    Thank you for the clarification on the ECC error behavior in both cases.  Please follow-up further with Ki on this.

    Ki, 

    Keep me copied on the internal discussions on this. We need to keep this in our radar when working with other customers as well.

    Thanks and regards,
    Vamsi

  • Steve,

    When the image is exported from Uniflash, did it include any empty spaces (erased locations)? 

    If yes, then ECC image would vary as ECC gets generated for the erased locations when programming the Uniflash exported image. 

    This is the only reason I can think if the application is working fine in both cases with no ECC errors.

    Thanks and regards,
    Vamsi

  • Vamsi,

    As I mentioned on offline, the exported out file have all Bank 0 area including erased location.

    -Steve

  • Steve,

    That explains the ECC difference.  

    When you program the exported image, ECC gets programmed for all the erased locations (all 1s) exported from the device.

    Thanks and regards,

    Vamsi

  • Vamsi,

    Is there any way to keep same ECC checksum for both case?

    Thanks,
    Steve

  • Steve,

    There are two ways to achieve same ECC checksum:

    1. In the original out file that you load, you can fill all 0xFFFFs for the flash range in the linker cmd file.  Note that this will increase program time as it will program entire flash with that change.  But, it will satisfy your requirement to match the ECC of the exported file. 
    2. You can use avoidance range feature in the plugin GUI.  You can provide the address ranges (128-bit aligned) that you want to avoid programming while loading the exported image.  This might be laborious for you to figure out the ranges.  If you know the ranges, then that should be fine.

    Thanks and regards,

    Vamsi