During the Records Test, Chain Test, one customer experienced an 0x800004FF task error, which indicates something is using up all of the CPU time.

The Error occured durring the Pass 2 test that verifies each of the record chains are valid. This test has code that checks the last time the test gave up time for other tasks to run but there was a change made to minimize the use of Rts_Sync_Acknowledge. This may be partially to blame for the Task Error.

The original test called Sync Wait every 15 seconds on a 30msec Sync Acknowledge. It did this after sending a message to the Peg Task to update the progress bar.

I have several concerns. Waiting 15 seconds to give up time is a significant amount of time to wait. In addition, at the time of the software edit, the sleep time was changed from a theoretical 30msec to 10msec. 10msec may not be a long enough time for the Peg Task to update the progress bar and anything else it needs to update after 15 seconds, to then be able to give up time for the lower priority tasks to run.

Two changes have been made. The time between sleeps has been changed to 5 seconds and the sleep time has been returned to the 30msec time that was originaly used for the Sync Acknowledge. If the original change caused the task error under extream conditions these two changes should prevent it from happening again or at least making it much less likely.

There is a chance that this customer still has another issue that created the extream test conditions but at least the Task error should be gone or at least less likely.

This task error happens if the resulting string of a Rts_Add_Hex_String exeeds 255 bytes, which is never supposed to happen. The only place this function is used is when adding the CRC to an Eclipse message response.

When investigating this error, I found that the response is tested a short time prior to this call and if it were anywhere close to causing this error, it was already being truncated. Something like an Interrupt would have to be modifying the response while we are building it.

We decided to double buffer the response from the buffer that is used by the RS485 interrupt to ensure that it is not the culpret.

In addition, just prior to calling the Rts_Add_Hex_String function we test again, just to be sure. If we find that it has been modified, we abandon the response to avoid generating the task error or sending a corrupted response.