TMS570LC43 optimization problem

Hi  Simon,

 I think the problem is that the LC43 device is a cache based architecture. You will need to enable cache to see the performance improvement along with the faster frequency. I will suggest  that you use the HalCoGen to generate the device startup.

That's make sense, my cache isn't enabled.

I've used Halcogen to generate code and call enableCache() juste before __TI_auto_init(), but I've got plenty of ESM core errors after I activate the cache.

I suspect that's why we've not activate the cache yet.

Do you have a clue ?

I've try it no change. In fact it doesn't run normally.  There is not just ESM error, it seems crashed or something after a while if I enable the cache.

The code is:

; Enable Cache

.global CoreEnableCache

.asmfunc

CoreEnableCache:

MRC p15, #0, R1, c1, c0, #0 ; Read System Control Register configuration data

ORR R1, R1, #0x1 <<12 ; instruction cache enable

ORR R1, R1, #0x1 <<2 ; data cache enable

DSB

MCR p15, #0, r0, c15, c5, #0 ; Invalidate entire data cache

MCR p15, #0, r0, c7, c5, #0 ; Invalidate entire instruction cache

MCR p15, #0, R1, c1, c0, #0 ; enabled cache RAMs

ISB

bx lr

.endasmfunc

Hi Simon,

 First of all when you get an ESM error which ESM error flags are set? If you are getting a Bus ECC error (Group 2, channel 3) then it is because the CPU  might have read (due to cache refill or due to speculative fetch) from some unimplemented addresses that do not have the corresponding ECC.

 If you have ESM GP2.3 error then please update the linker file per below example. Once you do this you need to make sure you turn off the auto-ECC in the CCS so you don't try to generate ECC on top of ECC. 

Below two posts may also be helpful to you.

Thank you.

Yes that's right, the ESM error is Gr.2 bit 3 (0x08).

Ok I'll use this linker config.

My linker mapping is pretty different than yours tough, and I don't get it where you take the origin and length values of the ECC segments (ECC_VEC (R), ... )

Could you help-me according to mine, for instance APPLCAN1_SPD (R) and FLASHMO (RX) below ?

And by the way, I flash my code using a boot loader, so I don't have to take care about the auto ECC, do I have ?

/*
 *
 */
--heap_size=0x0100
--retain="*(.intvects)"

MEMORY
{
    BOOTLOADER (RX)       : origin = 0x00000000 length = 0x00080000

    VECTORS (X)           : origin = 0x00080000 length = 0x00000040 vfill=0xFFFFFFFF
    CODECRC (R)           : origin = 0x00080040 length = 0x00000004 vfill=0xFFFFFFFF
    CODELENGTH (R)        : origin = 0x00080044 length = 0x00000004 vfill=0xFFFFFFFF
    APPLCAN1_SPD (R)      : origin = 0x00080048 length = 0x00000004 vfill=0xFFFFFFFF
    APPLCAN1_CRC (R)      : origin = 0x0008004C length = 0x00000004 vfill=0xFFFFFFFF
    APPLCAN2_SPD (R)      : origin = 0x00080050 length = 0x00000004 vfill=0xFFFFFFFF
    APPLCAN2_CRC (R)      : origin = 0x00080054 length = 0x00000004 vfill=0xFFFFFFFF
    CODE2ADDR (R)         : origin = 0x00080058 length = 0x00000004 vfill=0xFFFFFFFF
    CODE2LENGTH (R)       : origin = 0x0008005C length = 0x00000004 vfill=0xFFFFFFFF
    FLASHMO (RX)          : origin = 0x00080060 length = 0x0037FFA0 vfill=0xFFFFFFFF   

    RAM_DATA_EXCHANGE_ID  : origin = 0x08000000 length = 0x00000010   /* New meory map unique ID */
    RAM_BOOT_VER (R)      : origin = 0x08000010 length = 0x00000010
    RAM_CAN1_ADR (R)      : origin = 0x08000020 length = 0x00000004
    RAM_CAN2_ADR (R)      : origin = 0x08000024 length = 0x00000004
    RAM_CAN_SPD (R)       : origin = 0x08000030 length = 0x00000004
    RAM_CANPORT_USED (R)  : origin = 0x08000034 length = 0x00000004
    RAM_UDS_RX_ADDR (R)   : origin = 0x08000038 length = 0x00000004
    RAM_UDS_TX_ADDR (R)   : origin = 0x0800003C length = 0x00000004
    RAM_UDS_BOOT_MODE (RW): origin = 0x08000040 length = 0x00000004
    RAM_FREE (R)          : origin = 0x08000044 length = 0x000000BC   

    STACKS (RW)           : origin = 0x08000100 length = 0x00002000
    RAM_NOINIT (RW)       : origin = 0x08002100 length = 0x00000100
    IRAM (RW)             : origin = 0x08002200 length = 0x0007DE00   
}

