It’s all about time management in product development.
Nowhere is time management more critical than during board bring-up, when the
bare metal software needs to be integrated with the new hardware platform. The
problem is a chicken-or-egg issue. You need the hardware to develop the
software. To have functioning hardware, you need some bare-metal software. What
happens then?
Some organizations begin the firmware development using the
schematics and technical reference manuals (TRMs) in an effort to bridge this
development gap. The problem is that an error in the schematic or TRM leads to
an error in the code. There is no way to know about the error until the code is
integrated with the hardware. The manifestation of the error may not be readily
apparent to the hardware problem.
Most organizations have the hardware designer write some
code to address device initialization and facilitate board bring-up. This is
often an activity that was not necessarily planned but a necessary activity to
“wring out the design”. It is an exciting time for the designer as they bring
their creation to life but often with lots of personal sacrifices, trials and
tribulation – in short painful.
With today’s devices, particularly SOC’s, having hundreds of
registers and TRMs that exceed thousands of pages, hardware designers are
pressed to get the board(s) functional so the other departments (software,
systems, and test) can all have their own resource. So the code development is
done as quickly as possible often lacking the formal software structure seen in
the software side of the house. Thus this code is often thought of and treated
as throw-away code. Once an operational prototype is running the board is
quickly dispatched to the firmware team to get “the real code” running. This
problem has become so prevalent that some silicon suppliers are providing tools
to assist the hardware designer in device configuration. These tools also
support code generation. The code generation from these tools is often looked
upon skeptically, after all the code was “not invented here”.
This throw-away code development, a necessary evil, is
obviously a resource drain and often takes longer to develop than planned. The
problem can be a lack of tools or just the typical debug process of edit,
compile, flash, and debug. What is needed are tools
that provide an interactive session with the target, usually through some run
control or emulator, so the designer can peek/poke at registers, IO and memory.
Most of the device initialization within a software code structure involves
reads and writes to registers. Why not do it interactively
so you have an immediate response from the target. Then from this interactive
session, once complete, create a script to do the same initialization so it can
be automated and done repetitively. This script then becomes an integral part
of the life cycle of the target. The script can be used in test and can be used
as a hardware check-out when the firmware developer finds a “hardware bug”. The
scripting then eliminates the “throw-away” code and provides a defined process
for board bring-up and more rapid enablement for bare-metal software
development.
Learn about interactive sofware, ScanWorks Platform for Embedded Test – Processor-Controlled Test, to help designers peek/poke at registers, IO and memory.
