• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 594 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS570LS1224: CCM error forcing mode

Tomas Kirchner
Prodigy 120 points

Part Number: TMS570LS1224

Hello,

I want to test whether the ESM group 2 ISR is called when the error occurs. To do so, I assert a CCM error forcing mode (write 9h into the ccmkeyr register) after all startup routine is done.

If only IRQ interrupts are enabled, ISR for 'CCM-R4 - self-test failed' is executed and ESM status register for group 2 indicates 'CCMR4 - dual-CPU lock-step error' in deed. That looks OK, but:

If both FIQ and IRQ interrupts are enabled (as the only change against the first step), program get stuck at 0x4 address and ESM status register for group 2 indicates 'CCMR4 - dual-CPU lock-step error', 'TCM - ECC live lock detect' and ESM status register for group 3 indicates 'FMC - uncorrectable ECC error' (3.7. channel). I suppose that ESM high priority ISR is not executed - testing by GIO pin toggle.

What I am expecting is the ESM high priority ISR is called - therefore GIO pin toggled - and only 'CCMR4 - dual-CPU lock-step error' flag is set. Is that right expatiation?

VIM table looks alright, interrupts are enabled by _enable_IRQ() and _enable_FIQ() functions.

Regards,

Tomas

  • 0
    TI__Guru**** 200206 points

    Hi Tomas,

    The ESM high interrupt should be generated. Can you add a breakpoint to ESM ISR in esm.c to check if a ESM high interrupt is generated?

    void esmHighInterrupt(void)
    {
         uint32 vec = esmREG->IOFFHR - 1U;

     

  • 0 in reply to QJ Wang
    Prodigy 120 points

    Hello,

    thank You for the response. The thing is that Core compare error is not generated and flags is not updated upon detection of halting debug requests. And after CPU reset (by STC self-test), the connection with debugger is party lost - I can pause program manually, but breakpoint that I've made in advance do not work. To make them work again I have to load symbols or I can re-set breakpoints at the same places. Is there way to leave breakpoints active as well as the CCM error generation? This might help to debug the problem I have.

  • 0 in reply to Tomas Kirchner
    TI__Guru**** 200206 points

    The CPU reset, SW reset, and debug reset will not reset the breakpoints. The CPU selftest will reset the breakpoints, and you need to set the breakpoints again. The CPU reset generated by CPU selftest doesn't impact the JTAG connection. 

  • 0 in reply to QJ Wang
    Prodigy 120 points

    Hi QJ Wang,

    thank You! Your responses helped me to discover a banal error - our vector table .asm file had been modified and there ldr pc,[pc,#-0x1b0] instruction on the 0x1C address was missing. Is it a proper behavior of the system to go here?

    Now the interrupt is called and it seems everything work nice. Why exactly the #-0x1b0 constant in expression is used? 

    Regards,

    Tomas

  • 0 in reply to Tomas Kirchner
    TI__Guru**** 200206 points

    Hi Tomas,

    For ARM Cortex-R device, the program counter (PC) always pointers two instructions beyond the current executed instruction. In exception vector table, IRQ is located at 0x18 and FIQ is at 0x1C, so PC=0x18+0x08 and 0x1C+0x08.

    IRQ: PC-0x1b0 = 0x18+0x08-0x1b0 = 0xFFFF_FE70        which is the address of IRQVECREG which stores the pending IRQ ISR address

    FIQ: PC-0x1b0 = 0x1C+0x08-0x1b0 = 0xFFFF_FE74        which is the address of FIQVECREG which stores the pending FIQ ISR address

    The base address of the VIM control registers is FFFF FE00h.

  • 0 in reply to QJ Wang
    Prodigy 120 points

    Hello QJ Wang,

    Thank You for Your responses. It is clear to me now.

    With regards,

    Tomas