TMS570LS3137: Cannot access (read) some addresses towards the end of allocated flash

Hi Jose,

Can you share your linker cmd file and the const defined in your project? 

I cannot fully share the CMD or project code.   While debugging this issue further, I noticed that the issue only presents itself after we enable Flash ECC in the code.

We are loosely following HALCoGen 4.07.01 code initialization.  In sys_startup.c, early in _c_int00, we call _coreEnableFlashEcc_:

Before executing line 320 here we are still able to access that memory:

Immediately after executing that line, we lose access.

Is the ECC value programmed when writing data to 0x7FFF8?

Please check the ECC value at 0xF0400000 + 0x7FFF8 / 8

Yes, tha value seems to be programmed.

This is before the enabling the ECC:

This is after:

Hi Jose,

I calculated the ECC value for data at 0x7FFE8, 0x7FFF0, 0x7FFF8, and 0x80000

The ECC value for data at 0x7FFE8 is 0x7F --> it is same as the ECC in your screenshot (at 0xF040FFFD) 

The ECC value for data at 0x7FFF0 is 0x8A --> it is same as the ECC in your screenshot (at 0xF040FFFE) 

The ECC value for data at 0x7FFF8 is 0x24 --> it is different from as the ECC (0x05) in your screenshot (at 0xF040FFFF)

The ECC value for data at 0x80000 is 0x5D --> it is same as the ECC in your screenshot (at 0xF0410000)

Not sure how this is even possible, but you are 100% right!!

We flash the software using Intel HEX files so I manually modified the ECC code in address 0xF040FFFF from 0x05 to 0x24 as you suggested and sure enough I can access the data in address 0x7FFF8 now.

We have something like the following in our CMD file:

...
MEMORY
{
...
    MEMORY_NAME (R) : origin=0x0007FFC0 length=0x00000040 vfill=0xFFFFFFFF
...
    MEMORY_NAME_ECC : origin=0xF040FFF8 length=0x00000008 ecc={ input_range=MEMORY_NAME, algorithm=eccalgo, fill=true }
...
}
ECC
{
eccalgo : address_mask=0x003ffff8 hamming_mask=R4 parity_mask=0x0C mirroring=F021
}
...
SECTIONS
{
...
    .sectName : palign (32), {} > MEMORY_NAME
...
}

We have never had an issue in which the ECC code is incorrectly calculated.  What could be the cause of such an error?

Your CMD file looks good to me.

It is good to use palign(32) in your CMD file. Palign(32) tells the linker to place an output section .sectName at an address that falls on an 32-byte boundary, and ensures that the size of the section is a multiple of 32 bytes, and padding space (unused space in this section) is filled with zero (default). This will avoid getting an ECC error when the cache controller grabs a line that is only partially full of data or code.

Can you try to to allocate .sectName to FLASH0 instead of MEMORY_NAME, and comment out MEMORY_NAME, MEMORY_NAME_ECC in MEMORY{..}?

MEMORY
{
       VECTORS (X) : origin=0x00000000 length=0x00000020 fill = 0xffffffff
       FLASH0 (RX) : origin=0x00000020 length=0x001FFFE0 vfill = 0xffffffff
...

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

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

... 

}

SECTIONS
{
...
.   sectName : palign (32), {} > FLASH0
...
}

I tried changing the CMD as you suggested and I can access the symbol. The code is in active development so the data is different now:

The issue seems to still affect the original address though and seems to have spread to others.

I noticed that when running the instruction to enable flash the data in 0x7FFFFC changed from 0xC... to 0xD... Something similar happened to the data in other addresses too, this might be a display/debugger type of issue as the flash cannot be changing of course.

We need the symbol to be located at the address it was originally. Why could the ECC calculation when generating the HEX file be failing?

Don't you get the same issue if using *.out file instead of HEX file?

We tried flashing the out file as you suggested and we got an error:

Hi Jose,

The out file is generated with a linker cmd file which calculates the ECC. I am not sure why the Linker generated ECC at 0xFFF8 is not correct. Can you replace the VFILL=0xFFFFFFFF with FILL=0xFFFFFFFF for MEMORY_NAME (R)? Can you share your linker CMD file?

If yo use CCS to generate ECC during loading, does the issue exist too?