Xwire: Error handling
The Xwire protocol is quite robust. It can survive lost messages (packets) and uses a 16-bit CRC to guard against erroneous data being accepted by a receiver. Messages are being constantly transmitted, so if a single message is corrupted the data will get through next time around.
Error handling in Xwire is very simple. The Xwire master maintains an error counter that can be read out using XwireGetErrCount. Reading the counter resets it. It is an 8-bit counter that stops counting when it gets to 255.
Data is transferred between master and slaves by serial data messages (packets, datagrams). When the master sends out a message to a slave, it expects a reply. If the slave fails to decode the message correctly, it ignores it. If the master cannot decode a reply correctly, it ignores it. Whenever the master fails to get a message it expects, it counts up one error. Hence one error count represents a failure somewhere in the round trip.
Message failures can be due to:
- Excessive wire length degrading the signals.
- Excessive noise (electrical interference)
- Mismatched byte counts between master and slave (no messages will make the round trip – this should be detected during system debug!)
- The slave being temporarily too busy to respond.
It is a good idea, at least during system debug, to arrange to monitor the message error rate. One possibility is a task that reads the error counter every 100mS or 1S or 10S (whatever works) and displays it.
Why would a slave be too busy to respond?
The Xwire system has been deliberately designed to be tolerant of a slave missing messages. We have done it like that to leave ourselves room to design special purpose slave boards that squeeze the last little bit of speed out of their processors.This might be some very high speed peripheral function that fully occupies the processor for periods of time, during which it simply does not have enough grunt to do Xwire communications as well. The master will tolerate periods of no contact with such a slave. The error counter will accumulate counts rapidly but communications with other slaves will barely be affected.
Fatal runtime errors
Certain error conditions will result in a runtime error and reset of the controller. The error codes are documented under runtime error codes.