VFD motor control causing soft error in microcontroller flash memory

[elarson]

The basic setup is a microcontroller that is providing a 0 - 10 DC voltage level to the VFD. The VFD is connected to a 120VAC fan motor (small horsepower). The problem that is occuring is the flash memory in the microcontroller is getting corrupted. Reprogramming the device corrects the corruption problem.

I would like to be able to recreate the problem in the shop, but haven't had any luck. How can I corrupt the flash memory? I haven't been able to see any frequency in the field that might cause the problem. As anyone else experienced this type of problem?

 

[jraef]

While you propeller-heads are fighting over the bit-level actions going on here, might I point out that he responded that they are using portable cord on the VFD output, plus this micro-controller worked fine for years before they added the VFD to the equation? I still think that whatever the bit level cause might be, this is still, at the root, resulting from a poor system design with respect to having a VFD added in.

The easiest experiment to implement IMHO would be to find your worst offender and replace that portable cord with some properly shielded VFD cable or put it into steel conduit. If the problem goes away, no need to redesign the controller.

Eng-Tips: Help for your job, not for your homework Read faq731-376

 

[sugarshot]

If there is an electrical path between the AC motor and the microcontroller, even if only a single ground, I could see possible problems, especially if you are driving the motor with a light dimmer or something like that.

I would watch the power lines to the memory. If you don't have a 'scope, try a capacitor and headphones. If the motor comes on during a write, that could cause problems. A simple ferrite bead
on an interconnecting wire, a ferrite flat on a ribbon, could make a difference. If there are inputs to the system, digital or analog, seriously consider making these inputs (and signals) differential. I found this in a PID servo motor controller system with encoder feedback.
Since the wires to the motor were in parallel with lightly loaded digital (encoder) lines, the lines had to be differential to shed the induced noise from the signals which drove the motor.

It's safe to treat the flash device as infallible with regard to cosmic rays. I take it that you have observed this failure more than once.

I can't preclude bad software or something about the setup. Say some interupt occurs every 70 mseconds.. and should the controller be performing a write when the interrupt occurs, some flash controller timing condition is violated and the write operation fails, should any signals arrive late.

The circuitry perhaps could benefit from having a ground plane close by, if not within the board itself.
This serves in a sense to anchor electric fields locally
reducing interaction with more distant sources.

Putting a ferrite bead on the fan power line might be worth a try.

Though it's a tough call, I place my 50 cents on 'scat in the power rails', an occasional spike or heavily impressed 60-cycle voltage in the ground.

It may be possible to misconfigure a wake-up timer to run continuously.

Leprechauns?

 

[sugarshot]

Ok. Now I see. Chief suspect is the 10 foot span between the computer and programmer, which could well be 25 feet of cable. Forcing the port data rates to lower levels could solve the problem.

Putting power line filters on all the computers might help, and on the programmers' power supplies.

An industrial building could have a lot of large relatively slow transients... spikey power lines. Occasional confluence of effects results in a rare power event.
With 500 stations, it sounds like the output is fairly high, so rare power events equate with once/day failure rates. Lowering the data rate, if that works, might cut production enough to make reprogramming once a day are minor imposition.

Inadequate static control measures could be in the list of suspects I suppose.

If you have to go to the site, I would bring some fancy gear to monitor their power circuits. Some systems could be on noisy circuits.

I would take the port data rate down a notch and see if they have any errors that week. AC power filters to the devices on either side of the link (programmer, computer)
might be a better solution, since it might allow the higher data rate. Optically isolating the data links on one end could work.

Hope that helps.

Geoff