Newsgroups: comp.robotics
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!udel!news.sprintlink.net!noc.netcom.net!ix.netcom.com!netcom.com!nagle
From: nagle@netcom.com (John Nagle)
Subject: Re: 68HC11 reset circuit
Message-ID: <nagleD7uurC.M0n@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <3n41bs$n9k@spock.asic.sc.ti.com> <3n7bla$lif@ionews.io.org>  <95117.203453LEEK@QUCDN.QueensU.CA> <3nsb0g$7ip@ionews.io.org> <95120.005949LEEK@QUCDN.QueensU.CA>
Date: Sun, 30 Apr 1995 15:52:24 GMT
Lines: 27
Sender: nagle@netcom11.netcom.com

<LEEK@QUCDN.QueensU.CA> writes:
>In article <3nsb0g$7ip@ionews.io.org>, speff@bonk.io.org (Spehro Pefhany) says:
>>
>>The design (of the H11) may be considered non-robust because there is no
>>protection possible against runaway programs from corrupting eeprom,

>>It appears the original HC11 data sheets did not make it clear that this

>Only the original.  Motorola has mentioned more than a few times about
>the important usage of reset cicruits in revised databooks.

     Unfortunately, the original EVB board didn't have a reset circuit,
and Motorola did a work-around in the BUFFALO monitor, building the
EEPROM-modifying instructions on the fly to avoid having them in memory
during reset.

     This chip has the unusual property that as power drops, it
continues to execute most instructions but stops taking branches.
So the entire contents of memory gets executed a few times, in address order.
If something that shouldn't be executed is anywhere in memory, trouble
ensues.  That's why forcing reset during power-low is so important.

>App note: 997 deals specially address the reset circuit issue.

     Yes, and I recommend reading it.

					John Nagle
