recovery of bricked xbee
![Tracy Allen](https://forums.parallax.com/uploads/userpics/712/nTZD6K4WNP6G3.png)
This is just a collection of links to information about how to recover an xbee that is not working and also is not recognized by X-CTU despite following all the standard procedures. You can find different takes on this by typing "bricked xbee" into Google, but the source is the knowledgebase on the Digi Web site.
How do I recover my XBee adapter?
http://www.digi.com/support/kbase/kbaseresultdetl?id=3196
1. Take the module out of the interface board
2. Connect the interface board to the computer
3. Open X-CTU make sure Baud Rate is set to 9600
4. Go to "Modem Configuration"
5. Put a check in the "Always update firmware" box
6. Select proper modem from drop down menu
7. Select proper function set and firmware version from drop down menu
8. Click on the "Write" button. After a few seconds of trying to read the modem, you will get an Info box that says Action Needed. At this point, CAREFULLY insert the module into the interface board
9. You may get the info box again a short while after, just use the reset button on the interface board.
The Parallax or Sparkfun USB adapter boards do have the necessary connections, except for the reset line. You have to improvise a button for that. There is a similar procedure to use if you have one of the RS232 adapters or development boards, simpler really, because you set up the conditions above before plugging in the power to the XBee. Then when the message appears, plug in the power. It may take several attempts. I do think the board needs to support the DTR and maybe also the RTS flow control lines. Not sure about reset. There is way too much hocus pocus surrounding this, because what happens during the bootloader process is not well documented, and neither are the causes that lead to an xbee becoming bricked. I have not had it happen very often, but when it did, the above procedure has usually worked. (barring cases that involved release of smoke!) Digi tech support 866-765-9885. They do answer and they are very helpful.
If that doesn't work, there is a more intensive procedure:
How to get into bootloader mode manually from terminal.
http://www.digi.com/support/kbase/kbaseresultdetl?id=3203
bootloader mode involves conditions of pins at reset
DTR asserted (low)
RTS deasserted (high, usually has pullup)
Din = BREAK (extended start condition, low)
Type: <$18> B <$19>
Terminal will return the bootloader message.
Other links.
Digi page for xctu
www.digi.com/xctu
How to update firmware: (pdf)
(current version from 2011 has important revisions for sleep pin latency)
802.15.4 1xEC
knowledgebase -- lots of great info
Main firmware info page for 802.15.4 XBee and XBee Pro
http://www.digi.com/support/productdetail?pid=3257&type=firmware
.
How do I recover my XBee adapter?
http://www.digi.com/support/kbase/kbaseresultdetl?id=3196
1. Take the module out of the interface board
2. Connect the interface board to the computer
3. Open X-CTU make sure Baud Rate is set to 9600
4. Go to "Modem Configuration"
5. Put a check in the "Always update firmware" box
6. Select proper modem from drop down menu
7. Select proper function set and firmware version from drop down menu
8. Click on the "Write" button. After a few seconds of trying to read the modem, you will get an Info box that says Action Needed. At this point, CAREFULLY insert the module into the interface board
9. You may get the info box again a short while after, just use the reset button on the interface board.
The Parallax or Sparkfun USB adapter boards do have the necessary connections, except for the reset line. You have to improvise a button for that. There is a similar procedure to use if you have one of the RS232 adapters or development boards, simpler really, because you set up the conditions above before plugging in the power to the XBee. Then when the message appears, plug in the power. It may take several attempts. I do think the board needs to support the DTR and maybe also the RTS flow control lines. Not sure about reset. There is way too much hocus pocus surrounding this, because what happens during the bootloader process is not well documented, and neither are the causes that lead to an xbee becoming bricked. I have not had it happen very often, but when it did, the above procedure has usually worked. (barring cases that involved release of smoke!) Digi tech support 866-765-9885. They do answer and they are very helpful.
If that doesn't work, there is a more intensive procedure:
How to get into bootloader mode manually from terminal.
http://www.digi.com/support/kbase/kbaseresultdetl?id=3203
bootloader mode involves conditions of pins at reset
DTR asserted (low)
RTS deasserted (high, usually has pullup)
Din = BREAK (extended start condition, low)
Type: <$18> B <$19>
Terminal will return the bootloader message.
Other links.
Digi page for xctu
www.digi.com/xctu
How to update firmware: (pdf)
(current version from 2011 has important revisions for sleep pin latency)
802.15.4 1xEC
knowledgebase -- lots of great info
Main firmware info page for 802.15.4 XBee and XBee Pro
http://www.digi.com/support/productdetail?pid=3257&type=firmware
.
Comments
Things can happen to the normal settings that make an XBee seem bricked, most notably a corrupted or otherwise unknown baud rate. With only the 7 standard baud rates to contend with, it is possible to run through them all and look for a response. However the XBee also supports non-standard baud rates. For example, ATBD 80 selects a rate of 128. Not impossible to run through them, but is it necessary? Does X-CTU know a side door?
For field installations it would be desirable to have a foolproof procedure for setting the XBee back to its factory default settings, equivalent to the ATRE command. But first it has to be able to accept commands.
Corruption of the actual firmware, as apart from settings, is a separate issue.
The difference is that the way I remember it, after shorting the pins it was back at it's factory settings. I don't recall having to continue to flash. I could be remembering wrong...
The motivation comes from a device in place in Mexico that would not respond to anything I tried with Prop firmware sent via email, but it was fixed easily after I sent a Parallax USB interface board #32400 and a copy of X-CTU via courier. It is an isolated incident, but it is one of those nagging things.
-Phil