• State
  • Locked Locked
  • Replies 13 replies
  • Subscribers 31 subscribers
  • Views 607 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS570LS3137: Possible issue with ECC Calculation with VFILL

Jose Lopez2
Prodigy 180 points
Part Number: TMS570LS3137
Other Parts Discussed in Thread: TMS5700332, UNIFLASH

Hello,

We have a system that uses the  TMS570LS3137 and the TMS5700332.   For both we have ECC enabled and to be calculated by the linker (will be part of the output intel HEX files).  We've used similar configurations for previous systems with no issues.   We are using TI compiler tool chain v20.2.1 LTS.

For this system we've been getting intermittent errors when flashing the TMS570LS3137 using Code Composer or Uniflash (via CLI). We do not get errors on the other processor.  On Code Composer the error looks like this:

CCS Error

From the address in the error is is evident that the error is in the ECC sections of memory.

While debugging the error we tried changing VFILL to FILL in the linker file for the flash memory sections.  We noticed that when using FILL the error didn't occur.  Using FILL is less convenient as it results in a much larger HEX file size that will be more time consuming to flash.  We compared the HEX files produced with using VFILL and FILL and noticed that there was a difference on the ECC calculated, which I think is incorrect.

This is a screenshot of the ECC codes for a specific section of memory (note that this screenshot is for a different binary from the one used to get the CCS screenshot):

ECC Screenshot

The following is a screenshot of the flash data for that ECC:

On the data side, it seems that when using VFILL zeroes are used for empty memory. When using FILL, FF is used instead.  This doesn't seem to be the reason for the ECC difference as the other ECC codes do match.

What could cause a difference in the ECC calculated using FILL vs VFILL?

We cannot share our source code as it's property of our customer.  We tried setting up a simplified code base but we couldn't reproduce the error there.

Thanks,

Jose Lopez

  • 0
    TI__Guru 69871 points

    Hi Jose,

    We started working on your issue and we will provide an update ASAP.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 180 points

    Hello Jagadish,

    We had previously looked at the link you provided and it is not a good solution for our case.  Our linker command file does follow all recommendations from that topic, we are using "palign" in our sections:

    Thanks!

  • 0 in reply to Jose Lopez2
    TI__Guru 69871 points

    Hi Jose,

    I am transferring this thread to the expert. He will provide you an update soon.

    --

    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    TI__Guru**** 196346 points

    Hi Jose,

    There is a bug in Uniflash (FlashHerciles.dll). Sometimes, the ecc value generated using Linker for the unused flash section is not programmed properly. If you power cycle the board, and reload the program, the ECC will be programmed.

    I will give you the updated dll file later.

  • 0 in reply to QJ Wang
    Prodigy 180 points

    Hello,

    What you are referring to may be a different type of issue.  The issue we are seeing is that the HEX file generated (not flashed) has different ECC depending on if VFILL or FILL is used, would Uniflash somehow affect this?

    Thanks!

  • 0 in reply to Jose Lopez2
    TI__Guru**** 196346 points

    Hi Jose,

    Both FILL and VFILL should fill the flash hole with 0xFFFFFFFF if the fill-pattern is 0xFFFFFFFF. 

    The ECC value in your HEX is correct for FILL case and VFILL case.

    For FILL:

    The data is at 0x3B8F8: 0x 23800001, and 0x000000FF,  --> I got flash address based on your ECC addr offset 0x771F*8 = 0x3B8F8)

    The ECC should be 0x82  (my calculation using ECC table in TRM)

    For VFILL:

    The data is at 0x3B8F8: 0x 23800001, and 0x00000000, 

    The ECC should be 0x88 (my calculation using ECC table in TRM)

  • 0 in reply to QJ Wang
    Prodigy 180 points

    Hi,

    The code using VFILL and FILL didn't have any modifications.  The 0xFF in the data was added by the linker when using FILL. 

    Shouldn't the ECC code be calculated the same way, using 0xFF when using VFILL even if the data is 0x00?.  The fill pattern (when using either FILL or VFILL) is the same 0xFFFFFFFF.

    Thanks!

  • 0 in reply to Jose Lopez2
    TI__Guru**** 196346 points

    Hi Jose,

    For the ECC calculation, the data is aligned a 64-bit boundary (address 0x0~0x07, or 0x8~0xF). The 0xFF (FILL) and 0x00 (VFILL) are used in the ECC calculation as the upper byte (address offset 0xF). 

    Jose Lopez2 said:
    Shouldn't the ECC code be calculated the same way, using 0xFF when using VFILL even if the data is 0x00?

    Same way is used to calculate the ECC. Please refer to the Table 5-1 in TRM: ECC Encoding for BE32 Devices

    Each ECC[x] bit represents the XOR of all the address and data bits marked with x in the same row. For upper data byte (bit 63~56) 0xFF and 0x00, the ECC difference is at ECC bit 3 and ECC bit 1 (odd number of x): 0x82 vs 0x88

    Both ECC values are correct.

  • 0 in reply to QJ Wang
    Prodigy 180 points

    Hello,

    So, considering that the ECC values are correct for both variants (VFILL and FILL). What could be the reason to have flashing issue when using VFILL but not with FILL?

    Is the "updated" DLL part of a specific Uniflash installer or version?

    Thanks!

  • 0 in reply to QJ Wang
    TI__Guru**** 196346 points

    If you use linker to generate ECC for your project, it is necessary to change the loader settings so that the loader doesn’t try to generate ECC. Flash verification during programming needs to be skipped because the data areas and ECC areas will now be programmed in separate steps.

    You can access these settings in “Flash Settings” as shown below and make sure:

    • Auto ECC Generation is unchecked
    • Flash Verification Settings should be ‘None’
    • Perform Blank Check before Program Load must be unchecked

  • 0 in reply to QJ Wang
    Prodigy 180 points

    Hello,

    We had already unselected the "Auto ECC Generation".  When we select "None" in the "Flash Verification Settings" the issue disappears.

    I would assume that since we are not verifying a successful load, there is a small risk that the flash was actually not successful and we wouldn't notice unless we tried to run the software and hit the part that was corrupted.

    You had previously mentioned a bug in Uniflash and an updated DLL.  What version of Uniflash would have the issue resolved?

    Thanks!

    Jose Lopez

  • 0 in reply to Jose Lopez2
    TI__Guru**** 196346 points

    Hi Jose,

    Jose Lopez2 said:
    What version of Uniflash would have the issue resolved?

    The bug has been fixed in the uniflash8.3 released in May.

    The bug is different from yours. The ECC of the unused flash is not programmed sometimes with Linker ECC. It only happens in a very special program sequence. For example, the verification is enabled --> loading fails --> disable verification --> loading program, the ECC of code is programmed correctly, but the ECC of unused flash is not programmed.