• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 683 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.

FMC ECC and virgin units

Jeff Denton
Prodigy 60 points

The basic problem is that we get FMC ECC errors on new units loaded with our software. We are only using Bank 0, Sectors 0-4. I'm guessing the errors are due to speculative reads by the processor into the sectors 5-14 and have confirmed by seeing that the double-error address stored in the FMC registers is in this range. We are able to make these errors go away if we flash the unit with a build that includes explicit fills of all these sectors. Our actual application is bootloadable, so we would like to keep our release hex files to a minimal size.

Assumptions:

1. The ECC tables are not populated on a virgin chip.

2. Doing a full flash erase invalidates the ECC tables and they are not re-written unless specifically programming the empty sectors with 0xFF fill and auto-ECC enabled.

Are these assumptions correct? Is there a way to avoid or correct this issue without having to release one build for bootloading that only includes the active sectors and another 4MB build for flashing virgin parts to setup the unused sectors? Of course, if there were a way to turn off the speculative reads in the core, this would probably correct the problem as well, but I didn't see such a setting.

Thanks,

Jeff

  • 0
    TI__Guru**** 190406 points
    Hi Jeff,

    You might find below wiki pages helpful. The wiki pages talk about using the Linker to generate the ECC with the VFILL directive. The VFILL directive will give a much smaller binary than would be with the FILL directive.

    processors.wiki.ti.com/.../Linker_Generated_ECC
    processors.wiki.ti.com/.../LAUNCHXL2_570LC43:_LinkerECCRecommendation_-_VFILL_vs._FILL
  • 0 in reply to Charles Tsai
    Prodigy 60 points
    I've considered this approach, but I think it might cause problems for our build chain and/or bootloader. I'm assuming this approach would embed the Bank 7 ECC tables in the hex files, correct? I'll have to check with someone, but I think our CRC post-build script might choke on the hex file with those memory areas added. Additionally, I think at the moment, our bootloader is setup to write the ECC tables for the sectors it flashes rather than pulling that info from the hex file. I'll speak to someone about whether we can get these two tools to ignore those ranges of extended addresses in the hex file. If so, then that might work--allowing us to release one hex file that can be flashed on the virgin parts with all the sectors ECC'd that still minimizes what we send to the bootloader.

    I'll let you know the results. Thank you.
    Jeff
  • 0 in reply to Jeff Denton
    TI__Guru**** 190406 points

    Hi Jeff,

     This approach will embed the ECC for only the memory section(s) that you instruct the linker to do. It will not include Bank7 if you don't specify it. If you only specify the VFILL for just bank0 then it will only have ECC calculated for bank0.

     One more thing you can consider trying is to use the palign directive. The palign directive will instruct the linker to fill only up to the 32-byte boundary beyond the end of your sections. Please see below. I don't know which device you have. Is it the LC4357 or RM57? These two parts have cache. The cache controller can perform cache refill in size of 32-bytes. Let's say a section of your code ends in 1016 bytes. When the CPU reads the last few bytes of this section it will fetch the last 32 bytes. This will include 1017-1024 for which aren't initialized. This will cause the CPU to detect as uncorrectable ECC error. With the palign (8), fill = 0xFFFFFFFF, the linker will fill 1017-1024 with 0xFFFFFFFF_FFFFFFFF. The auto-ECC from the CCS or the bootloader with the Fapi_AutoEccGeneration will program the corresponding ECC for these holes from 1017-1024. However, if you truly have a speculative fetch that jumps to unimplemented address then you either need to use FILL or VFILL.