27c256 | 4K81H | 68HC11A1 | 68HC11P1 | 68hc24 | 68HC711E9 | 68HC811 | 8255 | A2D | ADC | ADC12138 | Am85C30 | BRCLR | Buffalo | CMOS | EEPROM | EPROM | Ethernet | EVB | EVBU | HC11E1 | HC11E9 | HC711E9 | Horray | ImageCraft | IRQ | Keypad | LCD | MC68HC11D0FN | MC68HC11E1CFU3 | MC68HC11F1 | MC68HC711E9 | MC68HC711E9CFN2 | Microcore11 | Microstamp11 | Minikit | NVRAM | PSD | PSD8xx | PSD9xx | PT1000 | RS232 | RTS | RXD | SPI | SRAM | TXD | Watchdogs | XIRQ

I've seen lots of great SW & HW 'bulletproofing' ideas bouncing around here.. maybe we can summarize the major ones in a couple of sentences, and the forum can add as needed, so we can all paste them in a file for future reference. Regards, Alec ---------------------------------------- Alec Bath East Region Field Applications Engineer ST Microelectronics, PSD & NVRAM Memory Products 10 Maguire Road Bldg #1, 3rd Floor Lexington, MA 02421 781-402-8793 www.st.com/psd www.st.com/nvram -----Original Message----- From: [mailto:] Sent: Thursday, June 06, 2002 10:44 AM To: Cc: Subject: Re: [m68HC11] Watchdogs and safety (was Thinking...) Michael: There are many ways to write "almost failsafe" software. Filling unused program memory with NOP instructions could be one of them. Of course, after the MPU stops processing NOP's, you should be sure about what to do next. Also, filling the empty ( unused ) interrupt vector table with some pointer to your main program routine ( or other better place ) is another idea. Specially de ILLOP $FFF8 & $FFF9 vector. In my opinion, there is no way to separate hardware from software when talking about non-stop, systems. A microprocessor chip is a piece of logic circuitry. You have lots of integrated flip-flops and some robust state machines. The same that we have when we use TTL, CMOS or any other family. We can get reliable operation using any redundant method ( as when you transmit data in a network ) , but if we would like to have a deeper discussion, the device must be considered as a whole, in which EMI or any noise source cannot be separated from software, hardware, oscillators, assembly, etc. Once you have your prototype up and running, you should apply EMI test methods. A very good place to start, that can save you lots of software patches and hours of programming, is the printed circuit board layout. Sometimes is better than 3 external watch-dogs. Roberto Guillermo Berner Boolean General Tel: 54 11 4308 3500 Fax: 54 11 4308 3700 Favor responder / please reply to: ----- Original Message ----- From: "Michael Pont" <> To: <> Sent: Thursday, June 06, 2002 3:34 AM Subject: Re: [m68HC11] Watchdogs and safety (was Thinking...) > > Lots of interesting ideas in this (by now fairly general) discussion. > > Some thoughts. > > Watchdogs are not the only form of 'fail safe' mechanism available. For > example, EMI may be a source of problems, for which the watchdog timer is > not necessarily the best or only solution. In this case, one impact of EMI > can be corruption of the program counter, which has an impact (in some > circumstances) like a 'random' GOTO statement. Filling blank areas of > memory with 'NOP' instructions, followed by an appropriate error handler, is > a better solution than relying on a watchdog in these circumstances. > > Watchdogs are mainly useful (as a last resort) for dealing with situations > where the code gets 'locked' and no local timeout mechanism has solved the > problem. > > There is little point in using basic watchdog hardware to handle xtal > failures. In this case, you may need to rely on a 'backup' processor. One > way to do this is to have the backup processor monitoring activity on the > main processor: in effect, the backup processor acts as a glorified watchdog > timer. Of course, if the backup processor also has an xtal-based clock, you > may not solve the problem (for example, if the board containing both > processors has been dropped, both xtals may be damaged). In this case, it > may be more appropriate to drive the backup processor using a ceramic > resonator. This will not give accurate timing, but may let you 'limp home'. > > Michael. > > +==================================+ > > Michael J. Pont > http://www.le.ac.uk/engineering/mjp9 > > +==================================+ > > ----- Original Message ----- > From: "Tony Papadimitriou" <> > To: <> > Sent: Wednesday, June 05, 2002 6:03 PM > Subject: Re: [m68HC11] Thinking... > > ----- Original Message ----- > > From: Roberto G Berner <> > > To: <> > > Sent: Wednesday, June 05, 2002 7:24 PM > > Subject: Re: [m68HC11] Thinking... > > > > > > > The purpose of an external watch-dog is to cover the chance in which > > de MPU > > > stops clocking ( if it ever happens - who knows... ). The external > > circuit > > > must then take care of at least the RESET line. In some of my > > boards, this > > > external circuit also switches power off and then on again, > > partially or > > > totally. Remember that many circuit failures depend on EMI and > > latch-up. If > > > latch-up is the source of the problem, power should be removed. Of > > course > > > gentlemen, all this brain-storming is strongly application > > dependent. > > > > I agree on what you say. However, I thought we wanted something less > > simplistic than just a reset or power-cycling. Besides, in the HC11, > > a reset like the one you describe can be achieved with the CMF reset > > which is bidirectional and, therefore, can reset other parts of the > > circuit as well. The CMF actually starts its job when clocks stop or > > slow-down dramatically (it uses an internal RC circuit). Now, it too > > may theoretically misbehave under severe conditions, but so can the > > external watchdog, so it's a matter of statistics from here on. > > > > The real problem as I see it is when the failure needs some action > > like shutting down a motor in a controlled way (not just power-down), > > returning it to a safe position, etc. This requires some code > > execution in most cases. So, the MCU must be able to come up running, > > or an alternate MCU takes control. If it is something too extreme, > > however, it can be considered a total disaster that no amount of > > fail-safe measures can prevent or correct. > > > > > Roberto Guillermo Berner > > > > > > To unsubscribe from this group, send an email to: To unsubscribe from this group, send an email to:

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )