workflow: BDM debugging with interrupts?

[irob]

Hey everyone.  I've got a high-level sort of workflow question.  I'm using CodeWarrior 6, on mostly HCS08QG8, and JS16 targets, i.e. I stay in the BDM world for ease of debug.

Until recently, I've tried to use pseudo-RTOS type program flow, e.g., efficient time slicing and complex state machines to poll through my code.

However, now I'm requiring a lot more interrupt-driven inputs.  Hod do you all use the BDM debugger with your interrupts?  For instance, I have an input capture coming from a periodic input.  So that interrupt is happening all the time.  Another example is the USB interrupts, which are also happening regularly.

Stepping through code seems futile to me, as you get hung up in the ISR all the time.  Just wondering what your workflow is.  Thanks!

[rocco · Accepted solution]

Hi Rob,

My systems are also highly interrupt driven, and it does cause debugging problems.

My first, and most desirable solution is to write code without bugs. Ok, I haven't perfected that tecnique yet.

One thing that helps a lot is that there is a option in the debugger to automatically set the interrupt mask upon encountering a breakpoint. It at least allows you to then single-step without vectoring to an ISR, but your interrupts still trip over each other.

Helps a little.

Mark

[irob]

Strange.  With a simple MTIM interrupt example software, I can't step through the code even with the "Disable interrupts while stepping" checkbox turned on in the True-Time Simulator.  The checkbox doesn't seem to affect anything, as the debugger gets hung up in the MTIM ISR.

This makes me think that there is some special something I'm missing in my source, maybe?

[irob]

Figured out my problem.  In order for stepping to work uninterrupted, you must start stepping (or Run To Cursor) immediately after reset.  If you hit the green Start/Continue (F5) button, and then stop, you'll get stuck in the ISR.

[irob]

Thanks, Mark.  I'll give that a try next time.