3

Sympthoms: I have several XBee 24-ZB series 2 here, and they are hooked up on a PC as the coordinator and on an end device (AVR) as a router (no sleep).

When sending data in larger amounts, it could happen that the router/end device XBee suddenly freezes the DIN line. It can still communicate over radio, and it can still transmit received data serially to the microcontroller (DOUT) but ignores DIN.

The XBee is operated in transparent mode, and it also ignores the AT commands (+++ with guard times), no matter how often you try. I made very sure the waveforms are clean, read the VCC is stable with a filtering capacitor, read the manual and datasheets.

The only solution is to RESET the XBee or power cycle of the XBee device.

Baudrates: I tried 111111 and 250000. Those are perfect matches for the XBee (0% error) and for the AVR which is also operating on a 16 MHz crystal. During the time the XBee works, it can transmit large amounts of data without a single corruption, and reset of the microcontroller does not change anything.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
John
  • 7,507
  • 3
  • 52
  • 52
  • For your information: A similar issue is posted to the Digi support forum, [xbee-series-2-module-enter-undefined-state](http://www.digi.com/support/forum/44629/xbee-series-2-module-enter-undefined-state-freeze) – Jostein Jan 05 '15 at 09:10

3 Answers3

3

The reason for this matter seems to be a (known!) firmware bug.

The XBee has hardware flow control which usually is not used on microcontrollers; it's additional lines, routing, programming and is in most cases not that important. The XBee has a receive buffer for the serial input which can get filled. It should ignore additional data; if you send more than it could send over the air, it will start to lose bytes.

If you keep sending data once the receive buffer is full, it will enter into an illegal state, and that's definitely a bug, IMHO. If you push data for a while it will just stop taking data for an infinite amount of time until a hard reset.

Note: it also does not send any more radio data, so even if the buffer is full it will not continue to use it anymore. I tried to get a confirmation from digi support, but without paying 99 USD they will not respond to this fact (one question = 99 USD). I am not going to pay 100 bucks to discuss a bug in their firmware; they should FIX it!

The solution is to either implement hardware flow control or to make absolutely sure you do not send too much data. The radio throughput is from 5 to 39 kbit/s depending on the situation, so you need either API mode which includes ACKs or wait for responses from your radio partner device (an own layer of ACKs).

I verified this fact with two different prototypes and three brand new XBee modules (XB24-ZB).

If someone has more information on the topic I'd appreciate it.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
John
  • 7,507
  • 3
  • 52
  • 52
  • I experience the same bug using XBee Pro 868. My solution enables and checks the CTS pin on the XBee. It gets asserted and de-asserted properly, but after about 10 minutes of work and some hundreds of kilobytes of data sent the CTS stays high (de-asserted) and the XBee does not respond over UART at all and does not switch to the command mode. The _Assoc_ LED flashes. – Mike Bessonov Apr 03 '15 at 22:30
  • 1
    Yea I also enabled hardware flow control but reliability with xbee has been a problem all the way for me. Their firmware is really really bad. They advertise reliability as one of their main features at the same time reliability has been my #1 issue with xbees. (pro as well as normal ones) For a radio controller that's a really bad thing. I also encountered a dozend of other serious problems I had to work around. Stuff that should have been fixed in pre alpha. – John Apr 08 '15 at 00:03
1

There are a few possible solutions:

  • Lower the baud rate to the point where you can't overflow the XBee module's serial buffer.
  • Implement hardware flow control, and stop sending data when the XBee module de-asserts CTS (telling you its buffer is full).
  • Wait for an acknowledgement of packets received on the other end.
  • Switch to API mode and wait for a Tx Status frame for every frame sent.

I would agree that it's a bug in the XBee firmware and it shouldn't lock up if you continue to send bytes after it de-asserts CTS.

But I would also argue that you'd still have problems even if the XBee didn't lock up. Would you really want it to start dropping data randomly?

A proper design would make use of both CTS and RTS signals to avoid losing any data between the host and XBee module. The host de-asserts RTS when its buffers are close to full, and doesn't send data when the XBee module de-asserts CTS.

tomlogic
  • 11,489
  • 3
  • 33
  • 59
  • Sure that's true. However this is a serious bug in a radio device that is marketed to be very reliable. I am quite sure that many people got gray hair over this as it's difficult to believe that such a primitive showstopper bug is part of the latest firmware. – John Jun 28 '14 at 00:56
  • My design does make use of the CTS signal on the XBee Pro 868, but the problem persists. The CTS gets asserted and de-asserted properly, but after about 10 minutes of work and some hundreds of kilobytes of data sent the CTS stays high (de-asserted) and the XBee does not respond over UART at all and does not switch to the command mode. The _Assoc_ LED flashes. The UART data rate is 115200, changing the buffer fill threshold with ATFT does not seem to produce any difference. – Mike Bessonov Apr 03 '15 at 22:35
  • 1
    I suspect that there is an issue along these lines: The XBee module's receive buffer is getting full, it de-asserts CTS. The host sees CTS de-asserted and stops sending bytes, BUT, there is still a byte in transit plus one or more bytes in the UART waiting to go. The XBee module may be in a state where receiving 3 bytes after de-asserting CTS results in a locked circular buffer. Although the buffer is full, the code pulling bytes from it somehow sees it as empty. And it could be code common to multiple devices. – tomlogic Apr 04 '15 at 16:05
  • @tomlogic Theoretically, the threshold of the amount of free space in the XBee's receive buffer below which the CTS is de-asserted is regulated by the ATFT command. The default value for Pro 868 is 0xA0, I've tried reducing it to 0x80 and raising to the max of 0x13F, but observed no change in either case. – Mike Bessonov Apr 08 '15 at 13:41
0

It does rather seem like this problem is never going to go away, which is a shame because it's rather a fundamental flaw as people have pointed out.

I have attempted to solve it with flow control, which seems to help, except that it does seem that router-firmware XBee devices tend to still crash. Something about it receiving packets to route at the same time I guess...

My full and final solution has been to give the attached device control over the XBee's reset pin, so when it crashes, the device can reset it after a timeout. It isn't a pretty solution, but it's 100% effective.

David Sainty
  • 1,398
  • 12
  • 10