I am using custom built arduino uno for a home automation project. Sometimes, the arduino locks up due to electrical noise or sparks in the ac lines. More details here.
I tried conducting some controlled tests to know more about this where I left the module powered up and tried my best to introduce as much noise as possible by turning on/off switches and turning fan regulator knobs. I also tried to zap the circuit using a gas lighter while the circuit was on. I made a setup which allowed me to make sparks jump on any part of the pcb that I wanted. I did this because I couldn't afford a esd simulating gun.
After all this, I was able to make my microcontroller hang up after torturing it for few minutes and I could repeat the hang up process. Success till this part.
Once my micro controller freezes, sometimes I am able to bring it back to normal process by pulling the reset pin LOW but mostly I can't. It's as if reset pin is not working at all. However I am able to bring it back to normal operation by power cycling it.
(Reset pin works fine otherwise when normal code execution is going on. Reset pin has a pullup and protection diode as recommended by atmega datasheet. Decoupling taken care of. Filter caps very close to power pins. Reset pin going LOW has been verified by an oscilloscope as well.)
Is power cycle reset different as compared to reset pin reset? Is this an expected behavior? Can I do something to ensure my reset pin always works in such conditions?
Best Answer
Yes. There are some semiconductor behaviours where only loss of power will allow previous behaviour to resume. An SCR is a type of component where this behaviour (i.e. only loss of power allows previous state to resume) is normal, and SCR-like structures exist within most ICs.
Depends what you mean by "this". Is it expected behaviour that you can provoke an extreme situation using unknown voltage ESD discharges on a live circuit, where only a power-cycle will recover? Yes
Always, for the conditions of that test? Realistically, no - without extreme measures.
Based on your description, I suspect your ESD injection is triggering latch-up, sometimes called SCR latch-up (or a latch-up like behaviour) inside the MCU. Texas Instruments have a nice app note called Latch-Up, ESD, and Other Phenomena which contains information very relevant to your questions.
I was going to reply to your earlier question which you linked, but too many details were unclear to me, some decisions were based on assumptions that I disagreed with, and experience tells me it's unlikely I can add much in that situation. I also don't believe that your current test is realistic, in the context of your problems described in the previous question.
I respectfully disagree that this is "success". What you have done is to provoke a similar symptom to your earlier question (i.e. MCU locks-up). But there are several possible root causes for that symptom - how do you know that you are triggering the same cause with the ESD gun, as with your device installed in its planned location? There was no evidence in your earlier question of direct ESD sparks onto the live PCB (which is an extreme test) - yet that is what you are now testing.
Therefore I see your current ESD test results as a bit like an XY-problem. You have the original problem with MCU lock-up. You weren't yet able to diagnose that. Now you have now found another way to trigger MCU lock-up (using direct ESD sparks). But that does not mean that direct ESD sparks are the cause of your original problem (therefore I wouldn't call ESD triggering an MCU lock-up a "success") - nor does it mean that any fixes designed to help with ESD protection would help with your original problem either.
I realise this sounds negative, sorry about that. I'm just suggesting that, based on many years experience of troubleshooting complex systems, you are quite likely to be "going down a rat hole" by following your current testing, as it may not help with your original problem.
Personally, if I was in your situation, I would be focussing on better diagnosing the original problem, rather than introducing a new (and, I believe unrealistic) test case. Best of luck!