>How about fixing the root cause of the problem? That would be time better spent.

You spend your time, I'll spend mine. The fat's already in the fire. The units have been built and have been deployed. We're talking a couple days of my time vs. three quarters of a million in hardware, plus rolling a truck to swap the units out once the new ones have gone through design and qualification. Root cause be damned, it we can fix it on the existing units with firmware we will, and we have.

>Maybe something as simple as a pullup/pulldown on the reset pin or an appropriate filter or shield somewhere.

We've researched the manufacturing and aging profiles of the relays with respect to energization-to-contact timing consistency and they fall nicely within the window of close-enough-to-zero-cross that is needed to avoid too much energy radiating into sensitive areas, such that the source of the energy can be eliminated by timing the relays precisely. Don't have to filter what noise don't exist. You could even go so far as to say the firmware was defective for having failed to anticipate the problem, we'll certainly steer the customer's perception in that direction.

Nevertheless, it looks like some transorbers in parallel with the original MOVs on the load circuit of the relays will also do the trick, and so will be incorporated into future designs, just in case we want to use the board to switch DC someday.

Concerning the clearing of internal RAM by the micro, it seems the ADuC has a bunch of chores to do before it ever gets around to running the application, setting up the A to D and whatnot, so the 'first' instruction is not the first instruction at all. This is factory code in 'hidden' flash that probably is not worth trying to mess with.

Cheers -- ewd