I was happily using my XB24-B with the “ZNET 2.5 ROUTER/END DEVICE AT” firmware (1241) which I programmed using X-CTU. Then I tried programming the same module with the “ZNET 2.5 ROUTER/END DEVICE DIGITAL IO” firmware (1741). At the end of the programming sequence, I got an error when it was trying to set my parameters. Now, I cannot communicate at all with this modem. The pin 13 and 15 LEDs are on steady. If I click the “Test/Query” button on the PC Settings tab of X-CTU I get “Unable to communicate with modem”. If I check the “Enable API” box, I get
Communication with modem…OK
Modem type = Name unknown (ID=429496724800)
Modem firmware version=
Just to verify my setup, I simply unplugged the XBee module and inserted another (good) one and I get
Communication with modem…OK
Modem type = XB24-B
Modem firmware version=1220
So I know that my serial port/USB connection is working properly.
Help! Did I “brick” my XBee module, or is there a way to recover it?
Me 3 ran into the same problem. It crashed while I tried programming the module with the “ZNET 2.5 ROUTER/END DEVICE DIGITAL IO” firmware (1741). I tried Jordanh suggestion, but It did not work. I got the error message: “Detected baud rate difference”. I tried to change every possible baud rate supports in the X-CTU program. I also tried this appnote, http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=2108
Below are the messages for the following operations,
=RESTORE=
Resetting AT Commands…
Detected baud rate difference.
Make sure PC and modem baud rate is set correctly
Restore Defaults…complete
=WRITE= (with any firmware Version 1241)
Getting modem type…OK
Programming modem…Detected baud rate difference.
Make sure PC and modem baud rate is set correctly
Lost communication with modem
Write Parameters…Failed
=READ=
Failed to enter command mode
Unable to read Version (ATVR)
Detected baud rate difference.
Make sure PC and modem baud rate is set correctly
Read parameters…Failed.
There must be a problem with one of the following,
The “ZNET 2.5 ROUTER/END DEVICE DIGITAL IO” firmware (1741).
X-CTU program V5.1.0 and V5.1.10 Beta, versus Windows VISTA(NOT supported).
I am still looking for any suggestion from the Mods, or anyone who can help me to fix the baud rate problem or related crashed. Thanks!
Thanks to Mike and others at Digi who helped me fixing the problem (Detected Baud rate difference).
I tried this suggestion,
Remove the RF modem while the power is on.
Under Modem Configuration tab,
Checked “Always update firmware”
Select Modem, Function set, Version (I used the default version, 1241)
Select 9600 Baud
Click on WRITE button while the modem is not install. The Reset message window pops up. Now install the RF Modem, then press reset. If the pop up window did not vanish, click on Cancel button. The modem will reflash as normal.
I ran into this problem as well. I followed the instructions above for flashing to 1241 and the module now responds like it did originally.
I am wondering what the “Digital I/O” firmware version is intended for. Will the 1241 firmware work OK if only sending digital I/O line information? In my application, I do not need the serial port - just the I/O lines.
Also, how are the parameters supposed to be programmed with the “Digital I/O” version? First X-CTU flashes the firmware, then the parameters, but the module cannot be communicated with after the firmware update.
Never fear, simply select the 1241 firmware again from the drop-down in X-CTU. When the dialog box comes up indicating that X-CTU can not talk to the module, press the reset button on the development board and X-CTU should continue reprogramming the module.
The modules contain a failsafe bootloader to prevent them from becoming unusable.
OK. So with help from Mark in tech support, I found what I did wrong. First, it turns out that firmware version 1741 is a little odd in that once you program it, you cannot read anything back on the serial port. (Apparently this version of firmware is meant to be used with a specific IO board that uses the serial port for it’s own purposes.) I may have some details incorrect, but this is how I understand it. However, you should still be able to program the firmware back to something reasonable like version 1241.
The reason I could not do this with was that I had neglected to connect the RTS and DTR pins on the module to my serial converter chip (see the footnote to Table 1-02 in the XBee ZNet 2.5 Product Manual, or check this link out: http://www.humboldt.edu/~cm19/XBee%20setup.pdf). Tech support was quite surprised that I was able to program firmware at all without RTS and DTR lines connected. Once I connected these lines to the corresponding pins on my FT232R serial/usb breakout board, I was able to use the X-CTU program to program version 1241 onto the module. Note: Before a reprogrammed, I still could not read parameters or anything from the module. However, if I manually selected the modem type (XB24-B) and the firmware version (ZNET 2.5 ROUTER/END DEVICE AT) and checked “Always update firmware” and click Write, I was able to download the firmware and start using my module again! Yes!
Thanks - tried the same procedure, but doesn’t work for me, probably because mine is in API mode - (If I select API mode then the popup message asking to reset the Xbee never appears…) - Do I correctly assume you did not set API mode?
Hi to everybody…i’ve the same problem to update the firmware on my modem…i tried the last suggestion in the last post but continue to not work…After this prove i obtain the message:
Getting modem type…OK
Programming modem…Detected baud rate difference.
Make sure PC and modem baud rate is set correctly
Lost communication with modem
Write Parameters…Failed
I’ve tried all possible combinations of the different parameters but nothing… Someone can help me please?
You might want to call Digi Tech Support to get assistance if none of the suggestions in this topic have worked. If we can’t get you going after calling Support, you may be in need of an RMA.
> Hi to everybody…i’ve the same problem to update the
> firmware on my modem…i tried the last suggestion in
> the last post but continue to not work…After this
> prove i obtain the message:
>
> Getting modem type…OK
> Programming modem…Detected baud rate difference.
> Make sure PC and modem baud rate is set correctly
> Lost communication with modem
> Write Parameters…Failed
>
> I’ve tried all possible combinations of the different
> parameters but nothing… Someone can help me
> please?
>
> Thanks…
I have stumbled into the same problem.
Has anyone turned up a solution?
Revision: Talked to Eric in tech service – he recognized the problem immediately. He told me to use the RS-232 dev board instead of the USB dev board. That did the trick.
LTR
Digital IO firmware is for use in the XBee Digital IO adapter. Its a special firmware which disables the UART of the radio, since serial communication isn’t part of the DIO adapter. The Analog IO and Router Sensor firmwares behave the same way, as they’re intended to be used in XBee adapters which don’t use serial communication.
As far as setting parameters on the unit once the firmware is flashed, you’d do this over the air with either the over-the-air beta version of X-CTU, or from a python script if you have a ConnectPort X as your coordinator.
I am wondering: When the “ZIGBEE ROUTER/END DEVICE DIGITAL IO” firmware is installed, should it be possible to change the feature set to another one “over-the-air”?
I have tried, but when I read the configuration afterwards (still over the air) it always flips back to “ZIGBEE ROUTER/END DEVICE DIGITAL IO”.
Where is the “over the air” stuff documented? Is it intended only for setting registers?
Hi,
I was able to solve the problem.
The module is series 2, with X-CTU reporting an XB24-B modem.
I tried to force XB-24ZB loading a “end node digital I/O” and magically all the commands described in the manual became available, including key management.
Unfortunately, I am no longer able to upload a different firmware. I downloaded the latest X-CTU from digi site, and can read/modify configuration on the air, but when I select the “upload firware” flag, nothing happens.
Upgrading firmware/changing function sets over-the-air does not work in ZNet 2.5.
You can issue remote AT commands to a DIO module (only way to configure it, since DIO disables UART of module) from an API Coordinator it’s associated to via XCTU, but there is nothing special about sending a remote AT command via API. This information can be found in the Product Manual.
Despite having followed the same steps as others who report that it works - I don’t succeed to remove the DIO feature set from my module using X-CTU.
I suspect I have a problem with my cable. I am using an FTDI USB cable on a X-Bee explorer board from Sparkfun. I wonder if I have RTS/CTS connected in the way I should, and if there are any other conditions for signals on the X-Bee module that need to be met in order to re-flash it. It would be really appreciated to get some more detail on why RTS/CTS is needed for reprogramming (doesnt’t seem to be the case all the time - but for this manoeuvre it is?) and if one can work around that by fixing some of the lines statically to GND or 3.3V?
Okay, I’m new here, but I’ve spent a good three days trying to recover from flashing 1741 to my xbee pro s2… and hopefully the dev board arriving tomorrow will help…
But does anyone else think, given the number of people falling into this hole, that just maybe the XCTU should pop some kind of WARNING before flashing a firmware that disables the UART and might be hard to get back from without a proper connection to the radio with DTR and etc?
Something like "Oh, Hi- XCTU here- you might be new and might not know what you’re doing (no offense meant) so we thought we’d warn you that the firmware you selected is for a pretty specific thing and you probably don’t really want it. Because it’s kind of a mess to get back to where you were if you don’t have the right equipment on hand… ‘ARE YOU SURE?’ [yes] [no] "
Update: I finally got my 1741-flashed xbee pro s2 back from the dead. Here’s the trick- follow the instructions in this thread but NOT ON A WINDOWS 7 PC!! I tried a million times, a million different ways, and I do not think you can get back to an other-than-1741-firmware on Windows 7. I tried with an FDTI usb-ttl, an rs232-ttl, an arduino mega with dtr and csr and the like hooked in, and also with the dev board, which finally arrived last week.
Then, I hooked up my dev board to an XP machine and it worked on the second try (steps 5-7 below) .
Here’s what I did (there may be an easier way- this is what worked for me.)
plug in dev board. No XBEE attached.
start XCTU. select new firmware. check “always write”. make sure speed is 9600, n-8-1.
press write button.
when you get the “cancel” dialog, hold down reset button, plug in board, let reset go. upload will fail.
it failed for me here. hit write again. wait for “cancel” dialog.
press reset button once.
uploading should commence.
when it is finished, you should be able to switch to the terminal tab and hit +++ and get an OK back.
