How reliable is the watchdog on the LPC81x series?

Why would you question its reliability? Yes, if you use the internal RC oscillator for everything, and that fails, the watchdog won't work, but it can't reset a non-functioning controller anyway.

Using either the RC or WDOsc, the RC oscillator is selected at reset, allowing you to check the crystal osc, and do a workaround if it's dead. The crystal oscillator is the least reliable (see AoE III, pages 443 to 450). You have four independent oscillators to play with, have fun.

If you're working on a project that requires extreme reliability, why not use redundant controllers? Only $0.60 each in qty.

BTW, ST's line of ARM controllers is very nice. The Nucleo line has 25 choices, NUCLEO-L011K4 has an STM32L011K4 Cortex-M0+, ready to go on a pcb, convenient Arduino Nano size pinout. Nucleo dev boards include a hardware debugger, only $11 at Digi-Key. Awesome.

Because I've seen too much grief of the "Now that normally never happens" kind.

I have had cases where the external WDT saved the day or avoided a truck roll. Including simple things that are not the fault of the uC such as the code inadvertently turning off the internal WDT because during an update a chunk of R&D code snuck in. Mostly it's lightning though where hardcore EMI generated by that upsets all kinds of internal uC registers and whatnot. An external WDT is a non-programmable device. Unless a bullet went right through that part of the board it's going to pounce.

Whenever I can and accuracy allows I use a resonator.

I am often forced into a certain brand and architecture because the code has to be re-used or their guys are familiar with it. And often it's all very small where you can cram in a little external SOT23-8 or so but not another QFP device.

Regarding ST, yes they uC are nice. However, I found that they excellent support when you client is a key account is not at all excellent when no key account.

Arduino ... not with a 10ft pole :-)

Because of that I liked the WDT in the Zilog Z86E04/08 chips. It was an internal RC timer, independent of the XTAL or whatever clock. Once armed you could not disarm it. You had to trigger it regularly.

As long as that arming function is a real fuse and not a non-resettable flash register because those can become corrupted by EMI. However, regarding uC type my hands are tied on this project, has to be the LPC series.

No, it's a software instruction. Once executed the RC monoflop is running and must be retriggered again with this instruction. If not it fires and resets the controller. If this instruction is executed during program start after reset the watchdog will bark if not regularly silenced regardless of any bits flipping. As far as I know it is on the same chip but quite independent of the rest of the chip. And BTW its POR and brownout detection has never failed me and I have used many in many different applications.

But these controller might be a bit tiny for your application: 60 bytes of RAM and 512/ to 2048 byte of EPROM.

In those two words the question is buried: How does this get executed in the hardware? If a fuse is blown and can never be "unblown" that is fine. If, however, it is just a flash bit I would not trust it.

Ok, but it depends on what turns that on.

Yes, we need a different caliber.

First the chip had no flash, program was in EPROM. Second, if you are afraid that the program gets clobbered because of EMI than a watchdog has become useless. A reset by a watchdog, may it be internal or external, will only lead to the (re-) start of a defective program.

You could also ask this for an external watchdog. If you see such problems you would need another caliber of hardware. Space grade, rad hardened, dual or triple independent CPU, or best relays working with 24V logic levels and the rest of your hardware should prevent any disturbances coming from external.

EPROM can be suspect because that relies on floating charges which can become disturbed by nasty outside events. Unless they make that one cell unusually large or something. That's one reason I ask, to see whether anyone can say something about the WDT reliability on the LPC series.

That can be ok, provided the software has redundancies and possibly a "limp more" built in. Just like the better vehicles have (or had) in case the motor control unit goes on the fritz.

No, because the external watchdog is always on. It's all hardwired and on the ones I used so far there is not way to disable them. Which unfortunately makes them inconvenient during debug.

Not for this application though. Sometimes one has to achieve the highest possible reliability while not exceeding a very modest budget. For me that means to always provide an external POR/BOR function because I never trust internal ones. With the WDT it depends and the reason I asked here and in a German NG was that the LPC family of processors is new to me.

Yesterday on a mountain bike trail I saw how watchdogs can fail: On the way up to Placerville a dog came running and barking at me. Good dog, good watch. On the way back I saw him sleeping in the shade :-)

Connect it via a zero-ohm resistor.

Cheers

Phil Hobbs

That, a jumper or a sacrifial trace with re-solder surface is what I usually do. However, in this case it makes the SW job tedious because every time you want to change it you have to take apart a lot of gear to get to it.

It often also requires to provide a cap to ground on the reset line which you can't really have when an external POR/BOR/WDT chip is connected to the reset line. Low cost chips of this kind have no feature to disable just the WDT part in there.

guys but not by nasty external events. But there is no real difference between nasty external events and software people. ;-)

Sure. But debugging software on installed production hardware is not generally a great idea unless it's super small production, in which you can just run a couple of wires to a switch on the cabinet. ;)

Cheers

Phil Hobbs

I've used LPC17xx WDT for years now without any problems. I did a quick look at the 812M101 docs and it's very similar. I suspect the low level IP block is similar.

WDEN=1 WDRESET=0 is handy for debug mode. I usually have a jumper on the board the FW looks at and sets either wdreset=0 or 1.

The down side, unlike a external wdt, the fw boot code has to work correctly to enable the wdt. It's one of those cases where boot code fails, no wdt, unit is dead or boot code fails external wdt does reset, boot code fails, external wdt reset, .... Of course the external wdt reset might clear a sparadioc boot failure.

Handling lightning events (as well as nuclear EMP issues) must be handled at the _system_ level. There is not much point in trying to solve these problems with board level solutions.

Oh Reinhardt, them's fight'n words :-)

Sometimes when there is lots of other hardware such as plumbing and stuff involved there is no other choice.

Not always that easy and it is best to do both. Cost often forbids to have everything in mil-spec metal enclosures. So far my desigsn have ended up nearly bullet-proof in that respect. I just do not know the LPC series processors which is why I asked.

No that's finally a word, thanks!

True. Although in this case the units typically remain powered all the time. I wish uC manufacturers would include an option where for production units you could have the code verifiably blow a fuse which enables the WDT irrevocably.