• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 973 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: Auto ECC with Uniflash, still get ECC error

Neal OHara
Prodigy 90 points
Part Number: TMS570LS3137
Other Parts Discussed in Thread: UNIFLASH, NOWECC,

Hello, I am debugging some legacy code, and I am getting an unexpected ECC error.

Our project has multiple hex files programmed to a TMS5703137CGWTQEP.

The CAN Bootloader (CBL), in BANK 0 Sector 0

The PDIF. in BANK 0 Sector 3 (This is just parameter memory, no execution code)

The APP, in Bank 0 Sector 4


The CBL and APP do NOT have ECC setup in their linker files.

The CBL does not turn on ECC for FLASH.

The APP DOES turn on ECC for FLASH in sys_startup.c with library function _coreEnableFlashEcc_();

We have the nERROR connected to a RED LED, so if I slip and say RED light On, that's what I'm referring to.


My issue is, when I use Uniflash 6.1.0.2829 with Auto ECC turn ON, to program all three software at once, I would expect no ECC errors.

However, my Red Light is in fact coming on. Debugging the registers, I see the following:

Stat3 and FEdacStat show that this the Group 3 Channel 7 error, which is the Uncorrectable FMC bus error

The address of 0x000643E0 is off in Bank 0 Sector 6, which we do NOT program or write to.

The APP also checks for group3 errors in sys_startup.c and and would restart with watchdog if any occur for this startup check, but this is NOT triggering.

So clearly my group3 error is occurring after startup some how.


So, I'm honestly a bit confused that I'm getting a FLASH ECC error even when I program everything with Uniflash with Auto ECC turned on. 

Any advice is appreciated. 

  • 0
    TI__Guru**** 197126 points

    Hi,

    The Cortex-R4 CPU may generate speculative fetches to any location within the ATCM memory space. A speculative fetch to a location with invalid ECC, which is subsequently not used, will not create an abort, but will set the ESM flags for a correctable or uncorrectable error. An uncorrectable error will unconditionally cause the nERROR pin to toggle low. Therefore care must be taken to generate the correct ECC for the entire ATCM space including the holes between sections and any unused or blank Flash areas.

    I suggest that you use linker cmd of bootloader to generate ECC for the whole flash.

  • 0 in reply to QJ Wang
    Prodigy 90 points
    QJ Wang said:
    may generate

    Are speculative fetches deterministic? Is there anyway we can constrain the flash sectors that are checked?

    QJ Wang said:
    care must be taken to generate the correct ECC for the entire ATCM space

    I have the Uniflash set to erase all, an then auto ecc. Shouldn't this combination be deterministic for the ECC checks? Is there anything else I can do from the loader side of things?

    The linker cmd change is currently a poor option for our program, as an actual source code change is not within scope at this time. Any options from the Uniflash side of things would be greatly appreciated.

  • +1 in reply to Neal OHara
    TI__Guru**** 197126 points

    Speculative fetch is not deterministic.

    The "ECC generation" option in Uniflash and CCS enables the ECC calculation for the image only, and doesn't calculate the ECC for the unused flash section. This option may not be sufficient if you are using a custom or third party programming tool or if you want to be certain that the archived image is complete with no chance for change due to outside influences at a later date.

    NowECC is another option for ECC calculation:

    https://www.ti.com/tool/NOWECC

     

  • 0 in reply to QJ Wang
    Prodigy 90 points
    QJ Wang said:
    doesn't calculate the ECC for the unused flash section. T

    Thank you, this triggered my solution via creating a temporary APP with a fill for the unused sectors, then programming that with Uniflash for the correct ECC. I was able to then program our tagged software normally and run with no ECC errors. 

    The speculative fetch being not deterministic is confusing to me. While debugging this issue, I tried three different boards/TMS570LS3137 chips with the same Uniflash settings, and got the same address of 0x000643E0 on all of them. Any thoughts as to why this is?

    While the temp app is a viable solution, I would like to improve this by creating a singular filled hex file for the unused sectors. Is there a convenient way to generate a valid hex file for Sectors 5 to end with only 0xFFFFs?

    Thank you for the advice.

  • 0 in reply to Neal OHara
    Guru 92251 points
    Neal OHara said:
    The speculative fetch being not deterministic is confusing to me.

    Possible ways Cortex-R4 can perform Speculative Access beyond APPLICATION Definition has some information on speculative fetching, of both instructions and data.

    If the speculative fetch only operates on addresses in flash, and the program doesn't modify flash, can see that for a given program on multiple devices the speculative fetch could always be from the same flash address without valid ECC.

    Not sure if a data prefetch for a LDR instruction could try and follow an address in a register which could be different from run-to-run.

  • 0 in reply to Chester Gillon
    Prodigy 90 points

    Thank you for the further information.