SECTIONS
{
   .intvecs       : {} palign=8 > VECTORS
   .text          : {} palign=8 > FLASHMO
   .const         : {} palign=8 > FLASHMO
   .cinit         : {} palign=8 > FLASHMO
   .pinit         : {} palign=8 > FLASHMO
   .init_array    : {} palign=8 LOAD = FLASHMO,
                       RUN_START(__TI_INIT_ARRAY_Base),
                       RUN_END( __TI_INIT_ARRAY_Limit)

   .bss           : {} > IRAM
   .data          : {} > IRAM
   .sysmem        : {} > IRAM
   .stack         : {} > STACKS,
                         RUN_START(__STACK_BASE),
                         RUN_END( __STACK_END)

   codecrc        : {} > CODECRC
   codelength     : {} > CODELENGTH
   applcan1_crc   : {} > APPLCAN1_CRC
   applcan1_spd   : {} > APPLCAN1_SPD
   applcan2_crc   : {} > APPLCAN2_CRC
   applcan2_spd   : {} > APPLCAN2_SPD
   bootversion    : {} > RAM_BOOT_VER,      type=NOINIT
   can1address    : {} > RAM_CAN1_ADR,      type=NOINIT
   can2address    : {} > RAM_CAN2_ADR,      type=NOINIT
   udsbootmode    : {} > RAM_UDS_BOOT_MODE, type=NOINIT
   ramNoInit      : {} > RAM_NOINIT,    type=NOINIT

   ramfuncs : {
                  //HighFreqTask.obj (.text)           /*36k*/
              }
              LOAD =  FLASHMO,
              RUN = IRAM,
              LOAD_START(_RamfuncsLoadStart),
              LOAD_END(_RamfuncsLoadEnd),
              RUN_START(_RamfuncsRunStart)

}

Hi Simon,

  The ECC is memory mapped to address starting at 0xF0400000. Please refer to the Memory Map in the datasheet. There is a 8-bit ECC checksum for each 64-bit of data. This means the ECC occupies 1/8 the size of the corresponding data.  So if you look at the example I gave the ECC length is basically 1/8 of the data. Let's pick FLASH1 as example. The FLASH1 bank is memory mapped to start at 0x200000 and its size is 0x200000 as well. The ECC will be 1/8 of 0x200000 which is 0x40000. Since the ECC is memory mapped starting at 0xF0400000, this means the FLASH1 ECC will be starting 0xF0400000 + 0x40000 which is 0xF0440000 with the size of 0x40000. 

Once you generate the .out file with the linking generating the corresponding ECC you don't want to use the CCS to further regenerate ECC. See below screenshot.  See the Auto ECC Generation checkbox needs to be unchecked.

Thank you again. Still have problem though.  I've tried it with:

ECC_VEC (R) : origin=0xf0400000 length=0x8 ECC={ input_range=VECTORS }

//ECC_OTH0 (R) : origin=0xf0400000 + 0x8 length=0x1 ECC={ input_range=CODECRC }

//ECC_OTH1 (R) : origin=0xf0400000 + 0x9 length=0x1 ECC={ input_range=CODELENGTH }

//ECC_OTH2 (R) : origin=0xf0400000 + 0xa length=0x1 ECC={ input_range=APPLCAN1_SPD }

//ECC_OTH3 (R) : origin=0xf0400000 + 0xb length=0x1 ECC={ input_range=APPLCAN1_CRC }

