Ed is an EE, PE, and author in Poughkeepsie, New York. You can contact him at [email protected].
Once upon a time, I wrote the firmware for a series of networked microcontrollers used by dedicated homebrew tinkers for home control. One type of network node could send commands to X10 remote-control power switches, thus providing program control over line-powered gizmos. This was before the days of embedded TCP/IP stacks (heck, it predated the Internet frenzy), so we cooked up a customized ASCII (!) network protocol that did exactly what we needed.
Everything worked quite well and the customers were happy, except that, once in a while, an X10 interface node would lock up. The Send LED blinked, so it appeared to be transmitting X10 commands over the power line; and if one waited long enough, it would recover and resume normal operation as if nothing had happened. Sometimes, "long enough" meant hours.
User error, as always, contributed to the problem. It was entirely possible to write a home-control program that ruthlessly hosed the X10 node with commands. The node would dutifully transmit those commands, but the X10 data rate works out to one command per second, the outgoing queue had 254 slots, and each slot could be repeated 255 times. Yes, the queue could take 18 hours, more or less, to drain. Oops.
Some customers were adamant that they couldn't possibly have made such a silly mistake, but when gently persuaded to examine their code, we didn't hear from most of them again. Sound familiar?
A few, however, offered convincing proof that their code wasn't at fault. After some rather protracted debugging and analysis (because, of course, we couldn't reproduce the problem on the bench), we decided that this one really was a hardware problem. To understand what happened, let's talk about power.
From OFF to ON
Although we think of the main CPU as being in control of our familiar desktop and server systems, the truth is more complex. During the first moments after flipping the Big Red Switch from OFF to ON, the power supply monitors its own outputs and holds a Reset line active while all the voltages stabilize. Until Reset goes inactive, the CPU and its supporting digital circuitry remain in stasis.
Systems with multiple supply voltages generally require a specific turn-on sequence so that the semiconductor junctions inside the chips aren't exposed to reversed voltages. Even single-supply systems must not start up before their power stabilizes because chips don't function correctly with out-of-spec voltages.
Commodity PC systems must solve an additional chicken-and-egg dilemma during those first few hundred milliseconds. The main power supply—the one plugged into the wall outlet—provides what's called "bulk DC" at a few standard voltages, but the CPU itself requires tightly regulated voltages that depend on the exact chip configuration.
Early Pentium-class system boards matched the supply voltages to the CPU chip using DIP switches or jumpers. When you installed the CPU, you either set those things correctly or fried a few hundred dollars worth of silicon. Gamers and overclockers could easily explore the multidimensional relationships between clock speed, supply voltage, cooling effectiveness, system stability, and CPU lifetime.
More recent CPU packages sport a handful of pins that select the proper voltages without user intervention, tech support, or risk of incineration by overvoltage. That voltage selection circuitry requires yet another power supply that must be active before the tightly regulated voltages appear. In effect, the CPU sets its own supply voltage before it wakes up.
And you thought snapping the Big Red Switch just turned on the juice!
From ON to OFF
A similar dance with death occurs at the end of the day. By now we're all conditioned to turn our systems off by clicking on a Start button, K gear, Gnome foot, or Aqua lozenge rather than just poking the Big Red Switch. Laptops generally link their power switch to a software shutdown sequence and some keyboards feature Sleep or Shutdown keys, but you don't want to try the Main Switch on the front of a desktop machine without being pretty sure it'll trigger a soft shutdown rather than a hard stop.
Modern operating systems keep so many balls in the air that simply turning off their power without warning can irretrievably scramble their file systems. The process of closing applications, writing data from RAM to disk, clearing caches, and ensuring that all is well can take tens of seconds, so it's best done under control of the OS itself.
As a final step, the operating system can tell the PC hardware to turn itself off. That's mediated through the ACPI machinery, which passes control from the OS to the BIOS, which can then fully turn off the power supply. In effect, the Power button now requests services rather than actually switching the juice.
New users generally expect that the system will actually do something visible immediately after clicking Shut Down, but a blinking hard drive LED doesn't seem to count. I know several folks, not all of them newbies, who simply give up and stab the power button after a few seconds. The common "fails to shut down" Windows annoyance doesn't help matters in the least.
Although a deeply embedded system may have a power switch, it's usually turned ON during installation and left there forever. The only downtime occurs during power outages, after an uninterruptable power supply's batteries go flat or a generator's fuel tank runs dry.
In short, both starting up and shutting down must be done with the greatest of care. What happens in between requires some attention, too, particularly in systems with no user interface at all.
Power by the Numbers
If you've ever found yourself sitting in a suddenly quiet room in front of a dark monitor, you understand why hardware designers must care about power supplies. Riding out a momentary power loss is one thing, but keeping a system alive long enough to go through an elaborate shutdown ritual is quite another.
Those old water-cooled mainframes solved the problem with a motor-generator set sporting a hulking flywheel that provided enough rotational inertia to keep the system alive until the auxiliary generators spun up. The total run time was then limited by the fuel tank capacity, an essentially limitless quantity.
Embedded systems generally don't have the luxury of guaranteed power and must make do with much simpler hardware. If the hardware can warn the software that the power has failed, the OS (or whatever software is involved) can save data and perform an orderly shutdown. The key is getting enough warning to finish the job.
The maximum time required for an orderly shutdown and the system's maximum power consumption determines the amount of energy that must be stored in the power supply. Both hardware and software contribute to the final answer in equal measure, but software has the advantage of not adding to the product's recurring cost, which may mean you get to solve the problem on your own.
For example, a standalone desktop PC may use 100 watts (excluding the monitor) and take 20 seconds to shut down. When the AC power goes off, the power supply must provide 100 W entirely from internally stored energy for the entire duration of the shutdown. The monitor will go dark during this operation, but if the shutdown proceeds automatically you won't lose anything but your composure.
The total energy stored in a capacitor, the only long-term energy storage device you'll find in a power supply, is
E = 1/2 CV2
with the energy E measured in joules, the capacitance C in farads, and the voltage in volts. Conveniently enough, 1 joule equals 1 watt-second.
Delivering 100 watts for 20 seconds requires 2000 watt-seconds or 2 kilojoules (KJ) of energy. Assuming that the power supply must hold its output voltages within 10 percent of their nominal values, the total stored power can drop by 20 percent. Therefore, if you need 2 KJ the power supply must store 10 KJ, at least to a first approximation.
Figure 1 shows the innards of a mildly obsolete desktop PC's 145-W power supply. The pair of black cans in the foreground are 4700 mF 470 V capacitors, a total of less than 0.01 farad. The smaller cans, barely visible behind the heatsink, are individual capacitors for the low-voltage regulated outputs that, because stored energy varies as the square of the voltage, don't pack much additional energy.
Despite their 470-V rating, the typical operating voltage will be somewhat less to allow for tolerances and line voltage fluctuations. At 350 V, those capacitors store 600 J and can provide 100 W for a second with a 10 percent voltage drop. This power supply was designed to handle relatively brief outages, a reasonable design point for a noncritical desktop PC.
Capacitance being roughly proportional to volume for a given capacitor technology, achieving a 20-second run time would require capacitors 20 times larger—about half the size of the entire power supply case. What that would do to the PC's price and sales is left as an exercise for the reader. Hint: It's hard to market invisible surplus capacity in a consumer product.
To be useful in an embedded system, the power supply must produce a digital signal that indicates the system will soon shut down. That signal probably shouldn't occur immediately after the AC line blinks off, as the supply can ride out short outages, but must occur before the supply's stored energy falls below the minimum required to support an orderly shutdown.
Unfortunately, while standard PC power supplies include a "Power Good" signal indicating when the voltages are within specs, they don't inform the system that trouble lies ahead. If you want a system that can shut down automatically, it must receive a warning from outside. That's just one reason uninterruptable power supplies now come with a serial or USB connection to the PC.
ON to OFF to ON
All that is well and good for systems that can afford a real power supply with all the trimmings. Given the preponderance of single-chip microcontrollers over PCs, though, it should come as no surprise that, for most systems, a wall wart is about as good as it gets.
That X10 interface node used a wall wart to get 12-V DC, from which a linear regulator produced 5 volts for the TTL logic and Intel 8032 microcontroller. This was before the days of cheap-and-easy switching regulators, so burning 7/12 of the total power in the regulator was the only way to go. One advantage of that simplicity was that you could use nearly any bulk DC source, including various batteries, without tweaking the regulator.
We noticed that users with battery backup installed near the X10 node tended to have few problems. That suggested the microcontrollers were crashing due to power supply glitches, a suspicion confirmed when I suggested installing a voltage-monitoring reset circuit similar to the Maxim MAX6803 (which is currently in production, unlike my original choice). Providing both a backup battery and a reset circuit eliminated the remaining problems.
The Intel 8032 microcontroller, a classic that dates back to 1980, has many peculiarities including an high-active RESET input with an internal pull-down resistor. The canonical reset circuit uses a 10-mF capacitor connected to the regulated supply voltage. As the power supply voltage increases after turn-on, the capacitor pulls the Reset pin high and holds it there while the voltage stabilizes.
That simple approach has two problems. First, if the supply voltage increases slowly enough, the Reset input won't be held high and the microcontroller will start up with an out-of-spec supply voltage. Second, after the supply stabilizes, a positive-going glitch can reset the 8032.
As it turned out, we had a particularly nasty variation of the latter problem. The 8032's specs said that the Reset input must be held high for at least 2 ms to reset the system. Shorter pulses would undoubtedly do something, but the specs were conspicuously silent on what that might be.
A short glitch, either positive or negative, could pass through the power supply and garble the system with a partial reset. Positive glitches were the easiest to understand, as they raise the voltage at the Reset input through the 10 mF capacitor. Negative glitches would have a harder time getting through, but would be more likely to cause very brief pulses on the power-supply voltage and Reset inputs, with a higher likelihood of a partial reset.
The reset circuit we added isolated the Reset pin from power-supply glitches, ensured a clean start-up, and asserted Reset when the supply voltage fell below the lower limit. It didn't give any advance warning of a pending blackout, but the X10 node didn't require that feature.
In any event, we found a satisfactory solution for the tech-savvy customers of this particular gizmo, the sort of folks who didn't mind a little hardware hacking. Had the system been inside a sealed consumer box, though, the lack of a good reset probably would have killed the product.
Your system will probably be more complex and require a correspondingly more capable power monitor. The MAX6441, for example, provides several levels of voltage warning in addition to controlling the microcontroller's Reset signal. Perhaps you'll need something different, but make sure the hardware can supply the signals you need to protect the system's data.
Just like your parents warned you, don't play with power!
Contact Release
Even in hindsight, cooking up that custom network protocol was a good idea. We didn't realize at the time that the checksum must appear at the end of the data packets, because some tiny microcontrollers can't store a whole packet in memory at once: With only 128 bytes of RAM, you can't compute the checksum on a 200-byte packet!
Power-supply design is far more complex than you might imagine from my cavalier first-order approximations. Maxim/Dallas provides power monitors at http://www.maxim-ic.com/MaximProducts/ uPSupervisors/voltage-detectors.htm. Other companies have other, equally interesting, gizmos, so you can probably find just what you're looking for.
On another note, if you leave your desktop systems on all the time, why not let them do something useful when you're not? Try folding proteins at http://www.stanford.edu/group/pandegroup/folding/, finding Mersenne primes at http://www.mersenne.org/, or searching for aliens at http://setiathome.ssl.berkeley.edu/index.html. Be careful what you download, as the more obvious and easily typed URLs belong to spammers, casinos, or porners.
DDJ
