Re: BDM and BERR\

[Gunter Magin <magin at skil dot camelot dot de>]

> I finally got a 5-chip interface together from the Canadian schematics,
> but it's still not working quite as expected.  The schematics label the
> one-shot driving the BERR line as supposedly putting out a 10µs pulse,
> but using a 2.2nf cap and 4.7k resistor only gives a 4µs pulse.

I don't know where this 10usec label comes from. It cannot be found on the
original 5chip schematic published by Motorola Munich. Probably
Acceleration Labs at Univ. of Sasketchuan (where I believe you found the 
"Canadian schematics") introduced it when modifying the one-shot circuitry
for BERR generation. Both time values are reasonable.

> The question I have is how exactly does BERR\ on the BDM connector tie
> in to sending / receiving BDM commands?  What's the theory behind the
> one-shot that drives BERR\?

I am talking about a CPU32 target:

A !DS being active low for more than a certain time indicates a hanging 
bus cycle, because nobody terminates it by asserting DSACK. Normally, the 
memory controller handles DSACK, taking the configured waitstates into
account.

In general, the bus monitor is responsible for bus cycle supervision, and 
pulls !BERR after a programmable timeout. If for some reason the bus
monitor is temporarily (FRZBM in SIMCR set) or permanently (BME in SYPCR
cleared) disabled, this emergency net is not working. This is especially
bad for cycles started by the BDM module, because the debugging host has no
way to bring the target back to life on the BDM line except by a reset, 
which destroys the current context. To remedy this, BERR circuitry has been 
added to the interface.

There is another option for BERR pulling: the BDM driver can also pull BERR
after a SW determined timeout.

> I'm also clocking my 68331 with a 32kHz crystal, and planning on using
> the '331 synthesizer to run at 25Mhz.  Of course when starting a BDM
> session, the clock hasn't been ramped up yet.  Could this be a problem?

Once the PLL has locked at the default frequency (8.39 MHz for a 32.768kHz
crystal), the CPU32 asserts !RESET itself for another 512 cycles. Freeze 
(and hence BDM) is only enabled after that. See Fig. 4-16 in the 
MC68331UM/AD. 

gm
-- 
Gunter Magin                                      magin[AT]skil.camelot.de

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com