XBee modules are a range of wireless modules built by Digi, and are typically used to add wireless connectivity to Arduino or other microcontroller based projects. To configure these modules and update their firmware, you can use the XCTU configuration utility. This utility uses a serial port to talk to the XBee module, so you will need some way to connect to the XBee module to a serial port on your computer (using a USB "TTL" serial port, a "real" RS232 port has too high voltage).

The easiest way is to use a dedicated board, like the SparkFun Explorer USB:

However, if you already have an Arduino and an XBee shield for it, you might want to use those to connect XCTU to your XBee module. In theory, this should be a matter of re-arranging some wires, but in practice I've run into some problems attempting this (depending on the hardware used).

In this post, I'll show a few ways to do this using an Arduino and a shield, and explain some of the problems you might run into.

First, let's see what connections we really need. When wiring things up using an XBee explorer, these are the connections made (leaving out stuff like the reset button, leds, and power and ground connections):

Here, the two data lines (TX/RX/DIN/DOUT) are the most important, those are needed for configuration and normal firmware updates. The other handshaking/flow control signals can prevent overflowing buffers at high speeds, but that is not normally a problem. They might also be needed to recover from a failed firmware upgrade, to force the XBee module into bootloader mode.

So, how can you use an Arduino and XBee shield to achieve these connections? Below, three variants are explored, each with different requirements, advantages and disadvantages.

Bypassing the Arduino microcontroller

Most Arduinos contain a single microcontroller (MCU), and have a USB-to-serial converter integrated on the board as well. This USB-to-serial converter is connected to the microcontroller, so it can be used to upload programs to the Arduino, and send debug output using Serial.println(). The connections on the Arduino Uno board are like this:

The resistors you see here are protection resistors, to prevent a short circuit when you connect another serial device to the Arduino's RX pin, but at the same time the USB-to-serial device also enables its TX pin. As you'll see later, these resistors might cause issues as well.

Now, to connect the XBee to XCTU, you can connect it to the USB-to-serial converter. To do so, you should connect the DOUT pin to the Arduino's TX pin, and the DIN pin to the Arduino's RX pin. This seems wrong, but remember that you want to talk to the USB-to-serial chip, not the Arduino. This would look like this (voltage converters not shown):

How to obtain this configuration depends on the shield used. The official Arduino Wireless SD shield, as well as some others, have a switch that can enable this wiring (in the other position, the connections are reversed, making the XBee module talk to the microcontroller instead). On some shields, like the SparkFun XBee shield, there is switch that can connect the the XBee module to pin 2 and 3 on the Arduino. Then, by connecting pin 0 to 3 and 1 to 2 on the shield's pin header, you get the above configuration. Yet other shields, like the one from ITEAD, simply have a long row of jumpers that allow connection DIN and DOUT to any I/O pin you want.

Interfering microcontroller

Note that the microcontroller is also still connected, since the Arduino board has no way to disconnect it. To prevent the microcontroller from interfering with the XBee communications, you will have to actually remove the microcontroller from the socket. This is not possible with all Arduino boards, though. If you do this, the auto-reset stuff below does not apply, though the pullup problems do.

You might think (I did) that you can also just upload an empty sketch to the Arduino, which keeps its serial port disabled. However, when XCTU opens up the serial port, the Arduino resets and the bootloader runs for a second or so, enabling the the serial port during that time. Because XCTU sends some data, the bootloader keeps running for longer, making the communication between XCTU and the XBee module fail.

Disabling auto-reset

This can be fixed by disabling auto-reset, but the only reliable way I've found to do this is to cut the "RESET EN" solder jumper. Since you'll have to re-solder the jumper again to enable it (needed for uploading new sketches), this seems a hassle. A lot of people online mention fiddling with a specific value resistor or capacitor to disable auto-reset, but that didn't work for me (I think the point is making the reset pulse so short it goes undetected, which is of course a bit shaky in any case). Connecting RESET directly to the 5V pin worked for me, but this creates a very brief short circuit whenever it would otherwise auto-reset (which might damage the usb-to-serial chip, though I'm not sure if this is a real risk).

Instead of disabling auto-reset, you could also try to keep the Arduino in reset by connecting RESET to GND. Again, this works, but has the same brief short circuit described above.

Problems with pullups

