Blink when input is constant?

Question

I would like to have a status LED to make sure my microcontroller software hasn't faulted. From software, I will alternate an output so if it dies, the output will be constant. I want the status LED to blink when there's a fault instead of blinking to show there is not one. So, I need a separate circuit that will blink the LED when its input is stuck high or low.

I can come up with a circuit myself, such as an edge detector that resets a 555. However, I would like to know first, is there a name for such a circuit? Or even better, if it comes in/can be made from a single IC?

EDIT: A completely external circuit is preferred because it'd be isolated and unlikely to be affected by software changes.

I don't think the Raspberry Pi's CPU falls into the microcontroller category, does it? In any case that information should be in the question, not a "by the way" in the comments. — Transistor, Oct 01 '21 at 20:44

hacktastical · Answer 1 · 2021-10-01T21:51:22.270

10

XY problem. This isn't a job for a 555. This needs to be dealt with by software, with a little help from RPi hardware. (Obi-wan voice: “Use the source, Luke…”)

What hardware? The ARM architecture in RPi has a watchdog timer resource. The point of a watchdog timer is for the system get unstuck and recover. I encourage you to use it (see the link below.) Further, RPi is powerful enough to run a robust RTOS, be it an open-source or commercial package. Any of these OS releases know how to deal with a watchdog and respond in an intelligent way (and if they don't, choose a different one.)

Related: https://diode.io/raspberry%20pi/running-forever-with-the-raspberry-pi-hardware-watchdog-20202/

What does that mean, 'respond in an intelligent way'? If you don’t want the system to recover but simply stop and inform the user that it has done so (why?), the watchdog timeout can instead cause a branch to a routine that flashes an LED and just sits there until the user intervenes. This routine can also, more importantly, log information for diagnostics later and also place the system in a 'safe' state. Again, this ability to respond to the watchdog and log errors would be something your OS would have built in.

Relevant: https://stackoverflow.com/questions/13217959/how-to-use-the-watchdog-timer-in-a-rtos

For some inspiration, this is how the Apollo Guidance Computer team did it: https://youtu.be/B1J2RMorJXM

edited Oct 01 '21 at 21:51

answered Oct 01 '21 at 20:38

hacktastical

49,832
2
47
138

1

An RTOS may be perfectly able to tell if ***it*** is working correctly. It will not know when your own code is or isn't. I ***never*** depend on an O/S I didn't write myself to *"know how to deal with a watchdog and respond in an intelligent way"* with respect to an application I'm writing. And because of that, I would not permit an O/S I didn't write to operate the watchdog. (And yes, I've been writing O/S systems from the ground up from before I worked on the Unix v6 kernel code in 1978. A very long time.) – jonk Oct 02 '21 at 04:45
Yes, whatever handles the watchdog has to be trusted code. That’s kind of the point. Not knowing the whole system that OP is proposing I can’t make any statements about that. If they’re writing something that requires functional safety then they are obliged to use code developed under an applicable framework (like ISO26262 for example.) – hacktastical Oct 02 '21 at 05:05
I just think it’s kind of short-sighted to have an ‘I’m alive’ blink as a solution. – hacktastical Oct 02 '21 at 05:07
The quality of the utility of the LED as described by the OP is entirely dependent on the thought and care that goes into using it. I also wrote to my comment to Spehro that the LED's use may be the subject of future modification and that an external SOT23-6 MCU is the right approach. It is, almost by definition, ***not*** short-sighted. Quite the opposite, in fact, since an external MCU can be modified per future requirements, as well. It's the right way to go. – jonk Oct 02 '21 at 05:37
I like this answer for others that may come by this question and the software-configured watchdog really is right for them. In my situation, I want it to be foolproof, and I am that fool who might misconfigure something, or screw up my startup scripts. The application being watched is a work in progress, which is also why I want the blinking status LED. I want to know problems when they happen so I can fix them. I know I'll be around it to investigate and reset it myself. – Drago Rosson Oct 02 '21 at 09:23
So like @jonk is saying, something completely external to the pi is preferred (or I'd at least like to know what the best external option would be) because it'd be isolated and unlikely to be affected by software changes. – Drago Rosson Oct 02 '21 at 09:28
2

@DragoRosson Read [this article](http://www.ganssle.com/watchdogs.htm). It should also add some fuel to the fire: *"... no WDT internal to the CPU is really safe."* And I agree. I've never used an internal WDT for WDT purposes. I use them, on occasion for timers. But not for WDTs. Where it matters, there is always an external WDT. Learned that lesson so long ago I can't exactly recall the decade anymore. ;) – jonk Oct 02 '21 at 09:43
Failing OS watchdog is not so very remote: I have one system running (controlling the fridge) on an esp32 where, as far as I can tell, the internal oscillator simply stops running under some (probably EMI related) conditions. An external watchdog---actually built around a 555 with reset pulse---keeps the hardware alive. But a dedicated hardware watchdog chip would be a much better idea. Be aware of the danger of the watched hardware getting stuck in 'resetting' mode. (In my case I have a series capacitor to prevent tying the watchdog down). – 2e0byo Oct 02 '21 at 15:10
1

I haven’t used an external watchdog chip in years. The programmers I’ve worked with seem pretty comfortable with using an on chip resource, so I haven’t bothered with it (one of those programmers is a well-known kernel guy.) Of course it’s not gonna catch a dead oscillator or other catastrophic hardware problem, but for workaday software errors like memory leaks, pointer smashes and other typical things that can cause the system to die the internal WDT works fine. – hacktastical Oct 02 '21 at 19:25
As it is, to use an external watchdog timer you have to configure a non-maskable interrupt pin. That’s pretty much the same issue as using the internal watchdog: if the configuration is wrong, even if the watchdog times out it won’t cause the exception to fire. – hacktastical Oct 02 '21 at 19:28
1

@hacktastical It sounds like OP doesn't look for an exception interrupt to be handled by the software itself. They want a human exception handler, notified by a blinking LED, where the human in the loop knows how to reset the software in any imaginable failure state :-) – Bergi Oct 02 '21 at 19:47
@hacktastical No. Read the linked article I gave earlier, if you need to see actual, exact and detailed reasons why an internal WDT isn't safe. The author is credible and writes well about the topic. If you aren't seeing the reasons now, you will after reading it. Just give it a shot. – jonk Oct 02 '21 at 20:01
@jonk -- the issue with external WDTs is that they are relatively hard to make safe against accidental feeding compared to an internal WDT -- it's possible by devoting say an entire I/O port to feeding the watchdog, or if you have an external memory bus, but it'll require a bit of logic to do so – ThreePhaseEel Oct 02 '21 at 23:46

score 4 · Answer 2 · answered Oct 01 '21 at 20:19

4

You could program another microcontroller, maybe an SOT23-6 or SOIC-8 package, to do that.

It would be a simple program, running off an internal RC oscillator, and using an internal (reliable) BOR/POR peripheral. Just the chip and a bypass cap on the power supply.

Alternately, you could use a resettable monostable multivibrator (not necessarily a 555) and a blinking LED. The component count and board area would be higher.

answered Oct 01 '21 at 20:19

Spehro Pefhany

376,485
21
320
842

1

Yes, an *external* watchdog is the right approach, I think. Easy to add. And since the OP has a specific desire for the LED behavior (which may later want to be altered), it's best to just write it up. It's not the east bit difficult. But it does add a whole other toolchain to be supported and maintained. But it's still not all that bad, really. Just a short "pain" and then it is over and done and the skillset will be likely useful elsewhere. – jonk Oct 02 '21 at 04:53
1

Yes, I should have mentioned too that there are external WDT chips (sourcing and selection left as an exercise), and connecting one of those to a blinking LED meets the requirements and is potentially more reliable than another MCU. – Spehro Pefhany Oct 02 '21 at 16:32

Math Keeps Me Busy · Answer 3 · 2021-10-03T14:57:19.617

3

I want the status LED to blink when there's a fault instead of blinking to show there is not one.

The following circuit may work for you, although I have not tested it.

schematic

^{simulate this circuit – Schematic created using CircuitLab}

The 555 is configured as an astable relaxation oscillator. However, the timing capacitor can be shorted by Q1. If this happens before the voltage on the timing capacitor rises to the trigger voltage, the 555 will remain in the same state and the LED will not blink.

Capacitor C2 limits the duration of the heartbeat pulse in case the source of the heartbeat gets stuck in the high state. C2 needs to pass current in each direction. In one direction it can flow through the base of Q1. D2 serves to provide a path for current in the opposite direction.

The resistors R1, R2 and Ctimer control the frequency of the blink. The heartbeat should be sent at least twice the circuit's blinking frequency to ensure blinking does not start. The heartbeat pulse needs to be sufficiently long to drain Ctimer through Q1.

If you want to change the default state of the LED, reverse it's polarity and connect the anode to Vcc.

edited Oct 03 '21 at 14:57

answered Oct 02 '21 at 20:27

Math Keeps Me Busy

18,947
3
19
65

Would this fail if Heartbeat remained high? – Transistor Oct 02 '21 at 20:54
1

Yes, heartbeat needs to go high long enough for the capacitor to discharge, and then go low again. By your question, I am guessing that this behavior may not be acceptable. – Math Keeps Me Busy Oct 02 '21 at 20:56
It would catch cases where the MCU failed with Heartbeat low but not when high. You could capacitively couple the heartbeat signal through and rectify it. That would seem to cover both cases as it relies on Heartbeat changing state. – Transistor Oct 02 '21 at 20:59
I could add a diode/cap/resistor to the base circuit to ensure that the base cannot remain high indefinitely. – Math Keeps Me Busy Oct 02 '21 at 21:00
I modified the schematic. I'm not sure that R5 is necessary, since there is a current path between base and emitter of Q1 and in the opposite direction through D2. – Math Keeps Me Busy Oct 02 '21 at 21:08
That should work. R5 doesn't exist, by the way! – Transistor Oct 02 '21 at 21:40
I took it out before the 5 minute edit window was up. It was parallel to D2. – Math Keeps Me Busy Oct 02 '21 at 21:52

score 2 · Answer 4 · answered Oct 05 '21 at 16:17

is there a name for such a circuit

When you have your software pulsing something periodically to indicate that the software is running normally (not "locked up"),

Watchdog: hardware that distinguishes between normal and locked-up software
Feeding the watchdog: the bit of software that tells the watchdog that things are running normally. (Usually in only one place in the main loop). Sometimes called "petting the watchdog" or "kicking the watchdog".
Watchdog's timer: the timer inside the watchdog that normally gets reset by the timer periodically. External watchdog ICs often use a resistor-capacitor network that slowly charges or discharges. Integrated watchdogs (on-chip watchdogs), on the same chip as the microcontroller, often use a a digital counter driven by some crystal oscillator or a fast RC oscillator.
watchdog timeout: when the watchdog hasn't been fed in long time, the watchdog's timer runs out of time and the watchdog takes action, typically pulling a reset line that watchdog resets the CPU and all peripherals.
consistency check : Rather than unconditionally feed the watchdog every time through the main loop, many systems do some quick checks (similar to assert() checks), then if all the checks look good, only then feed the watchdog. For example, this can catch problems where the main loop (responsible for feeding the watchdog) is still running, but some other thread has unexpectedly stopped.
heartbeat signal: an external signal, typically connected to an LED, that indicates to outsiders that things are running normally. A few hard real-time systems have a main loop that executes extremely regularly, so wire running to an external watchdog chip is used directly as a heartbeat signal. Other systems, every time they feed the watchdog, then check if a second has gone by, and only then flip a separate wire connected to the heartbeat signal -- so humans see a regular, consistent, slow LED blink even when the normal main loop cycles too fast to see or cycles with irregular timing.
supervisor chip: (aka voltage supervisor): a chip that drives the reset line of a CPU, holding it in reset as the power rails slowly ramp up to the normal voltage, until the voltage has stabilized. Many of these chips also include a watchdog timer.

A completely external circuit is preferred

Many people agree with you:

"no WDT internal to the CPU is really safe." -- Jack Ganssle

"If it's on the same die, it won't fly." -- George Farmer

score 1 · Answer 5 · answered Oct 03 '21 at 00:55

Configure one of the spare hardware timers to toggle an output based upon the counter value. For example, the timer counts up and rolls over at 0xFFFF and the output toggles at 0x7FFF and 0x0000 for a 50% duty cycle. After the software configures the timer at startup, then the toggling output will be under control of the hardware timer and doesn't require software intervention. Connect the output to the LED so that the LED blinks.

Now create a software watchdog mechanism that periodically resets the timer's counter value to zero if the software is working properly. The software watchdog should reset the counter value before the timer output toggles. This will prevent the LED from flashing while the software is working. If the software ever fails, then the software watchdog mechanism will not reset the timer counter value, which will allow the output to toggle and flash the LED.

davidcary · Answer 6 · 2021-10-06T22:00:22.070

schematic

^{simulate this circuit – Schematic created using CircuitLab}

I haven't tested this, but it looks similar to what you want. R1 and C1 set the output blink frequency when the input is constant (either hi or lo). R2 and C2 set the delay time from when the input stops pulsing to when the output starts blinking. When the input is constant, R2 eventually drains C2 and enables the oscillator to blink. When the input oscillates, C2 and the diodes charge up C2, so that NAND1 input goes close to GND, and then the output of NAND1 stays hi, and then D1 stays dark.

Blink when input is constant?

6 Answers6