ICD_BDM and problems with stepping through some instructions

[profesor at sidehack.sat.gweep.net]

Is the instruction accessing an illegal address?  If so, I may have
an answer.  Even if it's not the instruction accessing an illegal
address, GDB could be accessing an illegal address, which could
cause the same thing...

If the bus monitor is disabled, then the chip will hang forever waiting
for the bus cycle to complete.  There's two bits in two different
registers - one is in the SYPCR that controls whether BM is on
when freeze is asserted (you want it to be on - which means set it to
a 0).  In addition, there is a BME bit in a different register (I
forget which one) that controls if the bus monitor is enabled for
internal-to-external transactions - set this bit to a 1 to enable
it.

Before I had these bits set this way, if I accidentally accessed
a bogus address through GDB (or usually if GDB got confused about
the arguments to a function & accessed a bogus address), the
BDM would hang.  Now it just returns a bus error from the BDM
and continues on it's way.

	-Matt

[ Charset ISO-8859-1 unsupported, converting... ]
> Hello,
> 
> I am using a Motorola 68332ACFC16 with GDB 4.18, BDM patches for Linux,
> ICD_BDM driver, and PE Micro debugger.  I have a problem stepping through
> some instructions (MOVEL is one) that I wonder if anyone else has
> encountered.  The error is bdm_signal_handler: failed to stop chip no
> response from target via bdm.  The work-around is to set a breakpoint after
> the offending instruction and "continue" to it.
> 
> >From reading past user group messages and Pavel Pisa's 6/30/99 document, I
> think this might have something to do with internal GDB timing.  
> 
> Has anyone else seen this problem?  Found a solution?  Have hints on where
> to look?
> 
> Bill