Improved Fault Diagnosis on the XL200 ARM Coprocessor (accurate task error records, and keeping the information needed to read them later)

When the ARM coprocessor detects a fault it records a task error with diagnostic details and restarts itself, which is the designed behavior. Two problems were making those records misleading, and both are now fixed.

First, if the fault happened while the coprocessor was in the middle of handling a hardware interrupt, the recorded details described an unrelated part of the system instead of the code that actually failed. The record looked perfectly plausible, which is worse than no record at all - it points an investigation in the wrong direction. This was a significant part of why the recent USB hub fault took a full day to track down.

Second, two of the recorded values were stored under each other's labels, so anyone reading a record was told the failure was in one area when the evidence actually pointed somewhere else. That also contributed to the same wasted day.

Fault records now identify the code that actually failed, whether the fault occurred in normal program flow or inside interrupt handling, and they include which interrupt was active at the time. The record's format and size are unchanged, so everything that reads or displays these records continues to work exactly as before. Records logged before this change still have the two values reversed.

The build now also keeps a second piece of information under version control. A fault record identifies the failing code by its numeric address, which by itself means nothing - translating an address into the name of the function requires the "map file" the build produces, and that map is only valid for the exact program image it was built with. Until now only the program image was kept and the map existed solely on the machine that built it, so a fault reported from the field months later could not reliably be traced back to the code that caused it. The map is now saved alongside the program image automatically at build time, and a copy also remains on the build machine for immediate use.

Both fault cases were verified on the bench by deliberately causing each kind of fault and confirming the recorded details matched the known cause.

This is diagnostic accuracy only - it changes nothing about how the product runs, and it does not prevent faults. It makes the next one much faster to diagnose, including well after the software has shipped.