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.

TMS320F280039C: CRC/Checksum calculation on CCS editor

Part Number: TMS320F280039C
Other Parts Discussed in Thread: C2000WARE, UNIFLASH

Dear Champs,

In C:\ti\c2000\C2000Ware_4_02_00_00\device_support\f28003x\common\cmd\28003x_generic_flash_lnk_crc.cmd,

1. What is below statement used for? When the user comment this line, there is a warning like this.

"Description Resource Path Location Type
#10247-D creating output section ".TI.memcrc" without a SECTIONS specification SWFW_ServerPSU C/C++ Problem"

Does it matter?

2. For checksum generation on CCS beside the .out file, is the above .TI.memcrc statement required besides below statements? That is, can I just use below for checksum calculation without the above .TI.memcrc statement?

#ifdef __TI_COMPILER_VERSION__
#if __TI_COMPILER_VERSION__ >= 20012000
GROUP { /* GROUP memory ranges for crc/checksum of entire flash */
#endif
#endif

...

#ifdef __TI_COMPILER_VERSION__
#if __TI_COMPILER_VERSION__ >= 20012000
} crc(_ccs_flash_checksum, algorithm=C28_CHECKSUM_16)
#endif
#endif

  • Dear Champs,

    I add one more question.

    3. The user found the checksum read back from the programmed flash by Uniflash was different if the user commented both 1) and 2) statements in the last post. But if the user commented only one of the two, then the checksum read back from Uniflash was same.

    The user wonders why the checksum read by Uniflash is different if both the above statements are commented.

    Do you have any explanation?

    comment .TI.memcrc  Not comment .TI.memcrc
    comment ifdef/endif statement above Checksum read by Uniflash is different Checksum read by Uniflash is same
    Not comment comment ifdef/endif statement above Checksum read by Uniflash is same Checksum read by Uniflash is same
  • .TI.memcrc is the section where CRC tables generated from the crc() function is placed. TYPE=COPY will avoid it being included in the actual .out

    If you comment out .TI.memcrc : type=COPY line, I believe that section gets allocated to some random memory chosen by the linker

     

    Regards,

    Veena

  • Dear Veena

    Thank you for reply (1). 
    Would you please reply (2) and (3)?

    Wayne

  • 2. As mentioned in my reply, If you are using crc() function, memcrc section is automatically created. If it is not explicitly placed in any memory, linker could randomly placed it in an available memory block. So it is highly recommended to use .TI.memcrc : type=COPY.  type=COPY will ensure it is not actually included in the .out

    3. I think it is the same reason as above. Possibly the linker placed the computed CRC in a FLASH region and hence the actual CRC got updated

    Reagrds,

    Veena

  • Dear Veena,

    Do you mean even "type=COPY.  type=COPY will ensure it is not actually included in the .out", it is still placed and influences the flash content so that the checksum result read back by Uniflash seem different?

  • Yes, When you use TYPE=COPY, memory is not allocated and is not loaded to target.

    If you dont specify memcrc section at all, it might get allocated to an available memory block. Can you share your .map file? That should have the details on where it is getting allocated to

    Regards,

    Veena