• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 828 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.

CCS/TMS320F28379D: What are typical debugging tips for tracking down unplugged interrupts?

Mike Verdicchio
Prodigy 80 points
Part Number: TMS320F28379D
Other Parts Discussed in Thread: SYSBIOS

Tool/software: Code Composer Studio

Hi all,

I have a program that loads with the debugger attached just fine. However, part of my testing involved resetting the CPU(s) during runtime, and when that occurs, I get an unplugged interrupt #32.

What I (think I) know:

  • Unplugged interrupts occur when an interrupt occurs but doesn't have a function attached to it. In my case, it's probably a bad branch or memory being written over somewhere (I've had this problem before).
  • Intr #32 is the ACA1_ISR, which for me is just the default from Default_ISR.c since I'm not using it
  • The memory address for intr #32 is 0x88B3B
  • This only occurs when I reset the device after it initially begins (as described above).

What are some debugging methods that you use to track down this kind of problem? Are there any good registers to check out or convenient places to put breakpoints? I'm still kind of new to this processor, so I'm trying to debug it myself but I feel like I'm just not looking in the correct spots.

Thanks so much!

Mike

  • 0
    TI__Guru** 115881 points
    Mike,

    How are you resetting the CPU and then restarting? What is the bootmode used to restart the CPU?

    Regards,

    Vivek Singh
  • 0 in reply to Vivek Singh
    Prodigy 80 points

    Hi Vivek,

    Thanks for your response! When I first connect the debugger, I have to do a CPU Reset (Ctrl-Shift-R) on CPU2, then Restart (menu bar) both cores, and then run them both. To simulate a reset later in my testing, I use a similar flow, but instead I CPU Reset both cores, then do the above.

    Looking through the Reference Manual at the BOOTMODE section, I realize something is probably incorrect - I never dabbled with boot modes so this is new to me. My final product will be using the GET mode from Flash (S1 = 110) without a debugger attached of course, but it looks like since the debugger is correctly attached for testing, the TRSTn is high and it might not be booting the way I want it.

    EMUBOOTCTRL (0xD00) reads 0x0008B1D9 while the program is running, and Z1-BOOTCTRL reads 0xFFFFFFFF.

    Is there anything you recommend for getting this figured out? I'm sorry - I read through the BOOTMODE section but I'm still a little lost on how it all comes together. Thanks!

  • 0 in reply to Mike Verdicchio
    Prodigy 80 points

    I learned a little more about BOOTMODE and checked it, and that seems to be the way that we want it.

    I put a breakpoint at _ti_sysbios_family_c28_Hwi_dispatchPie and checked the RPC register a few times to see what's calling the unplugged interrupt. Every time, the RPC points to either *_Idle_loop__E or *_TaskSupport_glue. I've tried moving these functions to RAM and that doesn't fix it. Any tips?

  • 0 in reply to Mike Verdicchio
    Prodigy 80 points

    I ended up getting it to work. I realized that only one of my debug configurations (I have 4) was acting up, so I looked at what was different in that one between the rest. There was a checkbox under Auto-Run settings to automatically go to main() on a CPU reset. I unchecked that one and everything seemed to work great.

    I was using TI-RTOS and one of my functions issues a few memcpy's to copy flash programs to RAM, and I'm guessing those functions either weren't being copied correctly or were being overwritten when I'd go straight to main() on a reset.

    Regardless, it works! Hopefully this information helps someone else in the future.