Debugging COP resets...

[billw]

I was having a tough time debugging some COP reset issues using the
black widow virtual lab, and I think I finally figured out that this
was because a COP reset resets the Background Debug System as well as
the rest of the CPU. Since things like breakpoints are done via
registers in the BDC, they all disappear when a COP (or other) reset
occurs. So all the careful breakpoints I put in early init code trying
to catch a reset occuring got essentially deleted by the reset. Sigh.

So how do you debug COP reset issues? Can the BDC be configured to
trap resets automatically (I skimmed that section of the manual and
didn't see anything)? Can I force the debugger to insert "hard" code
style breakpoints (that survive a cpu reset) instead of using the BDC
hardware breakpoints or trap resets that happpen during debugging?
(some of my pain was from expecting patched-code style breakpoints,
which I'm used to on large CPUs...) The DBG module has the same
problems as the BDC, doesn't it?

Thanks
BillW

[Alban]

Hello Bill,

There is nothing stopping a Reset.

But I believed the debug buffers were not flushed.

Therefore you can see what happened before your reset with the trace buffers.

Am I wrong ?

Cheers,

Alban.

[billw]

Hmm. WHAT trace buffers? I guess a full-scale ICE might
have a significant trace history, but I'm using the internal BDC;

In any case, the problem is detecting that a reset has occured.
It seems that usinga debugger based on BDC/DBG, an internally generated
reset like COP reset will reset the internal registers that would normally
let the debugger software know that anything had happened. So I can be
sitting in the debugger happily thinking I have three hardware breakpoints
set (one in BDC, two in DBG?), while a COP reset might have caused them
to be removed entirely...

(Of course, you an just disable COP reset when debugging, or you can
manually put BKGD (breakpoint) instructions in your init code, but I
was hoping for something more elegant?)

[billw]

Hmm. So I inserted a BGND instruction into the BW contest program
near main() so make sure the debugger notices resets. When
the program first runs, it hits the BGND and the debugger reports
an "illegal breakpoint", which is about what I'd expect to happen
when the BDC gets invoked at a spot it doesn't think it set a breakpoint
at. So I continue from there ("go"), and arrange for there to be a
COP timeout reset. At this point the debugger reports something
strange along the lines of hitting a multiple condition trace event
(BEFORE it gets to the BGND instruction.) In theory, this is great!
The debugger has somehow trapped the reset? But apparently not, since
the next thing that happens is that it reports that it has lost contact
with the target and needs to reconnect! What's going on?