Newsgroups: comp.robotics
Path: brunix!uunet!wupost!csus.edu!netcom.com!nagle
From: nagle@netcom.com (John Nagle)
Subject: Re: 6.270 Boards -- be careful before deciding
Message-ID: <1993Jan18.021811.8970@netcom.com>
Keywords: control robot miniboard pcb 6.270
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
References: <1993Jan17.075322.10766@magnus.acs.ohio-state.edu> <1jc2p1INN903@life.ai.mit.edu> <1993Jan17.222345.26639@news.media.mit.edu> <1jcsueINNkt2@life.ai.mit.edu>
Date: Mon, 18 Jan 1993 02:18:11 GMT
Lines: 27

bleck@mobot.ai.mit.edu (Olaf Bleck) writes:
>That would be a MC34064, low voltage inhibitor.
>It sounds like the right solution.  Way back when we were first using the A
>series, we were having similar problems.  Turns out that on the A's at
>least, we were getting a spurious write on *power down* that trashed the
>reset vector or something in NVRAM/RAM.  That low power chip fixed it to some
>extent.  What it does is pull down the reset line when the voltage drops
>below the threshold so that the processor is halted completly when you power
>down, thus preventing the spurious write.

      Early (and maybe current) 68HC11s have the strange property than
when run undervoltage, as during power down, the CPU stops doing branch
instructions before it stops doing other instructions.  The CPU cycles
through the address space, executing all instructions in memory in sequence,
wrapping around at 64K.  So if there is some sequence that stores into
the non-volatile memory, it will be executed during power-down.  
Motorola recommended in one of their documents that the ritual for changing
NVRAM not be coded in such a way that executing all the instructions in 
memory in sequence will make it happen.  

      Have they fixed this yet?

      Still, fixing this shouldn't break existing boards or software.
So that may not be the explaination.

					John Nagle