//ECC_OTH4 (R) : origin=0xf0400000 + 0xc length=0x1 ECC={ input_range=APPLCAN2_SPD }

//ECC_OTH5 (R) : origin=0xf0400000 + 0xd length=0x1 ECC={ input_range=APPLCAN2_CRC }

//ECC_OTH6 (R) : origin=0xf0400000 + 0xe length=0x1 ECC={ input_range=CODE2ADDR }

//ECC_OTH7 (R) : origin=0xf0400000 + 0xf length=0x1 ECC={ input_range=CODE2LENGTH }

//

//ECC_FLA0 (R) : origin=0xf0400000 + 0x10 length=0x6fff4 ECC={ input_range=FLASHMO }

ECC_FLA0 (R) : origin=0xf0400000 + 0x8 length=0x6fff4 ECC={ input_range=FLASHMO }

...and stil have ESM error, at least no linker error.

So I figured out ESM errors come from the others segments (ECC_OTHx). I've tried to add them but I don't know how to configure them, always have linker errors. Could-you help-me on this ? length 0x01 or 0x00 don't work.

Another point: even without activate the cache, before I put vFill and adjust the segments like I did, I'd got some ESM errors, but they were trapped in a FIQ interrupt and successfully reset the fault with no crash at run time. Then I'd configured vFill properly and no ESM error. My point is the program could run with ESM errors at that point with no problem. That's not the case now with cache activated. So maybe the cache activation cause a crash and program goes everywhere causing ESM fault. What do you thing, could it be the case ?

Hi Simon,

 Sorry, I just got back.

 This is your memory map for  FLASHMO (RX)          : origin = 0x00080060 length = 0x0037FFA0 vfill=0xFFFFFFFF. So it starts at 0x00080060. If you divide by 8, it becomes 0x1000C. You will add 0x100C to the starting address of ECC space at 0xF0400000 which becomes 0xF041000C.

However, you have ECC_FLA0 (R) : origin=0xf0400000 + 0x8 length=0x6fff4 ECC={ input_range=FLASHMO }. Please change to

ECC_FLA0 (R) : origin=0xf041000C length=0x6fff4 ECC={ input_range=FLASHMO } and try again.

Simon lapointe said:

So I figured out ESM errors come from the others segments (ECC_OTHx). I've tried to add them but I don't know how to configure them, always have linker errors. Could-you help-me on this ? length 0x01 or 0x00 don't work.

What linker errors do you have? You have 8 consecutive 32-bit words starting at 0x00080040-0x000805F. Since they are already consecutive and they are aligned with 64-bit boundary so I think you may not need to -vfill switch for these 8 words. If you still have linker error then I will have to move your post to the compiler forum. Perhaps it is better for you to open a new post in the compiler forum as we have gone through this post multiple times on other questions that I'm afraid the compiler forum team will not understand the MCU specific questions. 

Simon lapointe said:

Another point: even without activate the cache, before I put vFill and adjust the segments like I did, I'd got some ESM errors, but they were trapped in a FIQ interrupt and successfully reset the fault with no crash at run time.

What ESM error flags were set before you activate cache? 

Simon lapointe said:

That's not the case now with cache activated. So maybe the cache activation cause a crash and program goes everywhere causing ESM fault. What do you thing, could it be the case ?

What ESM error flags were set after you activate cache? I hope after you fix the memory map for ECC_FLA0 this crash problem will somehow go away. 

Thank you again for your support.

We can put aside the cache issue for the moment cause I've realized it could really be related to ESM error in some way. I mean I can run with cache activated as long as there is only few ESM errors or no error. It crashes as there is too many. Maybe is related to FIQ handling also, I don’t know. For the moment I could deactivate the CACHE as long as I’ve still got ESM error.

No linker error again. I've read an app note and I use this format:

BOOTLOADER (RX) : origin = 0x00000000 length = 0x00080000 vfill=0xFFFFFFFF

VECTORS (X) : origin = 0x00080000 length = 0x00000040 vfill=0xFFFFFFFF

CODECRC (R) : origin = 0x00080040 length = 0x00000004 //vfill=0xFFFFFFFF

