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.

TMS570LS3137-EP: runFromRAM causes abort(flashErrorReal)

Part Number: TMS570LS3137-EP
Other Parts Discussed in Thread: HALCOGEN

Hi.
I asked this thread.
Now we need to improve the execution speed of our application.
I tested to run sample program received from Mr.Bob.
It works well.

But abort occurred when we operated our application which changed to operate on RAM.
Timing of abort is Calling  __TI_auto_init()→run_binit()→copy_in()→memset().

I checked the memory browser after calling _coreEnableFlashEcc_ ().


It shows many "????????"
I think that it means uncorrectable Ecc Error.

Is this Why?


The linker command file and the map file are shown below.

・Linker cmd file

MEMORY
{
    VECTORS (X)  : origin=0x00000000
                   length=0x00000020
                   fill= 0xffffffff

    FLASH0  (RX) : origin=0x00000020
                   length=(0x00180000 - size(VECTORS))
                   vfill=0xffffffff

    FLASH1  (RW):  origin=0x00180000
                   length=0x00180000
//                   vfill=0xffffffff

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

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

//    ECC_FLA1 (R) : origin=(0xf0400000 + (start(FLASH1) >> 3))
//                   length=(size(FLASH1) >> 3)
//                   ECC={ algorithm=algoR4F021, input_range=FLASH1 }


    STACKS  (RW) : origin=0x08000000 length=0x00001500

    RAM     (RW) : origin=0x08001500 length=0x0003EB00
}

/* ECC algorithm                                                              */
ECC
{
    algoR4F021   : address_mask = 0x003ffff8    /* Address Bits 21:3                          */
                   hamming_mask = R4            /* User R4 build in Mask                      */
                   parity_mask  = 0x0c          /* set which ECC bits are Even and Odd parity */
                   mirroring    = F021          /* RM4x and TMS570LSx are build in F021       */
}

SECTIONS
{
    .intvecs : {} > VECTORS
    .text    : {} > FLASH0
    .const   : {} > FLASH0
    .cinit   : {} > FLASH0
    .pinit   : {} > FLASH0
    .bss     : {} > RAM
    .data    : {} > RAM
    .sysmem  : {} > RAM
    .binit   : {} > FLASH0
    .runFromRAM :
    {
        BitCbit.obj (.text)
        /* I wrote it in the same way as above. Total 48 .obj Files */
    }
        load = FLASH0,
        run = RAM,
        table(BINIT)
}

・Map file

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  VECTORS               00000000   00000020  00000020  00000000     X  ffffffff 
  FLASH0                00000020   0017ffe0  0000be70  00174170  R  X (ffffffff)
  FLASH1                00180000   00180000  00000000  00180000  RW  
  STACKS                08000000   00001500  00000000  00001500  RW  
  RAM                   08001500   0003eb00  00022607  0001c4f9  RW  
  ECC_VEC               f0400000   00000004  00000004  00000000  R   
  ECC_FLA0              f0400004   0002fffc  0002fffc  00000000  R   


SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
00000000    00000000    00000020   00000020    r-x
  00000000    00000000    00000020   00000020    r-x .intvecs
000067bc    000067bc    0000567c   0000567c    r-x
  000067bc    000067bc    00004cc8   00004cc8    r-x .text
  0000b484    0000b484    000009b4   000009b4    r-- .const
0000be38    0000be38    00000058   00000058    r--
  0000be38    0000be38    00000048   00000048    r-- .cinit
  0000be80    0000be80    00000010   00000010    r-- .binit
08001500    08001500    0001bd0b   00000000    rw-
  08001500    08001500    0001bd0b   00000000    rw- .bss
0801d20c    00000020    0000679c   0000679c    r-x
  0801d20c    00000020    0000679c   0000679c    r-x .runFromRAM
080239a8    080239a8    00000160   00000000    rw-
  080239a8    080239a8    00000160   00000000    rw- .data
f0400000    f0400000    00030000   00030000    r--
  f0400000    f0400000    00000004   00000004    r-- .ecc0
  f0400004    f0400004    0002fffc   0002fffc    r-- .ecc1

  • Hello Takashi-san,

    Did you copy the object files to RAM before or after you enable ECC? The multiple locations with ??????? indicates that the debugger is unable to read those locations which is most likely due to uninitialized ECC memory in RAM. If you enable RAM ECC before memory init and copy to RAM, the ECC values would be updated to correspond to your object code.
  • Thank you for reply!

    Our reset exceprion code(_c_int00) is generated by HALCoGen v04.06.00.
    Calling order is below.

    _coreEnableRamEcc_() → __TI_auto_init()

    _coreEnableRamEcc_() : Enable RAM ECC
    __TI_auto_init(): Object files is copied to RAM

    As a result of various experiments, I guess the upper limit of the .runFromRAM section size is about 16 kb (0x4000).
    When the size of the .runFromRAM section is less than 16 kb (0 × 4000), the RAM operation operates without error.

    Do you know what caused the problem?

  • Hello Takashi-san,

    My guess would be that there is a branch size limitation. i.e., there is often a size limit to how far a branch can jump and the code that you are copying may run into this issue. 16kB seems somewhat small to be this type of limitation, but certainly shouldn't be overlooked. You may want to check the ARM assembler documentation to verify what the max size of a branch can be.
  • Sorry long time no see.
    This problem has not been solved yet.

    I checked assembler maual[spnu118o_ARM Assembly Language Tools_UsersGuide]
    In 8.4.34.3, --trampoline_min_spacing option can change branch code size,right?
    I tried to change, but there was no effect. i.e still occured abort.

    any idea?
  • Additional Information.

    I Changed the way of generating ECC.
    When Enable Auto ECC Generation Setting in CCS, It seems to work fine.
    Why? I need to write special Description in Linker command file?
  • Hello Takashi-san,

    The only explanation I can think is that there was an ECC issue associated with reading and copying the object code into RAM. By enabling the auto ECC generation, you have, most likely, resolved the issue. Perhaps it is related to an unprogrammed area that wasn't getting an ECC value programmed or reading beyond the end of the original object file, etc. If you are using the auto ECC generation, there should be no need for special descriptions in the Linker command file.