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: ESM exception generated using crc in semi cpu mode with rti trigger

Part Number: TMS570LS3137

Hi

I’m stuck with an issue I can’t figure out.

I’m using the CRC module in semi CPU mode triggered by RTI.

The code written is largely inspired by SPNA235 and the corresponding example project.

RTI3 compare is set at 1us like in the example.

 

The CRC tables for my project is as follows:

_boot_crc_table @ 00043060 records: 9, size/record: 24, table size: 224

       .intvecs: algorithm=TMS570_CRC64_ISO(ID=10), load addr=00000000, size=00000020, CRC=1f7dab46cae46a4b

       flashAPI_Text: algorithm=TMS570_CRC64_ISO(ID=10), load addr=00000020, size=00001cc0, CRC=681efbb03fd28603

       .text: algorithm=TMS570_CRC64_ISO(ID=10), load addr=00001ce0, size=0003c720, CRC=608adbf01af3ea34

       .const: algorithm=TMS570_CRC64_ISO(ID=10), load addr=0003e400, size=00001ef8, CRC=41ace6b9b533be9b

       FEE_TEXT_SECTION: algorithm=TMS570_CRC64_ISO(ID=10), load addr=000402f8, size=00001df8, CRC=d33e7c3d359d84b8

       flashAPI_Const: algorithm=TMS570_CRC64_ISO(ID=10), load addr=000420f0, size=00000220, CRC=382cccd4e5d7e60b

       FEE_CONST_SECTION: algorithm=TMS570_CRC64_ISO(ID=10), load addr=00042310, size=000001a0, CRC=0208a83974856964

       .cinit: algorithm=TMS570_CRC64_ISO(ID=10), load addr=000424b0, size=00000bb0, CRC=033294923ac8e483

       .boot_info_section: algorithm=TMS570_CRC64_ISO(ID=10), load addr=0005fff8, size=00000008, CRC=1b00001b00000000

SW works well for the first 2 sections e CRC calculates and comparison match. But CRC module watchdog times out on the 3rd  section. Interrupt flags in CRC notification = 0x10.

The size of the section to calculate the CRC on is larger than in the example project. But I would expect still the CRC module to be able to handle that for large sections of memory.

Digging further the DMA transfer starts but stops PrtBChnSrcAddr == 0x1CF0. 

Executing the code further, ESM kicks in with an undef entry exception. 

ESMStat1 == 0x40,  ESMStat2 = 0x00, ESMStat3 = 0x080.

It suggest an uncorrectble error has been encountered. I tried disabling ECC and initializing the flash bank 0 where the code is running.

Unsuccessl so far.

Could you please point me into the right direction about the cause this behaviour ?

I can share part of if it is useful.

  • I’ve been adapting my linker script to reflect the one of the example project.

    MEMORY

    {

        VECTORS          (X)   : origin=BOOT_START_ADDRESS                           length=0x00000020                                                                                                       fill=0xFFFFFFFF

        BOOTLOADERFLASH  (RX) : origin=(end(VECTORS))                               length=(0x0060000 - (BOOT_START_ADDRESS + size(VECTORS) + BOOT_INFO_SIZE))   vfill=0xFFFFFFFF // 384K

        BOOTLINFO        (RX) : origin=(start(BOOTLOADERFLASH)+size(BOOTLOADERFLASH))        length=BOOT_INFO_SIZE                                     vfill=0xFFFFFFFF // 8Bytes

        FLASH_NVM_SECT1  (RW) : origin=0xF0200000                           length=0x4000                                                                                                       vfill=0xFFFFFFFF // 16K

        FLASH_NVM_SECT2  (RW) : origin=0xF0204000                           length=0x4000                                                                                                       vfill=0xFFFFFFFF // 16K

        FLASH_NVM_SECT3  (RW) : origin=0xF0208000                           length=0x4000                                                                                                       vfill=0xFFFFFFFF // 16K

        FLASH_NVM_SECT4  (RW) : origin=0xF020C000                           length=0x4000                                                                                                       vfill=0xFFFFFFFF // 16K                                                          vfill=0xFFFFFFFF //16K * 4 sectors

     

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

     

        RAM              (RWX) : origin=0x08001500 length=0x0003EB00         vfill=0x0

     

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

                                               length=(0x00000020 >> 3)

                                               ECC={ algorithm=algoL2R5F021, input_range=VECTORS, fill=false }

     

           ECC_BOOTLOADERFLASH (R) : origin=(0xf0400000 + size(ECC_VEC)) // ECC BOOTLOADERFLASH include BOOTLINFO section

                                                      length=((0x0060000 - (BOOT_START_ADDRESS + size(VECTORS) + size(BOOTLINFO)))>> 3) // + BOOT_INFO_SIZE)) >> 3)

                                                      ECC={ algorithm=algoL2R5F021, input_range=BOOTLOADERFLASH, fill=false }

     

           ECC_BOOTLINFO (R) : origin=(0xf0400000 + size(ECC_BOOTLOADERFLASH) + size(ECC_VEC))

                                                      length=(size(BOOTLINFO) >>3 )

                                                      ECC={ algorithm=algoL2R5F021, input_range=BOOTLINFO, fill=false }

    }

    But no success. Exactly same behaviour.

    The DMA transfer stops at address 0xE380 after transferring 50848 bytes of data.

    At 0xE380, there is no hole. 

    .text 0 00001ce0 0003c948
    00001ce0 000058ec ti_fee_util.obj (.text)
    000075cc 00002cdc sys_selftest.obj (.text)
    0000a2a8 000025d4 CanTp_Prv.obj (.text)
    0000c87c 00001e08 CanSM_InternalStateTransition.obj (.text)
    0000e684 000017a8 ti_fee_ini.obj (.text)
    0000fe2c 000014cc CanTp.obj (.text)
    000112f8 0000139c Ios_Std.obj (.text)

    I did not see a limitation on any size of DMA transfer….

    I’m stuck with this but this working being quite key for a robust and performant bootloader.

    On your side did you try to the project I shared with you ? Can you reproduce the problem ?

    Regards

    Seb