Even if you solve these problems, you might run into further problems, depending on the XBee shield used. Since Arduinos typically run at 5V and XBee modules at 3.3V, shields need voltage converters (which were hidden in the previous image). For example, the SparkFun XBee shield uses a transistor and two pullup resistors for this converter. This results in the following (only the DIN line is shown, DOUT is identical):

Since the pullups used are 1kΩ, just like the protection resistors in the Arduino board, communication will break. When the USB-to-serial converter pulls its TX line low, a resistor divider is created, resulting in 2.5V on the transistor instead of 0V, preventing it from switching on. A similar problem can occur when a resistor divider is used for voltage conversion, like the ITEAD shield does, though that particular shield uses big enough resistors (10kΩ) to not cause any problems.

So, this bypass approach is only limited in use. If you use it, you can do both configuration as well as firmware updates in XCTU. Recovering from a failed firmware upgrade is sometimes possible, but since no handshaking connections are available, this does not always work (in particular, it only works if the bootloader detects that the firmware update has failed, so the bootloader stays active all the time).

Forwarding through the Arduino microcontroller

Instead of bypassing the Arduino microcontroller, you can also forward data through the Arduino microcontroller. One one side, the Arduino talks to the computer running XCTU, on the other side the Arduino talks to the XBee module. A simple sketch inside the Arduino takes care of forwarding the data.

Since most Arduinos only have one hardware serial port, connected to the USB-to-serial converter, you will need to use a software serial port to talk to the XBee. I recommend using the AltSoftSerial library for this, which is significantly more reliable (it can receive while sending, for example) than the Arduino-supplied SoftwareSerial library.

The wiring would look something like this (note that AltSoftSerial dictates the use of pin 8 and 9 on an Arduino Uno):

Achieving this wiring can be a bit tricky. On shields like the ITEAD one, this is a matter of placing the jumpers correctly. On shields like the SparkFun one, this means setting the switch so the XBee connects to pin 2 and 3, and then connecting pin 2 to 8 and 3 to 9. On shields like the Arduino Wireless SD shield, this wiring is impossible without cutting traces.

Disabling auto-reset

When using this approach, auto-reset again causes problems. When XCTU opens the serial port, the Arduino will reset and XCTU ends up talking to the bootloader instead of your sketch. Disabling auto-reset, as described above, helps here.

Fixed baudrate

When you use this approach, the forwarding sketch will need to configure a fixed baudrate for both serial connections. Now, since configuration, as well as triggering a firmware upload, typically happens at 9600 baud and the actual firmware upload at 57600 or 115200 (depending on the XBee board used), updating the firmware is not possible with this approach — you would have to (very quickly) switch the baudrates somewhere during the first part of the firmware update. In theory, you could first change the configuration baudrate to 57600 or 115200, so that the same baudrate can be used for both, but I haven't tried this approach.

Forwarding through the Arduino Leonardo

When using the Arduino Leonardo (or another ATmega 32u4-based board), this problem can be solved in a much better way. The Leonardo does not have a separate USB-to-serial converter, but instead its microcontroller supports USB directly, so it can expose a virtual serial port on the computer itself. This is useful, because:

1. This leaves the single hardware serial port on the Leonardo available to talk to the XBee module.
2. The auto-reset on the Leonardo works differently, so XCTU will never accidentally trigger auto-reset.
3. The sketch has access to the baudrate configured by XCTU, as well as the handshaking signals, allowing both firmware updates and full firmware recovery.

Wiring is also simplified, because all shields trivially support connecting the XBee module to the Arduino hardware serial port on the RX and TX pins. This is what the wiring looks like:

Note that this additionally connects the XBee handshaking signals to Arduino I/O pins, to support firmware recovery. If this is easy depends on the shield again - typically you will need to solder some wires, though I believe the ITEAD shield already has these connections in place. You can leave them out if you just want to do configuration and firmware uploads.

The sketch that implements this isn't so trivial, so I've made it available for download. This sketch uses some recently introduced changes in the virtual serial port to get access the baudrate and handshaking signals, so this sketch will need the Arduino AVR core 1.6.9 (expected to be shipped with Arduino IDE 1.6.6). Neither of these is released yet, so for now you can use the Arduino hourly build instead.

Summary

So, it turns out that using an Arduino and XBee shield for talking to your XBee module from XCTU is not quite as easy as you would expect. Using an Arduino Leonardo works perfectly, but other approaches are either cumbersome, or potentially damaging for the hardware... If anyone is aware of better approaches, please let me know!