• State Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 8 replies
  • Subscribers 83 subscribers
  • Views 1045 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.

TMS320F28379S: ITRAP with WatchDog-ISR

Alexander Kästner
Prodigy 20 points

Part Number: TMS320F28379S

Hello everybody,

I currently have a problem with the TMS320F27379S.

We use the watchdog interrupt in an application to bring the device into a safe state when the watchdog event occurs.
Four different time slices (96 kHz, 12 kHz, 200 Hz and the main loop) are used.
The interrupts are nested and the following interrupt priorities are set.
Prio 1: Watchdog Int
Priority 2: 96 kHz
Priority 3: 12 kHz
Prio 4: CAN-Int
Priority 5: 200 Hz

The individual time slices are blocked during the test using "while (1);".
The test is functional for 3 of 4 time slices (jump to the WatchDog interrupt).
A jump to the "illegalOperationHandler" occurs only when the 12 kHz time slice is blocked.
Debugging shows that the stack pointer points to an area outside the reserved area.
I also tried increasing stack size from 2048 to 4096 but this didn't resolve issue.
Commenting out the ISR code with the higher priority as a test does not change the result either.

Is there an errata describing this behavior?
Or what else can I test to further narrow down the source of the error?

Best regards
Alex

  • 0
    TI__Guru** 117441 points

    Hi Alex,

    We do have an errata for nested interrupt ("Caution While Using Nested Interrupts") which can cause issues like this. Please check if this apply in your case. 

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 20 points

    Hello Vivek,

    thank you for pointing out the errata.

    We follow the instructions from the errata.

    __asm ("NOP"); before EINT and DINT at the end of the ISR.

    But the problem remains ...

    Best regards

    Alex

  • 0 in reply to Alexander Kästner
    TI__Guru** 117441 points

    Ok thanks. Me and Anthony (FAE) had offline discussion on this and he'll reach out to you on the next action.

  • 0 in reply to Vivek Singh
    Prodigy 20 points

    Hello Vivek,
    here are the additionally requested informations.
    CCS version: 10.0.0.00010
    F2837xS Support Library v3.10.00.00
    Compiler version: v20.2.1.LTS

  • 0
    TI__Guru 62975 points
    Alexander Kästner said:
    Debugging shows that the stack pointer points to an area outside the reserved area.

    How far off is the Stack Pointer? Is it just beyond the allocated space or in an entirely different memory space altogether? I would want to make sure that the allocated memory space falls within the 16-bit address range.

    Do the contents at the Stack Pointer make sense as context save values? I would expect the CPU to attempt the context save even if the pointer is out of range:

    Alexander Kästner said:
    A jump to the "illegalOperationHandler" occurs only when the 12 kHz time slice is blocked.

    Can you check the contents of the PIECTRL[PIEVECT] field to confirm that it was really an ILLEGAL interrupt that triggered?  PIECTRL would most likely be 0x0D27 for ILLEGAL.

    Alexander Kästner said:
    The individual time slices are blocked during the test using "while (1);".

    Am I correct in understanding that the CPU is in the while(1) trap until the watchdog expires? Can you use the memory browser to observe the memory region of the while(1) trap and watchdog ISR to make sure that the contents are not masked to 0x0000 by the DCSM or Memory Controller? A 0x0000 instruction will trigger the ILLEGAL instruction trap.

  • 0 in reply to tlee
    Prodigy 20 points

    How far off is the Stack Pointer? Is it just beyond the allocated space or in an entirely different memory space altogether?

    The stack pointer points to 0xD621and for the stack is the following area reserved 0xC000 ... 0xCFFF.

    Can you check the contents of the PIECTRL[PIEVECT] field to confirm that it was really an ILLEGAL interrupt that triggered?  PIECTRL would most likely be 0x0D27 for ILLEGAL.

    The PIECTRL register contains 0xD27.

    Am I correct in understanding that the CPU is in the while(1) trap until the watchdog expires?

    Correct, in the test cases we are going in a while(1) loop and wait that the watchdog occurred.

    Can you use the memory browser to observe the memory region of the while(1) trap and watchdog ISR to make sure that the contents are not masked to 0x0000 by the DCSM or Memory Controller?

  • 0 in reply to Alexander Kästner
    TI__Guru 62975 points
    Alexander Kästner said:
    The stack pointer points to 0xD621and for the stack is the following area reserved 0xC000 ... 0xCFFF.

    That seems pretty far off. Can you try to run the program just to the while(1) trap and then confirm that the SP value makes sense before free-running in the loop? I would also recommend configuring a Hardware Watchpoint where the watch location is set to a few words past the SP value. This way, you will be able to detect if there is some unintended activity that is triggering context saves.

    tlee said:
    Do the contents at the Stack Pointer make sense as context save values? I would expect the CPU to attempt the context save even if the pointer is out of range

    Does the RPC value make sense while in the ILLEGAL ISR?

  • 0
    Prodigy 20 points

    Hi all,

    The tip from your side gave me a nudge in the right direction.

    "From what I can tell without trying to fully understand the software architecture, it looks like the TIMER1 ISR allows INT13 (TIMER1 itself) to be a nested interrupt source for preemptive ISR execution.

     So once the CPU traps in the TIMER1 ISR while(1) loop, a series of additional nested TIMER1 ISRs are spawned as TIMER1 continues to run in the background, which causes the stack to overflow, which causes the CPU to fetch an illegal instruction before the WatchDog can overflow."

    During the implementation I used the example for the nested interrupts as a guide and this example activates the currently active interrupt and all others with an higher priority. Now I have change my software in this way, that i allow only interrupt with an higher priority, so that the TIMER1-ISR cannot be triggered again.

    Regards Alex