0

I have a mosfet controlling power to a heater. I send pulses (akin to pwm) to tell the mosfet to turn on and send current to the heater. The pulses are coming from a Beagle Bone Black. The process on the controller takes the feedback from a thermistor and sets the output pin that's connected to the mosfet high, when necessary. If the program halts or freezes with the pin set to high for more than 10 seconds, then the equipment will catch fire. What kind of circuit can I use to limit the length of the high pulse to only 1.5 seconds? It is expected that the pin will transition from high to low in less than 1.5 seconds (henceforth reffered to as the limit time) but can make multiple transitions (low to high to high to low) many times per second. The frequency could be as high as 250hz.

user77232
  • 171
  • 1
  • 1
  • 9
  • 1
    You better generate the PWM in hardware instead of software then. Software only controls the pulse length as a number put into the PWM hardware. The Beagle Bone black has a dedicated PWM hardware. – Janka Jun 11 '19 at 00:07
  • Except that the userspace can lock up while the PWM generators keep on sending pulses, which is exactly what I don't want. The PWM will only stop when the watchdog resets the system; 60 seconds later. – user77232 Jun 11 '19 at 00:44
  • I've extended my comment into a answer. – Janka Jun 11 '19 at 07:08

6 Answers6

2

I am a little surprised by the number of answers here recommending a WDT for this task. The WDT can guard against software faults, but implementing a good robust WDT is not trivial, and designing the code to fail to "kick the dog" when a fault occurs is fraught with peril, especially on a complicated multi-threaded system like a BeagleBone running (presumably) Linux. A watchdog timer is not a magic wand that makes software safe - it is a tool that can make software more robust, but only if implemented correctly.

If this were my project, I would implement two hardware mitigations to remove the processor from the equation entirely:

  1. A safety circuit that detects if the GPIO from the processor has latched high for more than ten seconds, and if so, kills the heater. This is your first line of defense.

  2. A one-time use thermal fuse that kills the heater in the event that the temperature rises above a critical threshold. This is your second line of defense.

Why both mitigations? Well, the first option mitigates a particular known failure mode (processor output latches high), but this won't catch all possible failure modes that cause the particular hazard (overheating). It is likely there are other failure modes that can cause this hazard - for example, the PWM output could still be transitioning faster than 0.1 Hz but with a 99% duty cycle, or maybe the relay that operates the heater latches shut.

The thermal fuse detects the hazard directly (by detecting the overheating) and blows, permanently cutting power to the heater and removing the hazard. This would actually be sufficient to catch the GPIO latched condition on its own, but in this case we probably don't want to do that since the thermal fuse is permanent and it sounds like you are dealing with debugging your code (it would be inconvenient to replace a thermal fuse every time the output stayed high during development).

As for the safety circuit, something like this should do the trick:

schematic

simulate this circuit – Schematic created using CircuitLab

The circuit works like this: R1 and C1 form an RC circuit, selected such that their time constant allows them to charge to the reference voltage created by R2 and R3 at t=10s when the GPIO voltage is high. Once this happens, the output of the comparator goes to logic low, and when ANDed with the input signal, forces the heater off.

The reverse Schottky diode across the resistor allows the capacitor to drain quickly (ideally instantly) when the GPIO goes low, resetting the time delay circuit. Since the value of C1 might be quite large depending on the value of R1 chosen, it may be prudent to put a small resistor in series with D1 to limit the discharge current to the maximum value the GPIO is allowed to sink.

No fancy timers, no 555s, no watchdog circuits - just some basic components and simple glue logic.

Synchrondyne
  • 3,764
  • 21
  • 31
1

If the program halts or freezes with the pin set to high for more than 10 seconds, then the equipment will catch fire.

It would be prudent to add a thermal cutoff fuse/switch. Not only, in case your software fails, but in case your switching element (mechanical or solid-state) fails shorted.

sstobbe
  • 2,992
  • 1
  • 11
  • 12
  • If there is a dead short the power supply will cut off; but there is no harm in having a secondary fuse on the board. – user77232 Jun 12 '19 at 18:29
1

To expand on the WDT idea, mainly on the software side. This answer mostly discusses what can be done in software - it's not a full solution. Use a thermal fuse.

systemd. Live it or hate, it helps in this use case.

Get a dedicated external WDT chip. It will have an input pin and an output (likely open drain). Connect BeagleBone's GPIO to input of the WDT and it's output to BeagleBone's reset.

Then you configure kernel and systemd to use that GPIO to feed that external watchdog. This protects you from kernel and systemd hangs. Later on it's pure software - you use systemd's watchdog feature to make sure your software does not hang. If it does - depending on your configuration either your software or the whole system gets restarted.

