Linux being my operating system of choice, I’ve always felt some frustration at having to dig out a Windows machine when I want to update XBee firmware. I now know that I was wrong in this - there’s actually no need at all to run Windows in order to run X-CTU for firmware upgrades.
Google has shown me that I’m far from being the first to discover this, but I thought I’d post it because I’ve seen a few questions about it here and in the XBee forums and I’ve not yet seen the solution posted.
The key is the wine program, and finding out how to make it work for X-CTU.
Wine is available for Linux and for Mac, so in principle this explanation should also apply for Mac users. I haven’t been able to try it on a Mac though.
The wine home page is
So if you use Linux or Mac and want to try this, here’s the recipe.
Obviously, make sure you have wine installed. Typing
as a command is one way to find out. If it isn’t installed, your distribution probably has it as a package.
Now download the latest version of X-CTU. I got version 220.127.116.11 which came as a file called 40002637_c.exe.
Run the command
That installs X-CTU. If it asks questions, take the default answer every time.
The first time you run wine it creates a hidden directory called .wine in your home directory. This directory contains some configuration stuff and a subdirectory called drive_c. The drive_c directory corresponds to the C: drive (surprise surprise).
You’ll find the X-CTU installation in
and if you navigate to there you can run X-CTU with
Try it by all means, but there’s more to do before it will run successfully.
Actually on my distribution (Fedora Core 11) I also got a desktop icon for launching X-CTU. Your mileage may vary.
In the .wine directory there’s also a directory called dosdevices. The dosdevices directory contains symbolic links. Here’s how mine looked originally:
[john@spike dosdevices]$ ls -l
lrwxrwxrwx. 1 john john 10 2010-02-13 18:30 c: -> …/drive_c
lrwxrwxrwx. 1 john john 1 2010-02-13 18:30 z: -> /
Now at this point the recipe forks. I’m using an RS-232 development board, so I needed to put into dosdevices a symbolic link called com1 to the serial port device file (/dev/ttyS0 in my case). To do that from within dosdevices:
[john@spike dosdevices]$ ln -s /dev/ttyS0 com1
Note: no colon after com1.
Next check the permissions on /dev/ttyS0 (or whatever you’re using). I found it was owned by root and in the dialout group, with permissions allowing access only by those users. There are two solutions to this:
- Make it available to all users (you need to be root for this command):
chmod o+rw /dev/ttyS0
- Add yourself to the dialout group (also as root):
usermod -a -G dialout john
and log out and in again for the change to take effect. Use the
command to confirm that you’ve joined dialout.
If you’re using a USB development board, the procedure is similar but with a twist, because USB /dev files are typically created only when a device is plugged in. There will be a different group to join (perhaps uucp), or to change the permissions you have to dig in the /etc/udev directory. The device files have names like /dev/ttyUSB0 so you’ll need to set symbolic links accordingly. As you may gather from the slightly vague wording, I haven’t actually tried this.
Now you’re ready to run X-CTU. Have a development board or equivalent connected at this point, so that there’s something for it to see.
Launch X-CTU and the next problem becomes clear: it won’t detect any COM ports. Fear not. Click on the User Com Ports tab and enter the port by hand. So if you’re using COM1 put a 1 in the Com Port Number box, then click on Add. Now COM1 appears in the Select Com Port box and you can click there to select it. Hit the Test/Query button and if all has gone well you’ll get a dialog box with the modem type and its firmware version.
Unfortunately X-CTU won’t remember the COM port next time it’s run, so you have to do the last step every time. Still, that’s not a huge imposition.
And at that point you’re ready to go. Click on the Modem Configuration tab and upgrade the firmware on your module.
A few caveats:
- The display of parameter settings didn’t look right to me, and I wouldn’t like to use X-CTU in this way for viewing or changing parameters. That’s ok by me - I’ve made my own software for that, and in this exercise I was only interested in firmware upgrades.
- X-CTU didn’t automatically discover the modem type and function set so I had to select those by hand from the menus.
- It also didn’t manage to read the parameter values when I asked it to.
- The menu for selecting the version of the upgrade didn’t appear in the proper order. The latest version was somewhere in the middle.
Maybe further work would solve the caveats, but for now I’m happy with what I have. If anyone else tries this, please let us all know how you get on.