Hardware Test
4.0.0
11/19/2015
SCN: 2826 — XL2 Fixed Task Error Reporting, Blue Screen Resets

When a task error occurs, the task error code is supposed to turn off all IO. It should report the Task Error, important registers and stack data to the screen as well as save it in battery backed RAM for later retrieval. If a debugger is attached, the information is reported to the debugger also. Unless there is a debugger, all tasks are shutdown and the controller waits for a reset event. If there is a debugger, the debugger task is allowed to continue running and the task that caused and reports the task error is forced into an infinite sleep loop, allowing the cause of the TE to be investigated through the debugger.

However, over the passed couple of years, attempts to fix minor issues with this feature have caused other issues.

The Task Error Reporting feature was resetting in the middle of reporting task errors. From the users perspective this would look like a blue screen, with maybe a few numbers on the screen, followed by a quick reset. If they were not watching the screen at the moment of reset it would appear as if the machine stopped running on its own with no explanation.

Three main changes were made to resolve the issue:

  1. The Operating System watch dog is now being reset within the loop that writes out the Task Error Data. The loop was too long not to have the reset occur within it. Earlier versions of the code had this but it was inadvertently taken out somewhere along the way.
  2. There is a watchdog interrupt on the input task. If the input task does not reset the watch dog, the interrupt fires and initiates a task error. While resetting the OS watch dog the TE code is now also resetting the input task Watch Dog, which prevents a second TE from occuring while trying to report the first one.
  3. Interrupts now remain disabled until all of the TE data has been reported to the screen and saved to battery backed ram. This prevents any interrupts from modifying the data we want to preserve or more importantly, causing another Task Error. If a debugger is attached, interrupts are then enabled to allow the debug task to run and interact with the debugger.