People working with "locking" tends to write code looking like:

unlock_memory();
write_changed_data();
lock_memory();

A program that jumps to a random location, because of some ESD glitch or similar, is quite likely to run this three-step procedure, whatever complexity you have for the lock/unlock code.

Whenever the code has logic to unlock the memory, stray execution may locate this chain of events.


Your regular question. Apply an ESD gun to your product, and it will not matter how thorougly your code is debugged. No memory access can be trusted when enough voltage or magnetic fields are applied to a circuit. And no, shielding will not solve the problem. Just change the amount of energy it takes until your product may suffer a hickup.

Same thing if one of your components isn't as good as you thought. The factory test may have accepted the unit, without being able to find that this specific unit will not work well for the full temperature range it was expected to support. Testing your prototypes is not the same as knowing that 100.000% of produced units will be at least as good as the prototypes.

Another thing. Your new device may be excellent. 10-15 years later, a unit running in high temperatures will suffer a lot of ageing of all components. Capacitors may have lost a lot of capacity, making the unit more sensitive in case of glitches on supply voltages or input/output signals.

It is foolish to decide that there isn't a need for a safety belt as long as code or electronics are tested. Good code should still be written in a robust way, so that it either resets or auto-repairs when possible.

A student may strive to write "correct" code. An experienced engineer should not stop there, but try to write robust code.