For the detector, that's easy enough; an RF detector (little more than a wire in a likely location, inductor, coupling capacitors, schottky diodes..) and maybe a pulse stretcher will make it readable by MCU.
Maybe even simpler than that, like -- put the antenna wire on the MCU pin directly, attach a pin change interrupt, and let it cook. Likely either the induced latchup crashes the device, or the rapid-fire series of interrupts overflows the stack, to the same end.
Mind that, if the pin structures latch up, a soft reset won't fix it, it needs to be power cycled; using a LDO with a fairly tight current limit may be useful here (e.g. a 50-100mA limit so that the MCU's ballpark >100mA latchup causes itself to brown out and clear the latchup).
Mind, these aren't at all reliable methods, there's no guarantee that your detector fires from the same stimulus that knocks out the LCD.
As for mitigation:
If this is a plastic enclosure, there's still plenty that can be done to improve immunity. The display itself can be screened (use a window with an extremely fine mesh covering, or ITO coating), though at notable expense to visibility. If the display has metal brackets/bezel/mounts, ground them. Construct a metallic shell around, and/or including, the PCBs, so that ESD washes over them, preventing induced fields in wires, traces, etc. The enclosure can be lined with foil or formed sheetmetal, or painted with conductive paint; PCBs can be designed with internal ground planes (or stitched outer layers, doing about as good a job for 2-layer builds, when you don't need the extra density of a 4+ layer build).
The shield must be reasonably solid; ESD easily passes through gaps/slots of 5cm+ length. So, EMI springs, screws, whatever kind of contact points, should be at least as frequent.
And yeah, if it's the LCD driver latching up altogether, you really don't have much recourse but power cycling. Maybe the failure is apparent on the interface (reads are corrupt -- if your panel has a read function at all).
And you don't have to do the full reset cycle, it may do just to reset the config registers (e.g. screen size, orientation, etc. -- this would address the above-mentioned flip symptom, presumably), and try to avoid chain-writing the screen forever, do a location reset every so often so the pixel position doesn't get out of sync.
A common symptom is extra clocks, for any kind of interface really, but especially SPI being clock sequential. If you're doing continuous pixel updates, just copying from an internal frame buffer -- it can easily get off by a pixel here or there. Just resetting the frame every time, isn't a bad idea.
3. Because there is an LCD, it's likely you have user-interface buttons. Instead of a timing-based reset cycle, run the reset cycle when a combination is hit. I used the "Clear" or "Enter" buttons being hit 3 or 4 times in a row.
Gotta say, this is a surprisingly intuitive solution. Like, "alright fine, we expected this might happen, so here's a freebie for you", *mashes button* and there you go. Like, you might not even need to put that in the manual for users to discover it.
Tim
Home
Help
Search
Login
Register
