What causing IC firmware corrupted?

Question

What actually causing IC firmware program corrupted? Power Surge is the best answer given by most people. What others reason causing it? Please advice, thanks

Answer 1

Firmware, by definition, ("firm") is stored on ROM and cannot be corrupted, unless it is destroyed by excess voltage, like a power surge, or temperature.

Surges usually are caused by inductors being turned off, either motors, or solenoids, or relays.

Solenoids or relays can (should) have reverse diodes across their coils, which will remove the surges.

Answer 2

Reasons other than power surge:

Low voltage and not having brown out detection enabled on your uC. This can be an issue if the brownout ocurrs when data is being written to EEPROM or program memory in the uC.  

After that I can think of lots of ways poorly designed and insufficiently tested firmware can cause problems. Depending on the code and at what point in development your talking about.  Firmware in development certainly can have buggy code that could cause  corruption especially if pointer values are inadvertantly over written.  I would hope to not have this issue with a well developed and tested product.

Some micros like the Atmel AVR's have commands to read and write data to program memory.  It is possible to allow a uC to read and/or write a section of program code dynamically.   For example reading a Lookup table stored in program memory, or allowing the firmware to modify itself and move code from EEPROM into program memory.  

Memory Read Write cycles are limited  flash ram has a 10K cycle limit. While EEPROM has a 100K cycle limit. After these limits are exceeded there is no guarrantee that all bits in the byte will be correctly stored.   (One or more bits could latch high for example). Again this goes back to the program and testing of the product.   10K and 100K may sound like a lot of cycles but not if data is frequently being written to for variable storage several times a second by the firmware.   Exceeding the write cycle limit can happen when the programmer has reserved the SRAM entirely for stack usage and then uses program or EEPROM memory for variable storage.

Excessive pushing of data onto the stack which then stomps on  data stored at the other end of the SRAM.   Suppose that an analog input to the ADC of the uC exceeds an expected design range and triggers excessive subroutine calls.   This again also points to poor firmware design that doesn't include code to handle exceptions.      

Pointer Overflows that go undetected can cause memory write functions to stomp over data located in area not intended to be rewritten.

The use of registers as global variables which share a register address with a variable used in an infrequently called function.   The corruption could also be benign 99.9% of the time.   For example an adress stored in a register gets cleared to 0x00 when a timer function is called.    The result is that the program starts over at adress 0x00 in essence rebooting and not causing much of a problem. The exception could ocurr if the timer has a conditional that is rarely met which aborts the count before reaching zero.  The corrupted adress returned would be something other than zero and that would be a problem in this example as the program execution would jump to some other random point. Especially if that point is a code section that writes data to program memory and is triggered with out a properly initialized pointer value.