The vessel has a main battery, used to power it for most of the mission, and a reserve battery that can be used for emergency ma-neuvers.. In general, what this means is that a watchdog
Trang 16.2 Dangerous Exception Conditions and Recovering From Them
In analyzing how to protect a system against entering unknown or illegal states, you will need to create a list of things—voltages, memory variables, and so on—that can
be monitored Of only slightly lesser importance than analyzing the device’s possible failure modes, however, is to decide exactly how to recover from a problem detected
in one of the parameters you’re monitoring A typical analysis would identify the following:
■ The parameter to be monitored For example, this might be an analog voltage (perhaps corresponding to some real-world measurement such as tempera-ture), the state of a variable (a counter, for instance)
■ A range of values for which the parameter is considered within normal oper-ating limits
■ A range of values for which the system behavior should be temporarily
constrained in some way, and a clearly defined recovery methodology For in-stance, if a battery is outside its recommended charge temperature range, the system should not enable charging On the other hand, this is not necessarily
an error; the battery may just have been brought in from a cold environment,
or something of the kind The system should allow some period of time before declaring a fatal error condition
■ A range of values for which the system should be partly or wholly shut down, and the operator (if any) informed of a serious problem
■ Analysis of which system functions can still be provided if a partial shutdown occurs For instance, if your car’s ECM detects engine sensor problems, it can switch into an emergency “limp-home” mode, where it operates with consid-erably reduced fuel efficiency or other undesirable behavior, but it can at least function sufficiently well to get you off the highway
■ An estimate of the time available between an excursion from normal values and a physical system problem (explosion of a battery, for instance!)
■ Preferably, a means to cross-verify that the value being read corresponds to the actual system state
Trang 2■ External interlocks that can clamp related signals or effects automatically if the given parameter goes out of range
E-2 monitors a large amount of environmental information as part of its normal mission profile Some of this information can be used to determine if the system is in danger Most of the danger conditions (for our limited definition of the word “dan-ger,” anyway) occur when the vessel is completely submerged For this reason, the focus in E-2 is on bringing the vehicle to the surface, if possible If that’s not pos-sible, the secondary emphasis is on advertising the vessel’s location so that it can be recovered There is a module dedicated entirely to energy management and vehicle recovery; it has its own independent power supply
Here’s a list of some of the things we monitor and recovery steps we take:
■ The absolute external water pressure, and the differential pressure across the hull The vehicle has an emergency canister of carbon dioxide (connected
to the interior compartment of the boat via a solenoid valve) which can be used to pressurize the hull and expel water If the pressure differential across the hull exceeds rated limits, we add gas pressure to the boat to reduce water leaks If the exterior pressure falls below the interior pressure, we open a sec-ond valve in the keel to release gas pressure This prevents the vehicle from causing injuries when it’s opened at the surface
■ Internal bilge sensors Some water in the bottom of the boat is inevitable, but
if it rises above a certain threshold level, the CO2 cylinder is fired, the keel valve is opened, and the boat is commanded to surface
■ System battery state The vessel has a main battery, used to power it for most
of the mission, and a reserve battery that can be used for emergency ma-neuvers If the control module detects that the main battery is low, it aborts whatever activity is in progress, disconnects nonessential modules (camera, SBC, and so on) from the power bus, and switches to the reserve battery The vehicle is then commanded to surface; dive planes are brought to a mild rising angle, the rudder is straightened, and the motors are commanded to half-speed ahead
Trang 3■ Internal temperature of motors and battery compartment Rising motor tem-perature indicates a friction problem, and can abort the mission Abnormal battery temperatures may affect their ability to deliver charge; again, if things get too far out of range, we abort automatically
■ If the system and reserve batteries are both low, or if no change is detected
in exterior pressure during an emergency surfacing operation, a solenoid is triggered to release a small polystyrene-foam buoy, tethered to the vehicle by fishing line It is hoped that this buoy can reach the surface and indicate the vehicle’s position
■ Once an emergency recovery situation is declared, the recovery module disas-sociates itself from the vehicle’s main power bus and begins transmitting an intermittent acoustic beacon and blinking an array of white LEDs (with a very low duty cycle) The recovery module’s battery is calculated to operate
it in this mode for about 72 hours, which should be long enough to find and recover the vessel
Even the external light level has potential system survivability value, although
in the current design this information is used only to determine whether the vehicle should turn on its exterior lights or not A future version of the E-2 project will include solar cells for long-range missions (primarily, floating about in the middle of a body of water, collecting long-term data—the solar option is not intended to increase travel range significantly)
6.3 On-Chip vs Off-Chip Watchdog Hardware
Most microcontrollers have an on-chip watchdog This is a simple timer circuit that resets the micro if it does not receive some regular signal (referred to as a “kick”) The great thing about on-chip watchdogs is that they are free The downside to them
is that you’re stuck with whatever the manufacturer thought suitable to implement, and this can leave a lot of gaps in your armor against runaway conditions Here are a few common shortcomings of watchdog hardware in general:
Trang 41 Some watchdogs can be manually disabled after they have been explicitly enabled This is a very bad design flaw A good watchdog should be enabled
by a register write or similar operation (once the system has finished power-on initialization), and it should be impossible for software to disable the wachdog
2 Many on-chip watchdogs do not generate external signals when they fire
In general, what this means is that a watchdog bite will usually not cause the microcontroller to drive its reset output network (if it has one) active This can be a blessing or a curse It’s a curse if you want the watchdog bite to lead guaranteeably to a fully-reset system configuration; you have to dedicate an I/O pin to providing a “reset out” signal
3 Some on-chip watchdogs accept uselessly broad kick conditions For
in-stance, they might regard any write to a range of ports as a valid kick It’s better to have a watchdog that requires at least two sequenced writes of spe-cific data to different addresses; that way, you can be sure that a kick is really
a kick, not just a random write through a dangling pointer
4 All watchdogs are useless if used inappropriately Too many embedded
programmers think they have a safe system if the watchdog is enabled and
is being kicked regularly enough to keep the system from resetting In fact, it’s necessary to do some sanity checking before you kick the watchdog This can range from simply kicking the dog once in your main loop (this works quite well in round-robin task schedulers, if you only want to protect against infinite loop conditions) to very sophisticated techniques where you measure the time spent in various different subroutines and compare this against a nominal execution profile—too much time spent in one routine, or timeslice starvation of other routines, will cause a reset In between these two extremes are methods that check the state of a few variables and other parameters for consistency
5 It takes a finite time for the system to restart after a watchdog bite This
is a very serious limitation of practically all watchdog hardware Any safety-critical system needs to have external interlocks to mitigate this problem
Trang 5A common external hardware watchdog technique is the “pulse maintained re-lay” (PMR) E-2 uses this technique in addition to on-chip watchdog hardware The PMR consists of a simple circuit that expects to see an AC voltage on its input This voltage is generated by a pulse train coming out of one of the microcontroller’s I/Os
If the pulse frequency falls outside a certain range, the relay opens for a specified time period, thereby interrupting the circuit’s power and, hopefully, resetting the system
to a known state This is a very idiot-proof method of protecting a circuit against unexplained lockups
You can find some interesting reading on relays in general, and more particularly,
specialized relay circuits of this type, at http://www.ibiblio.org/obp/electricCircuits/Digi-tal/DIGI_5.html An excellent piece of reading on microcontroller watchdogs is Niall Murphy’s “Watchdog Timers” article in Embedded Systems Programming, http:// www.embedded.com/2000/0011/0011feat4.htm.
6.4 Good Power-On Reset Practices
At a rough guesstimate, something like 75% of hobbyist and commercial micro-controller circuits generate their power-on reset (POR) signals using a simple RC network An example of this sort of configuration is shown in Figure 6-1 (this circuit
is correct for an active-low reset signal)
Figure 6-1: Simple POR circuit
_RESET
GND
Vcc
+ C1
Trang 6It is assumed that the capacitor is completely discharged at the moment when the appliance is switched on At power-up, Vcc (theoretically) rises instantly to its nomi-nal value, so the microcontroller should be powered-up immediately The capacitor holds the reset pin low until the current flowing through the resistor has charged it
up to the input pin’s logic high threshold Thus, the length of time the reset signal
is active depends on the time constant RC, the voltage Vcc, and the specified logic threshold value of the microcontroller’s reset input pin
What’s wrong with this configuration? Well, the first thing to consider is that I lied shamelessly to you in the preceding paragraph The active pulse width on the reset signal also depends on the characteristics of the input pin(s) to which the RC network is connected If you connect more than one input pin to a single RC net-work, the overall behavior will deviate further and further from the calculated ideal
On the other hand, if you use a separate RC network for each section of the circuit that requires a power-on reset, you’ll inevitably have different parts of the appliance coming out of reset at different times Thus, an improvement on the circuit in Figure 6-1 would be to run the signal into a buffer (typically a NAND gate, or one or two inverters are used, depending on whatever discrete gates happen to be spare in the circuit being constructed), and to fan out the buffered reset output to whatever parts
of the circuit need a reset signal For example, the following:
Figure 6-2: Slightly refined POR schematic
_RESET 4
″B 2
GND
Vcc
3 1
+ C1
″A
Trang 7The second thing to keep in mind is that the active time isn’t the only important parameter on the reset signal All logic inputs have a maximum rise/fall-time speci-fication, which you’ll find in the device’s datasheet Recall that the V/t charge curve for a capacitor is exponential in nature; it rises very quickly from zero, but flattens off and, in theoretical terms, will never actually reach Vcc What this means is that depending on the specific values of your resistor and capacitor, it’s possible that the micro may see an abnormally slow risetime around the logic threshold voltage This situation is exacerbated by the fact that the power rail itself exhibits less-than-ideal behavior Some local slumping can be expected, particularly since at power-on and during brownouts, the supply rail is heavily loaded by the need to charge up all the bypass capacitors on the board In practical terms, then, it’s best to choose C to be large and R to be small, so that when the voltage crosses the critical logic threshold, the capacitor is still in the steep early regions of its charge curve—even if Vcc is ac-tually a bit lower than its nominal value A slightly more complete solution is to use
a buffer with Schmitt trigger inputs This will ensure that the logic level presented to the microcontroller is always a clean state
One partial workaround for these shortcomings—and I must admit that I’ve been guilty of perpetrating this in commercially fielded products—is to wire the product’s power switch so that, in the “off” position, it shorts out Vcc to ground This helps the situation in normal-usage circumstances because it ensures that the POR capaci-tor is fully discharged very shortly after the power is turned off The inadequacy of this workaround lies in the fact that not all potential power failures are caused by a user flipping the power switch on the device Temporary interruptions (blackouts) or slumps (brownouts) in the mains supply voltage can, for mains-powered appliances, simulate a power-on condition without anyone ever touching the power switch If these interruptions are short, the capacitor in our reset network won’t have time to discharge fully, and it will consequently charge up over the logic threshold faster than we expect In a worst-case scenario, a brief brownout or blackout will lower Vcc below the micro’s operating threshold, but won’t allow the capacitor to discharge far enough to generate a proper reset pulse when power is restored Pretty much any-thing could be happening to the micro in this scenario; it could be running normally (albeit with no I/Os because of a depressed I/O ring voltage), it could be frozen, it might be executing out of unimplemented ROM space, or it might have reached
Trang 8some undefined internal state where it can’t execute any code at all until it receives
an external reset signal
A carefully-structured POR circuit is, therefore, integral with a brown-out detec-tor It should assert the reset signal when power is applied to the system Ideally, reset should be asserted before the microcontroller is powered up, and the POR circuit should hold the signal active until the power rail is at a nominal value Furthermore, our mythical POR circuit should detect brownout conditions on the power rail, and should supply a clean, known-width reset pulse if such a condition occurs
Fortu-nately, we don’t need to design a chip to do this Maxim, for example (http://www maxim-ic.com/), sells several appropriate devices, and they’re very cheap E-2 uses
these integrated power-on-reset generators/brownout detectors extensively
6.5 A Few Additional Considerations for Battery-Powered Applications
Battery-powered appliances, in the main, need to exercise particular care over how they detect and handle hardware exception conditions Special rules apply to er-ror recovery, because it’s possible that you might not have enough life left to get all the way through a recovery algorithm When exceptions occur in a battery-powered device, your first priority should be to get the system into a state where it will be safe
if the microcontroller goes completely offline Systems operating off battery power constantly live under the Sword of Damocles; they scurry nervously from one safe state to the next, with as little time as possible spent in between In E-2’s case, the most worrying time for us is when the keel valve is open for any reason; it’s latched,
to save power, and we might not have enough energy to close it again
Another consideration which affects most devices that use rechargeable batteries,
is that these batteries will typically be damaged if they are discharged below a certain cell voltage It is normal, in such circuits, to set up a low-battery warning that gives the system a known grace period to shut down, and then for the microcontroller or
an external power supply circuit to shut the system down explicitly when a critical battery level is reached Not only does this protect your batteries against over-dis-charge, it also allows the system to shut down important systems gently and elegantly Note that one potential problem with this system occurs if the user powers off the device, then switches it back on once the batteries have had time to accumulate a surface charge These batteries are already further down their discharge curve than
Trang 9they appear (from simple voltage measurements) The unit may not have as much time as it thinks between “low battery” and actual death The best way to mitigate this problem is by including a gas gauge function in the battery itself, so that the unit cannot be powered up again until the battery is swapped out or charged Cellphones and laptops frequently implement this sort of system
And finally, while we’re talking about battery-powered appliances, you should be particularly careful about implementing charge controller features (for rechargeable batteries) entirely in software If you do use a microcontroller to perform charge con-trol, the code must be rigorously designed and carefully debugged—and you should have an external hardware interlock as well (thermal fuses to protect against over-temperature, regular fuses to protect against overcurrent, and so on)
Trang 10Contents of the Enclosed CD-ROM
7
C H A P T E R
envi-ronment for Windows.
/linux/busybox-0.60.5.tar.gz
The Busybox utility package for Linux.
Linux kernel
Geode-based SBC.
Sample programs
for Linux
/linux/sample-programs.
tar.gz
Contains entire source tree for all sample Linux programs mentioned in this text Sample hardware
project schematics
described in this book These are all in EAGLE format
EAGLE libraries for
hardware projects
in the standard EAGLE libraries.
Sample root
filesystem for
CompactFlash or
CD-ROM boot
/card-root.tar.gz /cdrom-root.tar.gz
A complete root filesystem as created by the steps described in Sections 4-4 and 4-5.
/linux/svgalib-1.4.3-patched.tar.gz
The SVGAlib graphics library sourcecode The -patched archive has been patched to build correctly with gcc 3.x.