Alll the 555 watchdog timers I have found are trying to reset the processor after a large number of seconds. My problem is different.

I am multiplexing LEDs, pushing them to their limit of about 100mA, with a 100us pulse. Now, the question arises as to what happens under conditions that would interfere with the pulse. So what I am doing is creating a "watchdog" that turns on for about 100ns and then turns off

I am attaching the schematics. The first is the schematic for the "555 & friends". Note that I am not discharging the capacitor with the DISCH pin of the 555. If there is no trigger, the capacitor charges to 2/3Vcc and drops the output low. It stays at low until the processor pulls its heartbeat pin low. This discharges the capacitor, and, falling below 1/3Vcc, starts the next cycle Thus, the pulse is hardware-generated, not software-generated. If the processor fails to trigger a pulse, there is no pulse to the LEDs, so there is no burnout. The PowerPoint slides are animated, and the "explosion" illustrates the failure mode if there is not a controlled trigger. The 100us pulse controls all the LEDs; an NMOS transistor selects which column is activated. While it is true that, in this illustration, the 555 has more than enough power to provide a source for a single LED, the final design will have a dozen or so in each column, hence the use of higher-power MOSFETs (1200mA).

This protects the LED array from either software failure or debugging by single-stepping. The driving pulse is limited entirely by the 555 timer.

My change in removing the DISCH pin from the circuit seems a bit odd, but I thought carefully about this; I don't want the capacitor to discharge unless there is a distinct negative transition on the TRIG line, and whether that signal is held low or high for too long should not matter. I have been debating putting a capacitor in series with the I/O pin to convert the output signal to a pulse, but I am not sure about how I should do this or how to select the size.

 

Firstly - full marks for using a hardware timer instead of relying on software!

There is nothing fundamentally wrong with how you are using the 555. There are no rules that say you may only use the three "standard" circuits (astable with resistor to V+, astable with resistor to pin3 and monostable). A 555 is just two comparators and an SR latch - there are a lot of other ways of connecting it.
I would suggest a higher value of R1, a lower value of C and a current limiting resistor (220Ω or so) in series with the microcontroller pin.

The only snag is if the microcontroller crashes whilst the output is low. In that case, the 555 output remains on and the LED fails - because on the 555 TRIGGER is dominant over THRESHOLD.

The 555 isn't the only monostable in the world! I would suggest that you change to a 74HC123, which is edge-triggered. The output pulse would be 100μs regardless of what happened on the input. It also has a very handy notQ output which would save you the NPN transistor (and there are two in a package, for about the same price as a 555)

 

Thank you.

 

Ian0 is correct in that if the 555 trigger input is held low, then the output will remain high.

My 555 timer cookbook shows an AC coupled trigger circuit using a 10nf capacitor combined with a 4k7Ω pull-up resistor in parallel with a diode connected between pin 2 and Vcc.

However this won’t work for you because you have a charged 100nf capacitor on pin 2 – you could experiment with a larger AC coupling capacitor (and/or reducing the 100nf capacitor and increasing the value of R1). If the 100nf capacitor is reduced to 1nf and R1 increased to 91KΩ, this may work with a 10nf coupling capacitor.

Otherwise I’d recommend you go with Ian0’s suggestion of using a 74HC123.

 

Won’t a standard 555 monostable with a capacitively coupled input also work?
it just uses more bits than the hc123.

 

Firstly - full marks for using a hardware timer instead of relying on software!

Next month I will start my 59th year as a programmer. And if there is one thing I have learned, it is to not depend on software to do a job that requires absolute reliability. I re-read the 555 documentation many times, but the TRIG overriding THRESH escaped me. I am first going to try the capacitor in series solution, since I have about a hundred 555s in inventory.

Thanks
Joe

 

Next month I will start my 59th year as a programmer. And if there is one thing I have learned, it is to not depend on software to do a job that requires absolute reliability. I re-read the 555 documentation many times, but the TRIG overriding THRESH escaped me. I am first going to try the capacitor in series solution, since I have about a hundred 555s in inventory.

Thanks
Joe

If I remember correctly, there is a truth-table and it says that OUTPUT will be high if TRIG is low and THRESHOLD is high.
If you want to save a component - you can eliminate that output inverting transistor by turning the whole lot upside down and faking a positive-going discharge with a diode from output.

 

Won’t a standard 555 monostable with a capacitively coupled input also work?
it just uses more bits than the hc123.View attachment 245730

OK, I'm curious. What does the reverse-biased diode do in this circuit?

 

As per my post above (#4), a 10nf coupling capacitor with a 4k7Ω pull-up resistor will work.

The purpose of the diode is to limit the positive going pulse that appears on pin 2 as a result of the input (to the capacitor) going positive.

 

Next month I will start my 59th year as a programmer. And if there is one thing I have learned, it is to not depend on software to do a job that requires absolute reliability. I re-read the 555 documentation many times, but the TRIG overriding THRESH escaped me. I am first going to try the capacitor in series solution, since I have about a hundred 555s in inventory.

Thanks
Joe

I'd like to point out that hardware is not really all that reliable. Components fail with considerable regularity. You need a layered approach.

 

I'd like to point out that hardware is not really all that reliable. Components fail with considerable regularity. You need a layered approach.

Yes. Backups on the backups. Trust, but verify. In this case, one level of backup suffices based on the risk analysis and cost. If this circuit were going to be in life support in the ISS, there would be a team designing backups on the backups, and more redundant redundancy that I could imagine.