nerror pin activation on TMS570LC4357

Hi Martin,

I have forwarded your question to one of our LC4357 device experts. They should reply to you soon.

Hello Martin,
I suspect that the CPU might have performed a speculative fetch to an address in the flash that is erased. If you use CCS to flash your code it will calculate the ECC for the valid code section, not the empty/erased areas. When the CPU tries to fetch from these erased areas, the CPU will detect Bus ECC error even though these speculative fetches are not taken into the CPU pipeline at the end. What you can try to do is in the linker command file, try to fill all the holes in an output section by supplying the fill value after the section definition using fill=0xFFFFFFFF. Try this solution first and see if this sovles the problem.

Hello Martin,
Normally when you use the fill option the output binary will be large. Another option would be to use the vfill (virtual fill). The vfill will not produce a large binary output while calculating the ECC for the holes in the section. To use the vfill option you can use in conjunction with the linker generated ECC capability. At the end of the linker output the binary .out file will have already contain the ECC. When you load this binary into the flash you do not need to enable the autoECC generation feature in the CCS. Please refer to the C Compiler userguide for the vfill option. For the time being, you can use either options and try to see if the Bus ECC error is due to the speculative fetch to the holes.

Hi Charles,

I tried both options:

• Setting the linker fill option to 0xFFFFFFFF. Apparently it did not change anything. The code size in the .map file is still the same and the ESM error is still there when an interrupt is called.
• I added vfill=0xFFFFFFFF in the .cmd to the memory sections I use with my software. The text FFFFFFFF was added in the .map file in the fill column next to the sections but the problem is still present.

Is there a way of knowing which address access caused the error?

Currently I flash with CCS but don't do anything for ECC, I was under the impression it was calculated automatically. Do I need to do something to have the ECC generated?

Thanks,

Martin

Hello Martin,

  Below is an example screenshot of the CCS flash tool config at the lower right corner. The auto ECC generation needs to be checked for LC4357 as the ECC is always enabled. If you are not having any ECC error while you are in the main() then you must have already checked this box or otherwise you will get ECC error at the very beginning of the code. Unfortunately, when Cortex-R5 processor detects an uncorrectable ECC error on its AXI interface it does not record the address that caused the error. Now I'm wondering if the error comes from L2SRAM rather than L2 Flash. Do you have the L2SRAM initialized with known values in your startup code? Can you also check the L2RAMW RAMERRSTATUS register?

  Let's also make sure that ECC values are programmed into the holes in the flash. Please go to the corresponding ECC locations for the erased areas and see if you see bunch of FF's or some programmed ECC values. The ECC are memory mapped starting at 0xF0400000.

Hi Charles,

In the On-Chip flash menu, I have the "Auto ECC Generation" option checked but the align option is not present. Maybe because I am using CCS5.5.

My software currently uses the flash as shown bellow (my program is in FlashBoot):

name origin length used unused attr fill
---------------------- -------- --------- -------- -------- ---- --------
VECTORS 00000000 00000040 00000020 00000020 X (ffffffff)
BOOT_CRC 00000040 00000004 00000000 00000004 R (ffffffff)
BOOT_LENGTH 00000044 00000004 00000000 00000004 R (ffffffff)
FLASHBOOT 0000048 0007ffb8 000129a0 0006d618 R X (ffffffff)

When I look at the code flash, I can see code up to address 0x000129E7 then the flash is erased. In the erased part I see mostly F but not all F. I think this is because of ECC not being programmed or something.
When I look at the ECC memory, address 0xf0400004 is 0xFFFFFFFF and address 0xF040253B and more are 0xFFFFFFFF. The rest is different from 0xFFFFFFFF.

I checked the L2RAM registers and RamErrStat is always 0. I do initialize the RAM at startup.

I can also give you more details on the test procedure I am using.
Using the emulator, I do system reset and CPU reset. (Program pointer goes to address 0)
Using the emulator, I clear errors in ESM1.Stat1,2,3 by writing the same number
Using the emulator, I write 5 in ESM1.ErrKey
I have a break point in the first line of my 1KHz interrupt.
I click RUN and when it breaks I have ESM1.Stat2 = 0x00000008 but ErrPinStat is still 0x1.
I click RUN again and when it breaks again I have ESM1.Stat1 = 0x80000000, ESM1.Stat2 = 0x02000008 and ErrPinStat is 0x0.
L2RAM is still ok, RamErrStat = 0x0

Hope this information will help.

Thanks!

Martin

Hello Martin,

 You said that starting at 0xF040253B the ECC are FFFFFFFF. This suggests that the fill does not work.  0xF040253B is supposed to be the ending address for the ECC corresponding to 0x000129E7 in the program section.  If you do the fill, then it is supposed to fill the rest of the ECC space (after 0xF040253B) with different ECC values. Below is an example linker command file using the fill command.

MEMORY
{
    VECTORS (X)  : origin=APP_START_ADDRESS                length=0x00000020                               fill=0xffffffff
    FLASH0  (RX) : origin=(APP_START_ADDRESS + 0x00000020) length=(0x00180000 - 0x20 - APP_START_ADDRESS) fill=0xffffffff
    FLASH1  (RX) : origin=0x00180000                       length=0x00180000                              fill=0xffffffff

    STACKS  (RW) : origin=0x08000000                       length=0x00001500
    RAM     (RW) : origin=0x08001500                       length=0x0003EB00

 If you are using your default linker command file (i.e. without the fill command) then you need to check the "Align program segments to 64-bit memory regions". Can you please try that and let me know if it works?

 

Hello Charles,

I added the fill=0xFFFFFFFF statement to my 4 first sections. Now the FlashBoot section is completely full, so my program length is now 0x80000 instead of 0x129e8 (kind of a problem because now flashing is longer). Now the ECC gets written until address 0xF0410000. After that it's all 0xFFFFFFFF. Previously I tried vfill=0xFFFFFFFF but it did not seem to work.

But the ESM behavior is still the same.

For the alignment, I don't have the option you are referring to in my version of CCS V5.5.

So I tried to put the align command manually in the .command file like this:

SECTIONS

{

  .intvecs     : palign(8), fill=0xFFFFFFFF {} > VECTORS

  .text        : palign(8), fill=0xFFFFFFFF {} > FLASHBOOT

  .const       : palign(8), fill=0xFFFFFFFF {} > FLASHBOOT

  .cinit       : palign(8), fill=0xFFFFFFFF {} > FLASHBOOT

  .pinit       : palign(8), fill=0xFFFFFFFF {} > FLASHBOOT

  .init_array  : palign(8), fill=0xFFFFFFFF {} LOAD = FLASHBOOT,

                                               LOAD_START(__TI_INIT_ARRAY_Base),

                                               LOAD_END(__TI_INIT_ARRAY_Limit)

But also it doesn't change anything the problem is still the same.

Thanks,

Martin

Hello Martin,
Can you please upgrade to latest CCS version? I don't think the native 5.5 version supports the LC4357. You probably got the drivers from TI offline. Is that correct?

Hello,

A TI REP came to see us when the LC4357 was still in engineering samples and installed us CCS V5.5 with a special update and we have been using this package since this time.

I will upgrade to the latest CCS version and let you know how it goes.

Thanks,

Martin

Hi Martin,

 Glad that you resolved the problem even though I'm not clear what went wrong based on your description. If you have an VIM ECC error when the VIM module reads the vector from the VIM RAM the VIM module will fallback to a default vector specified in the fallback register. I'm not sure if this is the issue if the fallback register is not initiated. I also wonder why you would get a VIM ECC erro. If you run into other issues please let us know.