…other 7 segments.

FLASHMO (RX) : origin = 0x00080060 length = 0x0037FFA0 vfill=0xFFFFFFFF

ECC={algorithm=algoL2R5F021, input_range=VECTORS}

ECC_VEC (R) : origin=(0xf0400000 + (start(VECTORS) >> 3))

length=(size(VECTORS) >> 3)

ECC={algorithm=algoL2R5F021, input_range=VECTORS}

ECC_FLA0 (R) : origin=(0xf0400000 + (start(FLASHMO) >> 3))

length=(size(FLASHMO) >> 3)

ECC={algorithm=algoL2R5F021, input_range=FLASHMO}

Obviously this is not enough, I've still got many ESM error as I activate SOME code in my application. The ESM error is always the same in all cases: Gr 2, bit 3.

In the TI wiki page Linked generated ECC, we see: « Please note, that CCS supports the automatic generation of the ECC code when downloading the binary to the target. This feature is enabled by default and could be configured in the Project Settings. It's not possible to use both the CCS integrated ECC generation and Linker Generated ECC at the same time. »

The only CCS option I see is auto-ECC as in debug and flash using JTAG. Is there others places that I shall deactivate the auto-ECC generation ?

I flash my application using an home-made CANBUS bootloader, the boot loader itself (0000-7ffff) is flash using JTAG port CCS environnement with auto-ECC activated.

So 0-80000 is bootloader, the rest it’s application code. As I flash bootloader with JTAG, shall I erase appl area using auto-ECC, or don’t care ?

Do you have any other hints ?

Regards.

Yes your understanding is correct.

I've got some ESM error while in bootloader, but that's NOT an issue apparently cause I'm able to flash my code using bootloader/CAN interface no problem.

In the boot loader, I have to read the application checksum value at 0x00080040 (appl range), that's probablly why I've got error. But again, since I quit bootloader and run application after, I don't really care about boot loader.

The ESM errors I'd talk about up to now is application ESM errors, while I'm running the application.

The steps you describe above is pretty what I already do. I've check them and repeated them again to be sure, but same result.

There is only one thing, the F021 lib, is that correct ?

I call CoreDisableCache() at the very beginning in Startup (application) and do not activated it again. I could check my CPU load and it is high compare when I activate it, so I don't think my cache is activated at all for now. Is there cache refill even when the cache deactivated ?
I've tried both with an without -vFill in the bootloader, no change.
I've tried to JTAG erase all before, after flash bootloader JTAG chosing sectors within 0-7ffff only, and flash CANBUS application, no change.

Once in application, the code don't access any code in boot loader area, at least as long as the application code call methode.

Another information: I said that my code running inside my FIQ interrupt cause ESM errors. If I configure the same interrupt in IRQ and run the same code, no ESM error (if CACHE deactivated). Once I activate CACHE in this scenario, then plenty of ESM errors.

In FIQ (high frequency code in FIQ), I confirm there are esm errors if cache disabled, and the value is Reg 1Ch= 0x008, Reg 28h=0x024, so the same like previous posts.

In Irq  (high frequency code in IRQ), I confirm there is NO esm error if cache disabled.

Ok thanks. I've got little problem to do this experiement: if I use fill (instead of vFill) I've got a little problem with an home made tool that convert .out to another encrypted output format. I guess it could be fix but if it's possible to test the same thing in another way, it could be less time consuming.

So I've just perform this experiment using JTAG flash instead (and use standard .out), using fill and activate the auto-ECC. Sadly I see no change, still ESM gr2:3 erros.

Is it possible that the ESM errors are caused because, during application execution, FIQ interrupt happens, at 0x1c or something, then the automatic ESM check goes to 0x00400000 area to compare ? But since the application executable doesn't take care much of the bootloader vector segment, the 0x00400000 area is erased during the appl flash process, only the ECC code about the application vector segment (0x080000 and its corresponding 0x00400000 + 0x080000/8) is preserved ?

No no no. Sorry, I was talking about the ECC memory 0xF0400000, where the linker generate CRCs. I don't say the FIQ goes there, it is just a guess, I'm searching an explanation why we have ESM error. I was asking myself, as the 0x1c fiq address is reached, where the ECC comparison is done, at 0xf0400000 or

