How can I tell the ARM7TDMI core stop because of DBGRQ or breakpoint/watchpoint

[hb guan]

When the ARM7TDMI core is running, I can stop it by writing
embeddedICE deubg control register bits DBGRQ. But if we also have
some breakpoint/watchpoint config in embeddedICE, how can I tell the
ARM7TDMI core stop because of DBGRQ or breakpoint/watchpoint? They
have different return address caculate formula:
breakpoint/watchpoint: 4 +N +3S
Debug request: 3 +N +3S
(N: instruction running in debug speed, S: instruction running in
system speed.)

Any information is welcome!

Thanks!

hb guan
2003-09-05

[Dave Adshead]

You can't tell. On later cores you *can* tell. For ARM7 cores, you
need to do some software trickery. This is the procedure:

1. Do a last minute check that the core is running. If not then it must
have hit a breakpoint already, so deal with that in the normal way.
2. Assert DBGRQ and wait for DBGACK.
3. Check to see if the address that it stopped at is consistent with an
address that you know has an existing breakpoint. If so, assume that
it is a breakpoint and do the address calculation for a breakpoint.
If not, assume that it stopped because of the DBGRQ and do that
address calculation instead.

Optimise your code or hardware to minimise the time difference between
steps 1 and 2.

This mechanism is used by Multi-ICE (and presumably by all other ICEs
that have bothered to think about the problem) and very rarely fails
even under contrived test conditions. Unfortunately you cannot do
better because it is a debug architecture limitation. Later cores
contain 'reason for stop' bits.

If you need more help you may be interested in my services. I worked
for ARM for 6 years, designed and wrote much of the code for Multi-ICE
and am now a consultant offering these types of services - see
www.debuginnovations.com for more info.

Regards,

Dave.