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.

TMS570LC4357: MCU into asynchronous data abort after reset

Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN, RM57L843

Hello there,

The appearance is weird. I use XDS110 USB dongle to download/debug a custom made TMS570LC4357 board, and its possible that board may not able to power up after first reset. The steps to re-create issue is:

1. Connect target board

2. Erase and download program

3. After finish, power off entire board, and re-power board. By now everything runs smoothly.

4. Power off the board again, and then power up. Now it goes into asynchronous data abort. No any extra information to locate error at all! Note that from now, reset is not an option to bring the board back to normal. Only re-download programme can make it run one more time.

I found that this issue may relates to how data are stored in flash/memory. If the problem occur, rebuild the project can not fix the issue. However, modify the scatter/link file to randomly re-locate codes/variables bring chances to remove the bug. In an other words, if the project is working good, adding new codes/variable may introduce this issue.

Project has been stuck by this for more than a month. Please kindly help. What could possible wrong....? Thx!

  • Hello Tian,

    Please use LED rtiBlinky example from HALCoGen to check the SW startup. Since the ECC is enabled at default for LC4357 device. To avoid the ECC error at startup, please generate ECC in linker cmd file:

    processors.wiki.ti.com/.../Linker_Generated_ECC

    TMS570LC4357 and RM57L843
    ECC algorithm
    These devices uses a different connection of the CPU to the flash and different flash wrapper (L2FMC) than TMS570LS and RM4x devices, due to their cached CPU (R5). From an ECC algorithm standpoint the difference is that all Address Bits are participating in the ECC check bit generation.

    ECC {
    algoL2R5F021 : 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 */
    }
    example Memory Map for RM57L843 and TMS570LC4357
    MEMORY
    {
    /* Bank 0 (2MB) */
    VECTORS (X) : origin=0x00000000 length=0x00000020 fill=0xffffffff
    FLASH0 (RX) : origin=0x00000020 length=0x001FFFE0 vfill=0xffffffff

    /* Bank 1 (2MB) */
    FLASH1 (RX) : origin=0x00200000 length=0x00200000 vfill=0xffffffff

    /* Bank 7 (128kB, FEE) */
    FLASH7 (R) : origin=0xF0200000 length=0x00020000 vfill=0xffffffff


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

    ECC_FLA0 (R) : origin=(0xf0400000 + (start(FLASH0) >> 3))
    length=(size(FLASH0) >> 3)
    ECC={algorithm=algoL2R5F021, input_range=FLASH0 }
    /* Bank 1 ECC */
    ECC_FLA1 (R) : origin=(0xf0400000 + (start(FLASH1) >> 3))
    length=(size(FLASH1) >> 3)
    ECC={algorithm=algoL2R5F021, input_range=FLASH1 }

    /* Bank 7 ECC */
    ECC_FLA7 (R) : origin=0xF0100000
    length=(size(FLASH7) >> 3)
    ECC={algorithm=algoL2R5F021, input_range=FLASH7 }

    /* eSRAM (512kB) */
    STACKS (RW) : origin=0x08000000
    length=0x00001500

    RAM (RW) : origin=(end(STACKS))
    length=(0x00080000 - size(STACKS))
    }
  • Hello QJ Wang,

    Appreciate for your kind reply. I understand this may caused by ECC, but how can the first power cycle reset running normally if ECC flashed was broken?

    Under CCS Debug Configurations, we had enabled 'Auto ECC Generation' and 'Align program segments to 64-bit memory regions (for ECC calculation)'. Seems this CCS feature could provide desired ECC flash fill?

    Looking forward to hear you soon! Thx.

    Tien
  • Hello QJ Wang,

    In addition, the startup code we used is copied from Halcogen generated project. In most of the time, it works well without this issue. Key is, occasionally, after adding codes/variables, the broad died (always goes into data abort) after first power cycle.

    Cheers!

    Tien

  • Hello there, anyone can help? Still blocking... Thx..
  • Hi Yiran,

    Did you know where the data abort occurs? does it happen in sys_startup.c or in your main()? What self tests are enabled? did you enable the cache and cache ecc?

    If you can access CP15 registers, read the address for data abort, data abort status.
  • Hello QJ,

    As its a asyn data abort, I have no clue on where the exception occurs...  We have an OS running and codes can always go beyond OS init so its definitely not within sys_startup.. Cache is enabled and the code used to enable it was extract from Halcogen generated project. Through the comments along with the cache enable codes it says ECC is enabled.

    I can access CP15, however, due to the Asyn data abort issue, it gives no useful information...

    Thx.

  • Hi YiRan,

    It is very hard for me to guess where the problem is located because I don't have enough information. Printing debug message can help you narrow down which portion of your code causes the problem.

    Does you code write something to flash or EEPROM as a condition or a flag for your next bootup? Is there any flash region is configured to be accessible by privileged mode only, and your code tries to access it in user mode?

    What is you MPU settings in OS? and what is the value in Data Fault Status Register? Thanks
  • Hi YiRan,

    Are you going to provide more information to help us investigate the problem?
  • HI YiRan,

    I assume you have solved the problem, so I close this thread. If you have any new question, please start another thread. Thanks