CTS stays high after communication

Question

XBee Pro900HP Firmware version 8070

Module sends and receives data in API mode for approx 35 hours, with occasional communication failures, but a retry by host is susccessful. Broadcast packages every 5 seconds, and unicast data every 20 seconds. Data length is less than 200 bytes in every case.

For no apparent reason, after approx 35 hours 10 mins module no longer transmited any data. Reception was unaffected. Only a hardware reset restarted transmit communications.

Although not using CTS, CTS line was de-asserted.

Interestingly, 35.4 hours is about 131072 seconds (2^17).

Would have expected, that if API packet was corrupt or sent while CTS was de-asserted, packet would be ignored and CTS would return asserted after timeout.

Answer 1

From the sounds of it, you are running into a buffer over run which is causing your API frames to become invalid. Try connecting CTS flow control and using it. I suspect you will not see this issue occur again.

Comments

Since the buffer is meant to be around 1kB and my packet size was only 200 bytes, I didn't expect to run into buffer problems, and lack of spare pins on the micro meant I didn't connect them.

If an API frame is invalid or buffer is overrun, shouldn't it be discarded and operation continue with next valid API frame?

Shall investigate and see if I can make some pins spare.

Answer 2

That would only be the case if API mode 2 is used. That is to say, in API mode 2, a 7E that is not first escaped indicates that it is a start of a new API frame where as in API mode 1, the module will wait for the number of bytes indicated in the length bytes. If the remaining bytes received on the UART that are needed to finish the packet and include the check sum (last byte received) prove to be incorrect, the packet is discarded. Since CTS flow control is not connected on the transmitting processor, you can see where this can cause issues. Especially if CTS changed states part way through receiving an API frame.