• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 83 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.

TMDS64EVM: Decoding R5F IRQ Exception

Seth Appleman
Prodigy 230 points

Part Number: TMDS64EVM
Other Parts Discussed in Thread: SYSCONFIG

I am running an application on the TMD64EVM, R5F_0_0 core. This application is built on one of the "empty" projects provided in the TI SDK (version mcu_plus_sdk_am64x_11_02_00_24).

At some point while running, I hit an exception, but silently, such that when I pause the debugger I am already in the HwiP_irq_handler_c routine.

HwiP_getIRQ (called in this handler) returns the following values:

intNum=160, priority=15

First, where can I find documentation as to what "intNum=160" maps to. I found some comments in the SDK header filer that suggests "INTR_TIMER8" but I am not using and timers in my code.

Second, how can I use the Interrupt handler routine to understand what address this interrupt is occuring at to try and backtrace the cause?

What other debug information do you suggest so I can try and flush out the bug?

Important note: this is code that was running 100% cleanly yesterday. This exception only started popping up today. I have a second TMD64EVM I switched to and the problem has followed it. So likely my testing is just uncovering a bug that has been laying dorment for weeks.

  • 0
    TI__Guru 64958 points

    Hi,

    Is this a freertos example or nortos example? The interrupt number 160 belong to the timer8 instance. This details can be found in the device TRM.

    Also please check your Sysconfig file, timer8 might be configured in clock section. Please refer below image.

    Seth Appleman said:
    Second, how can I use the Interrupt handler routine to understand what address this interrupt is occuring at to try and backtrace the cause?

    Is it not coming out of the ISR routine? 

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Prodigy 230 points

    After some late night troubleshooting, I discoverd that I had some debug/capture code that was writing beyond array boundries and overwriting the ISR handler addresses. So my timers weren't the problem, it was that they eventually stopped invoking my callback routines after my debug code wrote over the configured pointers.

    You can close this issue.

  • 0 in reply to Seth Appleman
    TI__Guru 64958 points

    Hi Seth,

    Thank you for the confirmation and above explanation. Closing the thread.

    Regards,

    Tushar