Dead Code Tells No Tales

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