5

I've been using IAR embedded workbench for quite some time but there is still one thing I'm unable to wrap my head around. And that's the inconsistency of the breakpoint operation.

I have a quite big project which runs an RTOS (might this affect the problem?) and when I place a breakpoint there is no guarantee the debugger will stop at this breakpoint. Sometimes it does, sometimes it doesn't. A workaround I found is manually stopping the processor and placing the breakpoint while the processor is paused. But even this has not a 100% success rate.

I'm generating debug information and I'm running in debug mode

Anyone had similar issues or anyone with some ideas?

Zjerre
  • 105
  • 1
  • 7
  • 1
    I've worked with IAR quite a lot (ThreadX instead of RTOS, and mostly on STM32 but also on MSP430). I have never encountered the problem that you are describing, except for cases where my code was partially or fully optimized (in which case, proper debug information doesn't necessarily exist). But even in those cases, either it would stop at the break-point, or it wouldn't (and not "sometimes yes sometimes no" as implied by your description). Sounds to me like it doesn't always stop at the break-point simply because your program doesn't always reach that point in the execution path. – barak manos Sep 03 '14 at 07:32
  • I'm not using anykind of optimization and I'm really sure the debugger reaches the code. I have a continously running timer in the RTOS where I place breakpoints. – Zjerre Sep 03 '14 at 07:36
  • 1
    Declare some global data-structure (a simple variable, an array + index, or even something more complicated). Update it at the place where you're trying to stop with a break-point (instead of using that break-point). Then, choose "the right moment" in the execution of your program, and view the contents of that global data-structure. You should save information that will give you a clear view of how many times you reached that point in the execution of your program, and what were the values of specific variables that are relevant to the scenario that you're investigating. – barak manos Sep 03 '14 at 07:56
  • 1
    BTW, the description above is often a useful method for debugging your program when: 1. Timing is critical and you cannot interrupt the execution of your program without affecting its behavior. 2. The code is optimized and debug-info is not available. 3. The number of viable breakpoints is limited due to HW restrictions, and you've run out of free breakpoints. – barak manos Sep 03 '14 at 07:58
  • I agree with the usefulness of your described method (and this is another reason why I know the debugger is reaching the code) but it still doesn't explain the behavior I'm seeing. – Zjerre Sep 03 '14 at 08:10

1 Answers1

1

Try to reduce number of breakpoints that you use (possibly just keep this one that causes problem), also you could use a “Log” breakpoint in order to print a message in the Debug Log window instead of stopping at that point (you may also want to try a different point in the same section of the code). If they don't help, I could say with a high degree of certainty that the debugger does not stop at the breakpoint because it simply does not hit it, and you do not enter that block of code. Consider that in an embedded project (especially when using an RTOS) some conditions are met only at the beginning or upon certain requests in certain conditions so you might want to figure out when the breakpoint is actually hit what conditions were met and what is the new state now.

Kepler
  • 31
  • 4