Seen in
ShipWithAssertionsOn.
An interesting expression of a concept I've tried to
bring up in developing systems with at least a minimal
ability to leave some kind of
TrailOfBreadcrumbs to
allow the
SoftwareMedicalExaminer to perform a useful
SoftwarePostMortem.
In embedded systems there are often no disk drives or
other storage media and no user interface interface.
If it dies, and no one is there to see it your forensic
abilities are really tested.
I've worked with computers that had a ROM monitor that
allowed you to stop everything, examine or trace areas
of RAM, and resume or restart. Nowadays such toys are
available only to hard core development & diagnostic
shops, not to mere mortal users.
In our recent systems (embedded and otherwise) we have
added the $0.89 parts and taken the development time to
give the forensics guys a head start -- saving state to
NovRam (
NonVolatileRam) or
FlashMemory when impending
turd/fan collisions are detected -- or writing to disk
when there is one.
Unfortuantely, $.89 buys you very little of FLASH or NVRAM--at best, one of those EyeSquaredCee serial thingies that can store a couple of kilobytes. Which may or may not be enough for such post-mortem diagnostics.
Another good strategy (assuming fiberglass real estate is not at a premium) is to design in a (larger, more expensive) diagnostic memory and delete it from the design (leave the pads on the ECB but don't install the parts) when you go to production. Assuming, of course, that you won't need to do such troubleshooting in the field. (And for many consumer items, you won't)
Once the program is deceased, especially in the hands of
user site personnel, the only clues you have are the ones
you left yourself.
--
GarryHamilton