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.
Comments