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.

Compiler/TMS570LC4357: NowECC versus linker to generate ECC

Part Number: TMS570LC4357
Other Parts Discussed in Thread: NOWECC, UNIFLASH

Tool/software: TI C/C++ Compiler

Hi, I apologize in advance for posting in the incorrect forum (if I am).  We used to use:

nowECC -r5 -f021 16M_ADD -a foo.hex

but since nowECC is no longer supported, we'd like to migrate to having the ECC generated by the linker command file.  The only documentation I could get from nowECC is running it with the -h option, where I get vague information, and seemingly not directly correlated to the information here: h t t p processors.wiki.ti.com/index.php/Linker_Generated_ECC.  For example, the -r5 option description is "To use "ECC in CPU" feature of Cortex-R5" which provides little real information.  How does that translate to the linker command line process?

I tried applying the example given in the wiki, and although I get no errors, the hex file generated has about double the ECC section than in the hex file generated by nowECC.

Ideally, if someone could tell me exactly how to create an identical hex file from the above command line instruction by using whatever linder command line information, I'd be thrilled.

Here is the relevant snip from the linker command file (that generated a bigger ECC section than I was expecting):

ECC {
algoL2R5F021 : address_mask = 0xfffffff8 /* Address Bits 31:3 */
hamming_mask = R4 /* Use R4/R5 build in Mask */
parity_mask = 0x0c /* Set which ECC bits are Even and Odd parity */
mirroring = F021 /* RM57Lx and TMS570LCx are build in F021 */
}

MEMORY
{

PBL_VEC (RWX) : origin, blah blah

PBL_CRC (RW) : origin, blah blah

PBL_TXT (RWX) : origin, blah blah

ECC_VEC (R) : origin=(0xf0400000 + (start(PBL_VEC) >> 3))
length=(size(PBL_VEC) >> 3)
ECC={algorithm=algoL2R5F021, input_range=PBL_VEC}

ECC_CRC (R) : origin=(0xf0400000 + (start(PBL_CRC) >> 3))
length=(size(PBL_CRC) >> 3)
ECC={algorithm=algoL2R5F021, input_range=PBL_CRC}

ECC_TXT (R) : origin=(0xf0400000 + (start(PBL_TXT) >> 3))
length=(size(PBL_TXT) >> 3)
ECC={algorithm=algoL2R5F021, input_range=PBL_TXT}

Could someone help, please?  Thanks!

  • Hello Dan,

    Since you are requesting how to generate the ECC within the linker command file, I assume you are using Ti tools? CCS and Uniflash have the capability to automatically calculate and program the ECC during the programming stage. This following is located under project properties in CCS and there is a similar screen in Uniflash.

    This option eliminates the need to use the NowECC tool or to include ECC generation in the linker command file. If the idea is to end up with an image including the ECC, then it is also possible to read the entire memory back and store it in a file using Uniflash.

    If you still want to use the linker command file options, there are a few posts that exist on this topic. Here are some links to a few of them.

    Hopefully this information is useful to you. Let me know if there are any follow on questions of if these do adequately answer your questions.

  • Hello Dan,

    When I initially read your post I was surprised that you mentioned that NowECC was no longer supported but as I had seen that the link to download the tool on TI.com was inactive, I couldn't determine the real state. After some research, I have found that the link was lost due to the process that was followed to create it within our web organization. This has since been corrected and the updated page should go live int he next 24 hours. i.e., the tool is and will remain available for our customers to use.

    With that stated, it is a mature product and there are no plans for future updates of migration to new platforms as they become available from Microsoft.

    Also, as you pointed out there is an additional, more recently developed method of generating the build image including the ECC. This is by using the linker command file to have the ECC generated at build time and included in the image created (bin, hex, out, elf, coff, etc).

    The other method is to have the ECC values calculated and programmed as part of the programming process as I described in my initial response. This is the latest methodology supported by Uniflash and CCS programmers. This 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.

    One final argument for maintaining the NowECC tool is that it provides a separate, independent engine for calculation of the ECC values. In the case of the ECC generated at program time, the CPU is used to calculate the ECC to be programmed. This means that if there were a flaw in the algorithm of the device, it would propagate into the programmed ECC value and never be realized until it is too late.

    At any rate, many reasons this tool should continue to be available and I have initiated the activity to fix/restore the broken download link.
  • One of the reasons we're interested in migrating away from NowECC is the lack of a linux tool chain option for NowECC.  If this could be addressed, I agree, we'd be happy to continue using NowECC, especially since you've indicated it is not deprecated.

    Thanks

  • Thanks for providing these links - I've gone through them all and although these seem to be similar problems, I'm still unable to solve the issue I'm having.  The fundamental problem is with the same set of code, when building with NowECC, the ECC code generated in the hex file is "X"; when building with the linker (and all the changes required in the linker command file) to generate ECC, the ECC code generated in the hex file is "X + Y" where Y is about the same size as X.  After fooling around with it further, it seems I can reduce the size of Y to just about zero only when explicitly limiting the memory area of the flash section to the size of the code.  So it seems that for some reason when using the linker ECC generation method, the algorithm continues generating code for what should be the 0xffffffff filled space between the end of code and the end of the memory space reserved for it.  I have used the appropriate vfill directives.  Do you have any other suggestions?  Is it worth moving this thread to the NowECC forum?  I'll snip the map file from both instances for further inspection:

    Linker based with size of PBL_TXT = 0xC000

    name origin length used unused attr fill
    ---------------------- -------- --------- -------- -------- ---- --------
    PBL_VEC 00000000 00000020 00000020 00000000 RW X (ffffffff)
    PBL_CRC 00000020 00000100 00000080 00000080 RW (ffffffff)
    PBL_TXT 00000120 0000bee0 00004c70 00007270 RW X (ffffffff)
    ECC_VEC f0400000 00000004 00000004 00000000 R
    ECC_CRC f0400004 00000020 00000020 00000000 R
    ECC_TXT f0400024 000017dc 000017dc 00000000 R

     

    Linker based with size of PBL_TXT = code size (0x4c70)

    name origin length used unused attr fill
    ---------------------- -------- --------- -------- -------- ---- --------
    PBL_VEC 00000000 00000020 00000020 00000000 RW X (ffffffff)
    PBL_CRC 00000020 00000100 00000080 00000080 RW (ffffffff)
    PBL_TXT 00000120 00004c70 00004c70 00000000 RW X (ffffffff)
    ECC_VEC f0400000 00000004 00000004 00000000 R
    ECC_CRC f0400004 00000020 00000020 00000000 R
    ECC_TXT f0400024 0000098e 0000098e 00000000 R

     

    Shouldn't the two maps be the same?  Shouldn't the ECC_TXT be generated just for the "used" portion of PBL_TXT?