• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 32 subscribers
  • Views 497 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.

resetEntry

David Sabol
Genius 4850 points

Other Parts Discussed in Thread: TMDSEMUPROTRACE

Hi,

I am using the Hercules Development kit for the TMS570 MCU with CCS 5.4.

 

I have my project setup using ucos ii and can successfully build, download, step through, etc.  However, I am getting a resetEntry interrupt.  I'm having a hard time tracing the source.  How can I track it down? Is there a way I can find the function that was running when the interrupt was triggered?

 

Thanks,

David

  • 0
    TI__Mastermind 22715 points

    David,

    (1) Set up a breakpoint in the resetEntry ISR.

    (2) With CPU locked in the ISR, check the value of hte link register (LR) which holds the address when reset occurs.

    (3) Check your map file to see what function is located in that address. You can also use CCS disassembly window.

    Thanks and regards,

    Zhaohong

  • 0 in reply to Zhaohong Zhang
    TI__Guru 69070 points

    David,

    Another option is TMDSEMUPROTRACE which plugs into the 60 pin MIPI connector on your HDK.  It's $3495 roughly in the TI eStore.  

    What I've found limiting in the above method is that you only get a history of -1 state prior to the reset vector entry.

    You may just find out something like 'I branched to the reset vector from some address in RAM' and then be stuck trying to figure out how you got to that address in RAM.   You can keep setting breakpoints / watchpoints backward, but this can be problematic if your path goes through some normal path -- you might hit the breakpoint 1000's of times in the 'normal' condition and only rarely when you'd have the problem condition that takes you to the entry point.    The ETM trace tool is quite nice because you can get a detailed history of exactly how you got to the reset vector.  And since you can see not only PC trace but data trace, if there is something like a stack overflow you'll be able to turn on the data trace and see accesses to the stack to confirm the problem.

    Short of this type of tool you can do things like make sure you have the MPU turned on, and if you have an OS like FreeRTOS you might look at what capabilities it has for stack overflow checking.  Usually it's some problem like that which will cause you to go back to the reset vector...