A customer is complaining about a 0x81000003 task error. The error is being generated while building the response back to the Office PC. The string has gotten too large despite having a check for size just prior to when the error occurs. There appears to be memory corruption or a timing problem with shared memory involved.

While troubleshooting, it was noticed that the task errors seemed to occur only during periods of time when the entire Eclipse network of machines were experiencing high rates of communication failures, indicating a network wide issue. It is believed that this network issue sets up the environment when this occurs.

The buffer for parsing a command and then building the response is a shared buffer. When the RS485 network is used, the buffer is protected by disabling the RX interrupt while building the response. There is no such protection with Ethernet which, in theory, may be the source of these task errors. The theory is that the network issues setup the environment where a new command can come in and corrupt the response as it is being built. The new command is written to the buffer in an interrupt.

To eliminate this as a possible cause, the following changes are being made. The interrupt will save the command in a temporary buffer. The UART task will copy this temporary buffer to its processing buffer so that if a new command comes in, it will no longer be able to corrupt the response. The new command will be copied and processed only when the UART task is ready for it.

Some additional changes were made to minimize the damages if the UART Tasks buffer corruption is still somehow occurring after adding the temporary buffer. Rather than using copy string functions, the buffer copying code has been modified to use sub string functions that will only copy as much memory as the target string buffer can hold.