EC-9.7 Power, Debugging and Reliability on a Real Board

What this is and why it exists

This is what separates something that works on a bench from something that runs for a year on a battery in a place nobody visits.

It is last in the module because every technique here needs the earlier material. It is also the topic the board practice modules quietly assume whenever they mention debugging.

The theme running through it is that the hardest embedded failures do not look like hardware failures. They look like software behaving randomly, and the cause is electrical.

The vocabulary

• Sleep mode — a low-power state in which parts of the chip are stopped.
• Wake source — the event permitted to bring the part out of sleep.
• Average current — the current that actually decides battery life.
• Debug port — a small interface allowing a host to halt and inspect the processor.
• Breakpoint — a marker causing the processor to stop at a chosen instruction.
• Watchdog — a timer that resets the part unless the program keeps clearing it.
• Brown-out — a supply dip too small to reset the part but large enough to corrupt it.
• Decoupling capacitor — a small capacitor near a chip supplying sudden current demands.

The mental model

Sleep first, because it is where battery life comes from. A part typically offers several depths of sleep, each keeping a different set of peripherals and memories alive. Shallow sleep stops the processor and keeps everything else; deep sleep keeps almost nothing and may lose the contents of memory.

Two design questions follow. Which source is allowed to wake it, and how long does waking take? A part that wakes on a timer and a pin, in ten microseconds, is one design problem. A part that takes ten milliseconds and must restore its state from scratch is another.

Average current is what decides battery life, and it is dominated by the short awake periods rather than by the sleeping figure. A part drawing one microamp asleep and twenty milliamps awake, awake for one per cent of the time, averages about two hundred microamps. The sleeping figure on the front page had almost nothing to do with the answer.

Measuring it honestly is harder than it sounds, because the current changes by a factor of ten thousand within milliseconds. An ordinary meter averages over its own interval and hides the peaks entirely. This is a case where the measurement module's warnings apply directly.

Debugging is the next tool and the difference it makes is large. A debug port lets a host halt the processor, read and write memory, and set breakpoints in flash. It costs two pins.

The difference between reasoning about what happened and looking at it is worth those two pins on almost every design. Leaving the pads on a production board, even without a connector fitted, is a decision people are grateful for later.

There is a limit, though, and it is important. Halting the processor does not halt the world. A motor keeps turning, a communication partner times out, a capacitor discharges. Some faults cannot be found by stopping, and that is where the next technique comes in.

Toggling a spare pin at the start and end of a section, and watching it on an oscilloscope, measures timing without changing it. It costs one pin and a few instructions.

Printing over a serial line does the opposite: it takes milliseconds and changes exactly the timing you were trying to measure. A fault that disappears when you add a print statement is a timing fault. The pin-and-oscilloscope method is how you look at it without disturbing it.

The watchdog is a safety net and it is often installed badly. A counter runs, and if the program does not clear it in time, the part resets. That turns a hang into a restart, which is usually the right outcome in a product nobody can reach.

The way to install it badly is to clear it from a timer interrupt. The interrupt keeps running when the main program has stopped, so the watchdog is fed by a system that is no longer working. Clear it from a place that only runs when the real work is progressing. Record the fact that a reset happened, so the failure is visible rather than hidden.

Finally the electrical failures, which is where this topic earns its place. A supply that dips when a motor starts can corrupt memory or half-reset the part. The symptom is software misbehaving at random, in a way that moves when you change unrelated code.

Two measures address the cause. Decoupling capacitors close to each supply pin provide the sudden current the chip demands, so the supply does not dip in the first place. Brown-out detection holds the part in reset while the supply is below a threshold. A marginal supply then produces a clean reset rather than corrupt behaviour.

Neither is exotic and both are omitted constantly. A board may behave differently on a bench supply and on a battery, or work until a relay switches. This is the first place to look.

What you should now be able to explain or do

• Choose a sleep depth and a wake source for a given duty cycle, and account for wake-up time.
• Calculate average current from an awake current, a sleeping current and a duty cycle.
• Use a debug port for what it is good at, and say what class of fault it cannot find.
• Measure the duration of a code section without altering its timing.
• Install a watchdog so that it catches a hang instead of hiding one.
• Recognise the failures caused by supply dips, and name the two measures that prevent them.

Check yourself