BDM and BERR\

[Chris Johns]

"Aaron J. Grier" wrote:
> 
> 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.
> 
> Without the bus monitor enabled, I get garbage back for memory reads.
> (0x40159580, to be specific.)  With the bus monitor enabled, memory
> reads appear as they're working, but my initial problem of not being
> able to set SIM registers still stands:
> 
> (gdb) set *(short *)0xfffa00 = 0x62ff
> BDM error: Target Bus Error
> 
> however, now I can continue to read memory.  (Previously, any subsequent
> memory read would give me a bus error.)
> 
> 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 not completely sure about this and could be wrong. If the bus
monitor is disabled or freezes (if it can) on a break an accesses to an
invalid address might not terminate.

> 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?
> 

Could be. The 5307 Coldfire needs a delay inorder for the processor
clocks to get started.

Could you please try this function to initialise the hardware :

static int
cpu32_init_hardware (struct BDM *self)
{
  int status;

  /*
   * Force breakpoint
   */
  outb (CPU32_CR_NOT_SINGLESTEP | CPU32_CR_CLOCKBAR_BKPT,
self->controlPort);
  udelay (100);
  outb (CPU32_CR_FORCE_RESET | CPU32_CR_CLOCKBAR_BKPT,
self->controlPort);
  bdm_sleep (HZ / 100);
  outb (CPU32_CR_CLOCKBAR_BKPT, self->controlPort);
  udelay (10);
  outb (CPU32_CR_NOT_SINGLESTEP | CPU32_CR_CLOCKBAR_BKPT,
self->controlPort);
  udelay (100);
  status = cpu32_get_status (self);
  if (self->debugFlag)
    PRINTF ("cpu32_init_hardware: status:0x%x control port:0x%x\n",
            status,
            inb (self->controlPort));
  return status;
}

-- 
 Chris Johns, mailto:ccj@acm.org

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