How we froze our Software!

Kim Pries and Jon Quigley

August 13, 2008

Kim Pries and Jon QuigleyAugust 13, 2008

The last time we froze our software, things became really cold around the office. We were producing an embedded product with a liquid crystal diode (LCD) display that was supposed to show the positions of the automatic transmission - the so-called prindle (PRNDL).

We took our sample part and dropped the temperature to -40o C. (or F.) in a test chamber with the unit powered. Once we stabilized the part thermally, we observed that it took approximately six seconds for the display to change when shifting simulated gears.

This situation violates a U.S. Department of Transportation Federal Motor Vehicle Safety Standard (FMVSS) requirement for prompt display of information.

Yes, we agree that it wasn't really the software that suffered from a chill but, in the world of embedded software development, the requirements and hardware behavior are never very remote.

The term "firmware" captures the essence of embedded software by implying the hardware and software are mixed indissolubly as an integrated solution to a product requirement. Considering these hardware failure impacts on the software in advance is key in securing a robust system in the field.

We have tested automotive embedded software under environmental conditions as varied as some of the following:

1) Emiting electromagnetic radiation, where we can fry the brains of the micro-controller;

2) Vibrating the sample, where oscillator or clock chips may assume erratic behavior, particularly if they contact the product;

3) Raising or lowering the temperature into regions where components no longer behave as expected;

4) Loading the data bus at high intensity so buffer memories become saturated and dysfunctional;

5) Introducing electronic noise with wholly unexpected results;

6) Pulsing the system with voltage transients or `brown outs," lower then expected input voltages;

7) Latching the CMOS at voltage boundaries;

8) Cycling EEPROM or flash memory with writes that are not protected against error; and

9) Inducing code drift through an inadequate watch dog timer (over-reliance on the microprocessor integrated watchdog timer).

< Previous
Page 1 of 3
Next >

Loading comments...