Newsgroups: comp.robotics
Path: brunix!uunet!enterpoop.mit.edu!news.media.mit.edu!fredm
From: fredm@media.mit.edu (Fred G Martin)
Subject: Re: A1 glitching on 6.270 boards
Message-ID: <1993Jan18.215956.6919@news.media.mit.edu>
Sender: news@news.media.mit.edu (USENET News System)
Organization: MIT Media Laboratory
References: <1993Jan18.032624.28824@athena.mit.edu>
Date: Mon, 18 Jan 1993 21:59:56 GMT
Lines: 59

In article <1993Jan18.032624.28824@athena.mit.edu>
spedhead@athena.mit.edu (Pankaj Oberoi) writes: 

>I talked with a Motorola engineer about this problem. of the glitchiness.
>He thought that because the EEPROM memory space of the A1 coincided with
>the RAM on the 6.270 board that when the chip was being reset into the 
>wrong state, it would access the EEPROM and wipe out some of the RAM.
>The problem never existed on the A0 because the EEPROM is unaccessible
>on that version, and if the processor was to be reset into the strange 
>mode, then it would access the RAM anyway.

This isn't true.  The 'A0 does have EEPROM, it's just not up to spec,
so Motorola distributes the chip with the CONFIG register programmed
so that the EEPROM is disabled.  Kind of like Intel's selling you a
'486SX chip, which is really a '486DX with a FPU that didn't check out
and was intentionally disabled.

The difference with the 6811 case is that the configuration is
reprogrammable.  You can reprogram the 'A0's CONFIG to enable the
EEPROM, and voila, there is the EEPROM (all 512 bytes of it) sitting
in the memory map.  I've tried this and it does work! although
Motorola tells that the EEPROM functionality will not be up to spec.

So this explanation isn't too convincing.  Also, I'm not clear on what
you mean by "when the chip was being reset into the wrong state"---do
you mean on chip power-up or on power-down?


I think John Nagle's on the right track with the details on what
happens on power-down, involving the processor's ignoring of jump
instructions.  

With the 6.270 board, however, there is a hardware interrupt that is
triggered the moment that power is removed on power-down, during which
time system capacitors are still keeping Vcc at reasonable levels.
This interrupt causes a software driver to halt the processor by
executing the STOP instruction.  This _should_ mean that power-down
isn't the source of the problem---the 6811 should go into
"hybernation" the moment that power is removed.

One possible explanation is that when Vcc falls to a certain level the
6811 spontaneously starts up again and proceeds to trash memory.  I
think the RESET line is high on power-down, thus allowing this
situation to potentially occur.

I continue to think that popping the Motorola low-voltage detector
onto the 6.270 board's RESET line will solve any combination of these
problems.  We should have used one in the first place in the board
design. 

	- Fred








