We have a customer complaining that several of their controllers are resetting and powering up with loss of memory, reporting that the configuration has changed.

The most likely cause is that a power or software glitch is causing the reset. Something in the software is apparently corrupting settings or Global Back data, which requires a memory clear.

To help determine what software is losing control, we added a switch-on diagnostic that arms the 386's hardware breakpoints on the backup copy of the setup table. If anything writes to it unexpectedly, the controller records a task error with a code (0x000F0002) and a stack trace pinpointing the offending code — the tool to catch, in the act, whatever is corrupting configuration on the affected customer machines.

In addition, every powerup, the controller reports to the debug console which copies of the setup and global data passed their integrity check. If a "configuration changed" ever happens again, this tells us exactly which data went bad (setup table vs. order/global data) so a targeted fix can follow. No effect on machine operation — it's reporting only.

If the Global Data backup is being corrupted, a new error message will be displayed to distinguish it from the Setup Data. Knowing which block of data that is being corrupted will help us target that memory with more debug resources, if necessary.