A while ago I wrote blog on “intelligent” output drivers, which allow you to monitor the output current to an external load that your micro is controlling. But what happens if your micro should freeze? What happens to the load when it is permanently on? An instance in my experience was driving the print head of a dot matrix printer, the long gone LRC 7040. Each pin on the 7-pin print head is activated by a solenoid that impels the pin forward causing the tip to compress the inked ribbon against the paper and leaving a small dot on the paper. If the solenoid is energized for longer than a certain period the coil overheats and burns out. The print head is toast! Since the micro is switching a solenoid there are likely to be EMI spikes, and in the prototype stages these may crash the micro, but you don’t need a microcontroller malfunction for this to happen – it can actually happen during development if you stop at a breakpoint at an unfortunate stage in the execution of the code.

There could be even more disastrous consequences depending on what you are controlling. Compelled by Murphy’s Law, the presumption that a microcontroller can and will malfunction at the worst possible time drives the need for a robust design. Given the above scenario, how can you approach your design so that an output will fail “safe” under a soft failure of the microcontroller?

One approach would be to use a retriggerable monostable to drive the output. In this case the firmware would have to clock the monostable at a rate faster than the timeout of the monostable in a manner reminiscent of a watchdog timer. In its simplest form there is a hang time before the output turns off even when the desired state actively changes from on to off. The monostable could be something like a MC14538, and the number of components would impact the cost, PCB real-estate and reliability of the design. See Figure 1.

click to view larger version



Figure 1: The micro must toggle the input to the MC14538 faster than the monostable timeout period. Obviously there is a hang time of up to the full monostable period when the output is de-activated.

An alternative might be to control both sides of the load – the supply to all loads could be controlled by a separate output, perhaps even linked to an independent monostable or even the output of the watchdog timer, so that if it timed out all outputs would be disabled. The micro could then control the other side of each output load as normal as in Figure 2.

click to view larger version



Figure 2: Using a single monostable to control the power to the loads spreads the cost across several channels when compared to the approach in Figure 1. Also the load will be deactivated at the same instant that the micro turns it off. An additional benefit (when an enable signal is fed to the monostable CD input) is that the outputs will not be activated until the system is ready. For instance some micros will power up with the outputs high which will activate the outputs until the outputs have been initiated.

A third solution might use two outputs and one could improve on a simple EXOR by using one as an enable (on true) and reset (on false) into a some kind of register arrangement that would require a sequence to enable the output. You also need to consider how to de-activate the system so that it could not fail in the active condition, even if it had got there legitimately. This approach will not solve the issue I mentioned earlier of creating a breakpoint at a critical point during development. It is also rather hardware intensive.

click to view larger version



Figure 3: In a two output combination, the signal clocking the D-type must occur during the monostable period created by the enable input (on D) going active. It may be possible to use the Enable as a common signal for several outputs. Clearly (pun intended) you will need to force some kind of power on reset on the CLR input to initialise correctly. A watchdog would ensure that the output doesn’t remain active when the micro freezes.

In a recent comment in a Friday quiz on the I2C bus the poster complained of a “wedge condition” that required a hardware reset on a device without that feature. Using a transistor to switch the power (provided you kept SDA and SCK low while you do it, or protect the inputs of the device against overvoltage) like Q2 in Figure 2 would reset the chip. I actually have found that the old style (originally Hitachi) LCD character displays could lock up under certain circumstances and I used this technique effectively to restore operation without requiring a system reset.

Of course it is possible to build the hardware into an integrated design using some form of programmable logic element, but this could impact the economics of the project. Have you ever needed to protect your outputs from freezing, and what techniques did you use?