Breakpoints Using CyclonePro & S08QG8

[Wings]

I posted this on P&E forums but I don't think anyone is home over there, so hopefully someone here can give me some help.

I'm using CodeWarrior Development Studio vers 5.7.0, debugger is BDM P&E Multilink/Cyclone Pro, vers 6.1. Here is my question, copied from my post at P&E:
---------------------------------------

I'm taking my first test drive with a CyclonePro connected via USB to my QG8 hardware via the BDM port. I've got the default ASM file loaded and I've inserted a string of NOPs and an instruction to increment a memory location (just to see if it's really doing something). Sure enough, if I single-step or halt it, it really is working!

So now I try setting a breakpoint.... or two or three. Sometimes that works, sometimes not. One breakpoint always seems to work but when I start adding more things start getting weird. Weird, as in not stopping at a breakpoint even though that little red pointy arrow says there's one there. Weird as in saying "Could not set the hardware breakpoint at address $E00F", immediately followed by "Was not able to set the breakpoint at $E00F". (I think it knows I learn best by repetitive & redundant error messages.) Weird as in stopping at a breakpoint that I have previously inserted and then removed.

So before I go spinning my wheels trying to figure out exactly what I'm doing wrong I would like to ask for some advice here.

What is the thing I need to do to make sure that breakpoints I've set really are there? (This question is most important of all, since if I can't trust it to stop at my breakpoint then I'll never be able to debug my code with any confidence at all.)

What am I doing that causes it to complain that it cannot set a breakpoint?

How can I make it forget about a breakpoint that I once had but have since removed?

I'd really appreciate some feedback from P&E or anyone who has experience in using the CyclonePro with the BGM.

[Wings]

I've narrowed down one breakpoint quirk to a specific set of conditions that are repeatable.

The code

LOOP: CLRA
INCA
INCA
INC $80
BRA LOOP

If I place a breakpoint at the 2nd INCA, all is well -- it stops there on every loop (and AccA = 1). If I place 2 breakpoints, one there and the 2nd at INC $80, it does this:

1 It stops at the 1st breakpoint (2nd INCA), and the command window shows "Preset breakpoint encountered" then "Breakpoint". AccA = 1. What I expected.

2 Hitting Resume and the command window says "STARTED" but nothing seems to happen. (AccA is still a 1.)

3 Hitting Resume again and it stops at the first breakpoint as before.

4 Resume and it does nothing.

5 Resume and it stops at the 1st breakpoint.

6 Resume and an alert dialog says "Could not set hardware breakpoint at $E008", then "Was not able to set the breakpoint at $E008".

7 Remove both breakpoints and it's as though they are still there. The breakpoint indicators go away but it repeats forever from steps 2 and 3 above whenever I hit Resume (no more alert dialog).


A N Y B O D Y?????

[rhinoceroshead]

There is only one hardware breakpoint built into the device, so what you're describing mostly makes sense.  Does it work fine if you only set one breakpoint at a time and remove that one before applying another one?

The BDM module on the chip lets you program one address into the breakpoint match register - and when the program counter holds the same address, the BDM stops the CPU.

[Wings]

Hi Rhino, and thanks for responding.

I thought it had 2. One instruction breakpoint and one stop-on-address breakpoint.

In any case, I've even put 3 breakpoints in and it stops at the 1st and the 3rd.

I put in 4, and when it runs it says it can't install the 4th one. So I remove it. And now it stops on the 1st, 2nd AND 3rd.

To answer your question, yes, if I only put in 1 breakpoint it seems to work OK as far as breakpoints go. I would think it would warn me if I try to put in a 2nd or 3rd breakpoint and that wasn't supported.

I know once I get into a serious debugging battle that I'm not always going to remember if I have a breakpoint installed somewhere or not.

[bigmac]

Hello Wings,

It is conceivable that the Cyclone Pro hardware may be operating correctly - thus the disinterest by P & E.

If multiple breakpoints are allowed, these would need to be supervised by the debugger, and the hardware breakpoint automatically updated, depending on the current PC.  So this could potentially be a problem with CW debugger.

A suggestion - try leaving at least one instruction between consecutive breakpoints - this would usually be the case in a normal debugging session.

Regards,
Mac

[rhinoceroshead]

At first I thought CW should automatically update it too - but in the event that there is a branch and you want a breakpoint in each branch, it would be impossible for CW to know which breakpoint to set.

[Wings]

I've read in app note AN2596 that the debug controller in every S chip has one breakpoint that can trigger on either an instruction fetch (normal breakpoint) or an address access (stop-on-address). In the Debug Module, which is present in most S chips but not all, there are two more breakpoints just like the first one, so that does make a total of 3. Now whether or not CW's debugger allows one to use all 3 is another question.