LPC1788 reflash required after RFI exposure

[dstadille]

Hello,

Our LPC1788FBD208 -based product hangs and requires complete re-flash after heavy RFI exposure.  There's probably nothing inherently wrong with the LPC, and of course, RFI problems can be tricky to identify and solve. But I wonder if there are a few known failure modes - for example, odd things that can happen on programming pins or other port pins - that NXP has seen that lead to the need to re-flash.  Our product was designed with care and has the recommended bypass capacitors, uses a ground plane, and has other measures of protection against intrusion of EMI/RFI, but I want to ask NXP if they have seen the RFI-re-flash combination and if they have specific advice on where to look for the problem.  Years ago, we had a similar problem with a PIC processor, which turned out to be due to RFI-based signal excursion on one of the programming pins.  Any advice NXP has here, would be much appreciated by us. 

Thank you,

David Stadille

[frank_m]

What exactly do you mean with "RFI" ?

"Flashing" is basically injecting charge carriers into an isolated gate via "high energy". (Usually at >9V, which are created via charge pumps on-chip).
Exposing the Flash to other energy inputs (like ionising radiation or heat) causes these charge carriers to revert back to the equilibrum state, ie. "erased".

[dstadille]

Frank, we have a design that sometimes serves in close proximity to variable frequency motor drives. VFDs are notorious for both radiated and conducted broadband emissions. Surely it's our responsibility to harden our design for electromagnetic compatibility, but the symptoms in this case are a little unusual. It's been a long while since I have seen a case in which EMI/RFI results in an already-programmed processor needing to be re-flashed. My thought pattern is this: MCU manufacturers often have information as to how their ICs malfunction in different scenarios. In this case, we have loss of program memory in response to an external noise source. Years ago, I saw a case involving PIC chips that incurred flash memory corruption. We communicated the basic symptoms to Microchip and their tech person advised us of an odd, known failure mode, the solution to which involved fortification of specific pin signals against unintended excursion due to RFI. Surely NXP staff have encountered questions pertaining to loss or corruption of flash memory contents, and it's highly likely that in certain instances they have sought to understand the specific means by which this can occur. It's usually a question of finding the right person. We can go on a long goose chase, and it might come down to this, but as is often the case, there may be someone at the manufacturer who has "been there" and is willing to articulate.

[frank_m]

This seems indeed strange. I don't know of any physical effect that would influence Flash cells directly via magnetic fields.
I am more of a software guy, but had to deal with Flash relatively often. Mostly in regards to erase/write duration, energy consumption, and erase/write times. Albeit I have no special insight in any vendor's implementation, I think their Flash cells are fairly similiar, only differing in dimension and some process-related parameter.

But having read into the theory a bit, I remember that erase/write required voltages of 9V or more to tunnel electrons onto the isolated gates. While these voltages had been applied externally 30 or 40 years ago, they are now generated on-chip, via charge pumps.
A direct "hit" by e.g. alpha particles is one way to discharge such an isolated gate. But I suspect an inadvertent activation of this internal charge pumps by EM induction would be another. If the susceptibility is caused by the silicon, bonding wire or external wiring is beyond me.

I am not a hardware developer, but know that motor driving circuitry is quite troublesome. EMI can "intrude" via GPIO or the power supply circuitry, causing severe ground level offsets.

[dstadille]

Hi Frank,

I first want to thank you for your interest and your suggestions.  I like to learn new things (well, most of the time) and this is also a good way to start a friendship.   I'm mostly a hardware engineer but do embedded work as needed, which by the way I enjoy. 

To your point, my focus is on external forcing / intrusion of some kind, something perhaps via port pins (as was the case years ago with a PIC) that causes loss or corruption of flash memory.  I'm sure NXP has been there, I just need to speak to the right person.  I know someone way high up in NXP, an old friend I worked with in France, but I'm hoping I can compel Amy to join forces with me rather than having to pull that lever. 

Our product loses its memory when operated in close proximity to VFDs, but the product is in a metal enclosure, and though VFDs are notoriously noisy, we're not at CT or MRI machine level.   I can try this or that band-aid, but it is much better if I understand the MCU loss-of-flash problem at the root level or perhaps one level up, otherwise I'm not really doing my job.  

What is something I can do for you?

David

[Alice_Yang]

Hello @dstadille 

Sorry nxp doesn't have the related information.

BR

Alice

[dstadille]

Alice, do you understand the question?