My last blog was about eliminating throw away code during
product debug. Often, the designer faces even more critical issues during
circuit board bring-up. In fact, it’s something of a catch-22 where hardware
requires bare metal software and bare metal software requires functioning
hardware.
Then, to compound the problem, once both are complete and the board still
won’t boot, the question becomes: whose fault is it, hardware or software? One
technique that can help get you past this dilemma and avoid the finger pointing
is using sufficient run control tools and CPU cache as boot RAM.
In many instances, the hardware designer’s dilemma is this:
even if he or she writes throw away code to initialize onboard devices and kick
start board bring up, when the board won’t boot, he still doesn’t really know whether
the cause is faults on the path to the memory controller, in the memory
controller itself, on the path to the DIMMS or whether the DIMM configuration
information is working properly? Or, to dig a little deeper, since the boot code
could be targeted as resident in flash, he doesn’t really know that the path to
flash or that the content of flash is good? Designers can make lots of
assumptions, but this is where they can get in trouble and end up
unintentionally adding delays to a product’s introduction. With the right tools
and a judicious use of cache-as-RAM techniques, we can address these sometimes
time consuming problems of dealing with DDR RAM.
To help you understand these issues and offer some solutions,
we’ve put together a new e-book, “Cache-as-RAM for board bring-up of non-booting circuit
boards”. It might get you past your next catch-22.
