Mains overvoltage spike synthesizer resets micro in LED lamp..will EEPROM be OK?

[ocset]

Hello,
We built a mains transient generator, so as to test how our  prototype  150W LED lamps would handle small  mains overvoltage spikes  up to twice mains peak.
The first post of this  thread has the spike generator  circuit attached in pdf….
https://www.eevblog.com/forum/projects/igbt-tail-current-means-it-can_t-switch-off-quickly/msg1336038/#msg1336038
(its just an LC circuit which gets quickly switched into the mains supply  then  switched out again at mains peak, thus it delivers a ~600V spike to the LED lamp)

I programmed    it to deliver a 600V spike every 2 seconds.
The lamps don’t blow up…but the micro inside them resets,       (not always, but most times) and so the lamps keep going off  almost  every time the transient is fired at them…then the lamps come back on, but go off again when the next transient comes…then come back on again.
The versions of LED lamps concerned here have no  AC mains filter. They are linear regulator based. But do have a small 1W  HV Buck bias supply. (this has a CLC  filter just upstream of it)
We find that we can stop the lamps turning on and off by adding Y capacitors from the incoming  Live and Neutral  wires to Earth. Also, adding 100n  of high voltage ceramic capacitance across the HV DC Bus inside the product, significantly downstream of the mains bridge , also stops the on/off’ing.
Also, unhooking the earth connection to the heatsink on which the PCB resides also stops the on/off'ing.
Just adding 100n of x2 capacitance either just before, or just after the mains bridge  does not help.

Another strange point is that while we were doing this test, another similar prototype lamp plugged in 8 metres away in the lab also started going on/off/on in synchrony with the synthesized transient spikes.   

To be honest, if the lamps go off then back on whenever a mains  overvoltage spike occurs, then that may well not be a problem… ..however, if the disturbance somehow corrupts the EEPROM in the microcontroller, then that is not good    …because in this prototype we use EEPROM to store values  so that we can increase the average led current over time, so as to counteract the led’s light degradation with time.

Do you think that there is danger that the micro’s EEPROM may be corrupted by these spikes? –Or perhaps even the program memory could be corrupted? 

 

[BrianHG]

 

[Rerouter]

treez, If your testing a commercial product, have you hooked an oscilloscope up to your micros power rail and reset pin to trace why its resetting, attack that problem first, if that isn't robust to begin with, then outside interference other than what comes through mains could cripple it (e.g. used near a truck stop, flickering everytime someone hits TX on there 10W CB radio)

Once you have the problem resolved, you can look into filtering,

[Ian.M]

Its certainly possible for glitchy power to corrupt a MCU's program memory if it has the capability to write to it at runtime.  Its even possible when your code doesn't contain any routines that write to program memory.    e.g. for many 8 bit PIC MCUs the difference between an EEPROM (data memory) write, and a FLASH (program memory) write is a single bit in a control register.   They use the same 'unlock' sequence with the same magic numbers, so anything that glitches the MCU core badly enough for it to execute an instruction incorrectly or flip a RAM or register bit (rather than simply resetting the MCU) has the potential to brick it by corrupting the firmware.

If your firmware starts a write to EEPROM without a 100% guarantee that the MCU's Vcc rail will stay in an acceptable range for operation for the next N milliseconds, where N is the worst case EEPROM write cycle time, multiplied by the number of bytes that must be written to maintain the stored data in a consistent state,  sooner or later you will get data corruption.   What happens then depends on the amount of redundancy in the stored data and how good your error detection and correction routines are.     A smart designer includes a monitoring  circuit for the supply before the regulator feeding the MCU's Vcc rail to get sufficient advance warning of supply disturbances to avoid commencing write sequences that can't safely be completed, and also uses a power supervisor circuit (on-chip or external) that holds the MCU in reset if Vcc is out of spec rather than letting it crash.

[Niklas]

How do you determine if the data stored in the EEPROM is valid? Just defining 0x00 and 0xFF as invalid might not be enough. There are many ways to do it, but you should at least have some strategy and not rely on a single byte.
Some ideas:
Store the data in multiple, non consecutive, bytes.
Checksum or 2-complement
Default value if corrupted data is found?

[ocset]

If your testing a commercial product, have you hooked an oscilloscope up to your micros power rail and reset pin to trace why its resetting,

Thanks, incidentally, its using PIC16F1947. We declared the MCLR pin is a input pin in the code, but have no capacitor or pullup resistor connected to the MCLR pin.......the only thing connected to MCLR is the trace going off to the programming via....so its juts not connected to anything.  I wonder if this is part of the problem? 

[T3sl4co1l]

Reminder that your "tester" still is not, and never will be, either an IE 61000-4-5 surge, nor a 61000-4-4 fast transient.

Tim

[SiliconWizard]

Thanks, incidentally, its using PIC16F1947. We declared the MCLR pin is a input pin in the code, but have no capacitor or pullup resistor connected to the MCLR pin.......the only thing connected to MCLR is the trace going off to the programming via....so its juts not connected to anything.  I wonder if this is part of the problem? 

Sure is. I wouldn't leave the damn MCLR pin floating. Good lord.
Additionally, it's connected to a trace and via (is there some kind of programming connector or just pads that intended to be used with some pogo pins?), which act as an antenna to make matters worse.

To make the design more robust to external perturbations, what I sometimes do is even to pull-up the MCLR pin with a fairly low resistor value (like 1k) and a capacitor to ground. Since this arrangement may hinder the programming phase, in some cases I put a solder jumper to be able to isolate this from the MCLR pin while programming the MCU. Sounds like some hassle, but it works.

[Ian.M]

If you use a 0.1" pitch programming header following Microchip's standard ICSP pinout, /MCLR is on pin 1 next to Vdd on pin 2 so a simple jumper can be used to tie /MCLR high.   If you are using a non-standard header, bare pads etc. consider a solder pad jumper to tie /MCLR to Vdd