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.

Debugger not stopping on breakpoint

I have a project which I believe has some bad code in it, and I am trying to debug the problem. I am using a custom board, an XDS200 emulator, and Code Composer Studio 5.5. My custom board is populated with a TM4C129 processor.

My problem is that my program runs for ~5 minutes, and then skips several state machine states and ends up back in the IDLE (default) state. Initially, I saw the program call exit(), but that only occurred once and I haven't been able to reproduce it. Instead, now, I'm seeing the code leave the state it's normally in and go back to IDLE. Conditions aren't appropriate for it to exit IDLE, so it gets stuck there.

In order to see why this was happening, I put a breakpoint on the IDLE state's steady-state function, so I would be able to see when the device re-entered IDLE. To my surprise, even when I could tell from external equipment that the device went back into IDLE, the breakpoint was not referenced and did not halt the system. 

I paused execution and did 'step-over' until I was in the state engine, and it's walking directly over my breakpoint, but not halting on it. If I run the system, it continues execution uninterrupted. If I pause the system, remove the breakpoint, re-add the breakpoint, and hit resume, it stops on the breakpoint immediately. This is a hardware breakpoint.

So, it seems my breakpoint is somehow being disregarded during execution - but it still shows as active. If I re-create it during the same debug session, debugging the same program, in the same place, it halts the system as intended. What's going on here?

  • Brief update here: I tried putting some breakpoints in other places that would only get invoked in the IDLE state, and none of them function either. Is it possible that some bug in my code would actually disable breakpoint halts in the processor? That seems very unlikely, but I don't have any explanation for how my code can be definitely entering areas with breakpoints without stopping on them.

  • Benjamin Fitzpatrick said:
    I paused execution and did 'step-over' until I was in the state engine, and it's walking directly over my breakpoint, but not halting on it. If I run the system, it continues execution uninterrupted. If I pause the system, remove the breakpoint, re-add the breakpoint, and hit resume, it stops on the breakpoint immediately.

    This is definitely odd behavior. Are you saying that when you first set the breakpoint and run, it is not hit. But if you halt execution, remove the breakpoint and re-add at it at the same place, then it does hit it when you continue running? Did you confirm that it shows up as a hardware breakpoint and is enabled when viewed in the Breakpoints view?

    You might also want to try posting this question to the Tiva device forum in case the experts there have further advise with regards to the device/hardware that might be affecting this behavior.

  • Hi Aarti,

    Yes, I think you've described my situation perfectly. I think I've also figured out what's causing it, at least in part. It looks like the problem in my code is causing the Watchdog I have implemented to not be 'pet', and so my system is resetting after the watchdog timeout. Apparently after a Watchdog-driven reset, I don't lose my debug session, but none of my breakpoints work.

    I confirmed that it is a hardware breakpoint, it is enabled, and it shows up in the Breakpoints view.

    Is there a CCS setting that I need to change to make breakpoints persist through a processor reset? Is that even possible?

    Let me know if this is out of the CCS forum scope and I'll re-post this question over on the Tiva forums.

    Thanks,

    Ben

  • Benjamin Fitzpatrick said:
    Apparently after a Watchdog-driven reset, I don't lose my debug session, but none of my breakpoints work.

    Are you able to send us a small test project that reproduces this behavior? We have tried reproducing it by manually performing a core reset or system reset but neither causes the breakpoints to be disabled. In order to perform further analysis it would be very helpful if we could get a reproducible test case.