Mains overvoltage spike synthesizer resets micro in LED lamp..will EEPROM be OK? - Page 1
Forum section: electronics / projects

author: ocset
author_rank: Super Contributor
timestamp: April 06, 2018, 11:35:59 pm
content: 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?

author: Rerouter
author_rank: Super Contributor
timestamp: April 06, 2018, 11:57:51 pm
content: 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,

author: Ian.M
author_rank: Super Contributor
timestamp: April 07, 2018, 06:35:38 am
content: 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.

author: Niklas
author_rank: Frequent Contributor
timestamp: April 07, 2018, 12:56:19 pm
content: 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-complementDefault value if corrupted data is found?

author: ocset
author_rank: Super Contributor
timestamp: April 07, 2018, 02:48:32 pm
content: QuoteThanks, 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?

author: T3sl4co1l
author_rank: Super Contributor
timestamp: April 07, 2018, 03:32:50 pm
content: 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 07, 2018, 03:51:42 pm
content: Quote from: treez on April 07, 2018, 02:48:32 pmSure 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.

author: Ian.M
author_rank: Super Contributor
timestamp: April 07, 2018, 06:30:53 pm
content: 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