Further reading: http://0pointer.de/blog/projects/watchdog.html

jaskij
  • 1,223
  • 8
  • 13
  • The AM3358 that the Beagles are based on have an internal hardware watchdog timer. It is independent of the kernel, and will reset even if the kernel halts. – user77232 Jun 12 '19 at 15:03
  • @user77232 the point is to connect the hardware watchdog (internal or external) with software. To have a full chain from OP's software to hardware watchdog. Which won't just restart the system the hard way for each and every failure. – jaskij Jun 12 '19 at 17:18
  • @user77232 also - is the internal watchdog independent (ie standalone RC oscillator) or does it run from the system PLL? – jaskij Jun 12 '19 at 17:19
  • I actually don't know. I'll try to find out. – user77232 Jun 12 '19 at 18:22
  • @user77232 in this application I suppose it doesn't really matter. I mean: it **is** safety critical. But what are the odds that a kernel bug screws up the PLL? – jaskij Jun 12 '19 at 18:25
0

Protection from MCU hang or hardware fault

If you want to protect against a software fault leaving the output drive pin for your FET high (and the heater ON) then you need to setup your Watchdog timer.
There are a heap of tutorials that can educate you on its operation ...here is one.

If you want to protect your system against hardware faults (eg pin stuck high, faulty FET etc) you need extra hardware. This may be as simple as an overtemperature detector that shuts down the power supply. Your device heats up rather dramatically in 10 seconds so detecting this may not be a problem.

Update: Of course you could always implement an external WDT of your own design which in itself could be relatively simple, (perhaps a 555 timer). The difficulty here is to provide surety in that design. Any WDT you make is it's own reliability issue. using capacitors as timing elements is always a concern so you want to keep capacitor values small.
I'd tend to think you should be using something like this STWS100 as an external WDT. No external capacitors is a real advantage here.

Jack Creasey
  • 21,428
  • 2
  • 15
  • 29
  • It's not reasonable to have a watchdog timer set to 1.5 seconds. – user77232 Jun 11 '19 at 00:51
  • You can set the timer to anything you want within its range. Can you count in code? It's very much the standard way of assessing software troubles. – Jack Creasey Jun 11 '19 at 02:38
  • I prefer to set the watchdog to 10 seconds, since there are other things in the system that may cause the system to be unresponsive for a few seconds, that I don't want the watchdog timer to get triggered on. – user77232 Jun 11 '19 at 14:45
  • Given the importance of your needs (the equipment catches fire) then the choice is yours. However the internal WDT would appear to be the most sensible first step. – Jack Creasey Jun 11 '19 at 15:07
0

You better generate the PWM in hardware instead of software then. Software only controls the pulse length as a number put into the PWM hardware. The Beagle Bone black has a dedicated PWM hardware.

Use the watchdog timer to address hung PWM. Its time is sometimes configureable. Check it.

If not you can use a "PWM watchdog", a monoflop gating the PWM output which has to be triggered each second by the software. For example a Schmitt trigger NAND, 1/4 4093.

schematic

simulate this circuit – Schematic created using CircuitLab

Do you trust your WDT trigger software? See if you can put the output into one-shot mode, making the kernel or better the hardware generate a single pulse on trigger, not userspace.

Janka
  • 13,636
  • 1
  • 19
  • 33
  • Is single shot mode an actual thing? Is it possible for the PWM generators to do that? – user77232 Jun 11 '19 at 14:43
  • I've yet to see a WDT that could be used this way, and putting the signal through an external network with it's own failure characteristics (especially a capacitor) brings it's own reliability concerns. – Jack Creasey Jun 11 '19 at 15:13
  • @JackCreasey, apart from using the wdt in software, what hardware solution would you suggest? – user77232 Jun 11 '19 at 15:17
  • @Jack Creasey: This **is** a watchdog, and the trigger port is to be connected to some GPIO of the board. – Janka Jun 11 '19 at 15:23
  • You are right @Janka ...I misread your post. A simple RC such as you propose would concern me however, since the delay and trigger level move with VCC changes. I'd prefer to use a 555 as a primitive WDT since the trigger levels are at least well defined. – Jack Creasey Jun 11 '19 at 15:43
  • It's just an example. I'm lazy. – Janka Jun 11 '19 at 19:21
0

You can use a 555 timer to make the pulses out to the heater. When it stops seeing transitions, it stops making output pulses.

CMOS version draws little supply current

http://www.ti.com/lit/ds/symlink/tlc555.pdf

Here's a stackexchange article on using it to make an output pulse. 555 timer, one shot trigger

Make the width what you want. If there is no pulse from the uC to keep triggering it, the output pulses stop.

CrossRoads
  • 3,453
  • 1
  • 6
  • 14