0xf0410000 ?

Anyway, it's like we're going nowhere.

When I did VFILL, I did it with auto-ECC and no linker generated.

I've just done what you said (linker generated, VFILL, disable auto-ECC), the code doesn't work, it always goes to unrecognized (unused) interrupt.

I had erased all flash memory before to flash it.

VECTORS (X) : origin = 0x00000000 length = 0x00000040 vfill=0xFFFFFFFF

CODECRC (R) : origin = 0x00000040 length = 0x00000004 vfill=0xFFFFFFFF

CODELENGTH (R) : origin = 0x00000044 length = 0x00000004 vfill=0xFFFFFFFF

APPLCAN1_SPD (R) : origin = 0x00000048 length = 0x00000004 vfill=0xFFFFFFFF

APPLCAN1_CRC (R) : origin = 0x0000004C length = 0x00000004 vfill=0xFFFFFFFF

APPLCAN2_SPD (R) : origin = 0x00000050 length = 0x00000004 vfill=0xFFFFFFFF

APPLCAN2_CRC (R) : origin = 0x00000054 length = 0x00000004 vfill=0xFFFFFFFF

CODE2ADDR (R) : origin = 0x00000058 length = 0x00000004 vfill=0xFFFFFFFF

CODE2LENGTH (R) : origin = 0x0000005C length = 0x00000004 vfill=0xFFFFFFFF

FLASHMO (RX) : origin = 0x00000060 length = 0x003FFFA0 vfill=0xFFFFFFFF

ECC_VEC (R) : origin=(0xf0400000 + (start(VECTORS) >> 3))

length=(size(VECTORS) >> 3)

ECC={algorithm=algoL2R5F021, input_range=VECTORS}

ECC_FLA0 (R) : origin=(0xf0400000 + (start(FLASHMO) >> 3))

length=(size(FLASHMO) >> 3)

ECC={algorithm=algoL2R5F021, input_range=FLASHMO}

I have never used the way you defined it for ECC_VEC and ECC_FLA0 so I don't know if it is the reason for the problem. I have no idea what algoL2R5F021 means to the linker and how it will guide the linker in calculating ECC. algoL2R5F021 seems like an algorithm for CortexR5 L2 Flash in F021 technology. But I'm not sure if it is sufficient for the linker. You have:

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

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

This is not how we have done it. If you refer to the example command file then I would have re-written for your application as:

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

ECC_FLA0 (R) : origin=(0xf0400000 + (start(FLASHMO) >> 3)) length=(size(FLASHMO) >> 3) ECC={input_range=FLASHMO}

ECC

{

   algo_name : address_mask = 0xfffffff8

   hamming_mask = R4

   parity_mask = 0x0c

   mirroring = F021

}

Once you do this the linker will generate the ECC as part of the .out and you will need to disable the CCS auto-ECC and check the 'None' radio button for the Flash Verification settings. 

Below is the summary i gather. Perhaps you can help me fill out the symptoms you see in each case. 

I've done the changes you proposed, no success:

ECC_VEC (R) : origin=(0xf0400000 + (start(VECTORS) >> 3))

length=(size(VECTORS) >> 3)

ECC={input_range=VECTORS}

ECC_FLA0 (R) : origin=(0xf0400000 + (start(FLASHMO) >> 3))

length=(size(FLASHMO) >> 3)

ECC={input_range=FLASHMO}

...

IRAM (RW) : origin = 0x08002200 length = 0x0007DE00

}

ECC {

algo_name : 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 */

}

To sum up (without bootloader):

- I've got no success at all using Linker Generated ECC (got uncognized interrupt all the way, cache or no cache);

- All my ESM errors are GP2:3

- FILL, Auto-ECC, cache OFF  => no ESM error, cache ON some ESMs error but no crash.

With bootloader: FILL, Auto-ECC, cache OFF => ESM errors == Nb of FIQ interrupt, cache ON crash application.

Regards.

Ok, but I cannot post my code on the forum. Just send-me a message where I can send you my code.