TMS320F28379D: Debugging ITRAP Interrupt_illegalOperatorHandler()

Nigel Paine

Part Number: TMS320F28379D

I'm currently trying to debug why an ITRAP is occurring on the F28379D chip we are using. Here are some things to consider:

I press the Debug "bug" button to flash both CPU1 and CPU2 consecutively as that is how I've setup my debug configuration
Once the code is loaded onto both cores I press the resume button on CPU1, then on CPU2, and immediately after resuming CPU2 the ITRAP is triggered on CPU1
The Debug window shows that Interrupt_illegalOperationHandler() is the specific ITRAP being called
The interesting thing is that the ITRAP only occurs once. What I mean is if I press the CPU reset/restart button for each processor and then resume CPU1 and CPU2 again, the ITRAP does not occur. However, if I stop the debugging entirely by pressing the stop button and re-debug both cores it will occur again.
The ITRAP was introduced in a recent commit, however, nothing I've seen in that commit suggests why the ITRAP occurs
I fill the stack with values upon startup so I can observe the stack memory when the ITRAP occurs, however, nothing indicates that the stack is overflowing
I also tried increasing stack size from 2048 to 4096 on CPU1, but this didn't resolve issue
I have a suspicion it may have to do with memory, the memory differences between the previously working commit (no ITRAP) and the faulty commit (ITRAP) is the following:
- RAMLS0_1 increased from 2653 to 2680 (TI ramfunc)
- FLASHB increased from 8186 to 8192 (max size)
- FLASHD increased from 8189 to 8192 (max size)
- FLASHE increased from 10511 to 11637
- RAMGS0 increased from 2903 to 3683
As recommended in another forum post I tried to add a return; statement right after the ESTOP0; in the Interrupt_illegalOperationHandler() function, but for some reason the debugger skips the return and continues looping forever in the for(;;){;}
- Perhaps I was editing the wrong driverlib file, I modified interrupt.h in C:/ti/c2000/C200Ware_3_04_00_00/driverlib/f2837xd/driverlib

Please advise on how I may debug this ITRAP condition further. Thank you!

over 4 years ago

0 KARTHIKEYAN RAJAMANICKAM over 4 years ago

TI__Genius 11645 points

Hi,

Please refer to "How can I debug an ITRAP?" section from the below link

https://software-dl.ti.com/C2000/docs/c28x_interrupt_faq/html/index.html

You can try removing the forever loop and replace with a return, but place a breakpoint there to debug further as mentioned in the FAQ.

0 Nigel Paine over 4 years ago in reply to KARTHIKEYAN RAJAMANICKAM

Intellectual 290 points

I have already referenced this document and it is quite vague as to how to actually debug as it is saying. "Insert a breakpoint into the ISR"...which ISR...where? Or with "looking at the return address value on the stack"...again, where and how do I do view this value? I've already tried to replace the infinite for loop and set a breakpoint, but the debugger steps over the return as if it isn't there, which tells me there must be some other file I must edit. Please re-read my post and advise.

0 Ashwini Athalye over 4 years ago in reply to Nigel Paine

TI__Expert 7695 points

Hi Nigel,

Since you have already verified that the stack is not the issue, it may be some other event. Please look at the following document section 3.6 "Illegal Instruction Trap" section. This has information on how to get the offending address by looking at the contents pushed on the stack when the core is in the trap ISR. This may help shed some light on what may be causing the trap.

https://www.ti.com/lit/ug/spru430f/spru430f.pdf

Thanks,

Ashwini

0 Nigel Paine over 4 years ago in reply to Ashwini Athalye

Intellectual 290 points

The interrupt FAQ link pasted earlier should include further information on this document. I'm not familiar with the stack/interrupt specifics so section 3.6 is a bit convoluted. Here's a screenshot of the stack memory at the moment the program hits the ESTOP0 in Interrupt_illegalOperationHandler(). Highlighted is where the current stack pointer is (0xB865) Please let me know how I may further debug:

0 Ashwini Athalye over 4 years ago in reply to Nigel Paine

TI__Expert 7695 points

Hi Nigel,

It will be hard to answer this question just by looking at the memory as the ISR itself will have some prologue code generated by the compiler that will be pushing content to the stack other than what is automatically done by the hardware as indicated in Table 3-5 of above CPU and Instruction Set Guide. Without that ISR code information it will not be possible to backtrack in the stack and finding the offending address.

The following post has more details to understand this and help you backtrack the stack and get the address.

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/979782/tms320f280049c-illegal-instruction-behavior---how-to-retrieve-the-offending-address/3620048#3620048

Thanks,

Ashwini

0 Nigel Paine over 4 years ago in reply to Ashwini Athalye

Intellectual 290 points

Ok...I decided it was easier to just step through every interrupt on our system, starting with the most complex, to see if it triggered the ITRAP. Luckily the illegal instruction was triggered on the first interrupt I checked so that saved me a lot of debugging time. Unfortunately seems like a memory overrun...for some reason a function callback within a struct gets overwritten with the wrong address. Needless to say, I've narrowed it enough to not require further assistance.

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28379D: Debugging ITRAP Interrupt_illegalOperatorHandler()