Page 208 - Embedded Microprocessor Systems Real World Design

System Integration and Debug 7

After the hardware PC board or a handwired prototype is built and the software
compiles with no errors, it is time to plug in everything and watch the system come
to life. Fifteen minutes after initial power-up and flawless operation, the hardware
and software engineers knock off early for the day.
Well, not really. The actual scenario usually goes more like this: If smoke does
not roll out when power is first applied, the engineers quickly discover that
absolutely nothing works. After a brief argument in which the hardware engineer
accuses the software engineer of forgetting to initialize the stack, a logic analyzer
or emulator is connected. Investigation reveals that the PROM or the RAM or some-
thing else appears to be completely dead. The software engineer goes to lunch,
smug in the assurance that it is a hardware problem.
After the hardware engineer fixes the chip select that had two devices enabled
at the same time or the wiring error that had the data bus reversed end for end,
debugging resumes. When the next problem stops all work, it turns out that an
interrupt vector is in the wrong place or the internal processor peripheral area is
uninitialized, and the hardware guy leaves early while the software engineer works
until 8 p.m. to fix it.
This process repeats for the next four weeks as the project stumbles its way to com-
pletion. Two weeks after the design team breathes a sigh of relief and hands it off to
the beta test customer, a bug is reported. The error occurs only under certain con-
ditions and not every time at that. If the design team is lucky, it can reproduce it in
the lab and work on it there. Otherwise, another argument ensues as to who has to
take a midnight flight out to the beta site to fix it-hardware, software, or both?
While the utopian fantasy I first described is rare, the nightmare scenario need
not be the only alternative.
Like the design part of a project, the test and integration part works best if there
is a goal-a plan. Many large companies have formal test plan requirements that
detail every test to be performed. These range from functional tests to safety agency
approval tests to tests involving shock, vibration, and temperature (called by some
shake and bake).

189