SparkFun Forums 

Where electronics enthusiasts find answers.

All things pertaining to wireless and RF links
By Tobrew
#74409
This worked for me when the reset trick refused to.

It is possible when using the USB board. You just have to go about it in a different manner.
1. Take the module out of the interface board.
2. Connect the interface board to the computer.
3. Open X-CTU
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 menus.
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.

This should get you back up and running.

It can take a couple of tries but it worked for me.
By jimmyhowarth
#84634
Guys,

The fix above didn't work for me, I have a XBee 2.5 module and I am trying to program it via a sparkfun USB board. The following did though.

1) Select "Always update firmware"
2) Under modem select "XBP24-B"
3) Under function set select "ZNET 2.5 COORDINATOR AT"
4) Put XBee module into USB board and plug into computer
5) Press write button
6) When dialog button pops up, reset the XBee module. I did this by turning over the XBee module and sticking an unraveled paper clip through the two holes marked "GND" and "RST".
7) The firmware should start to load.

Hope this helps.

Jim
By rtaubitz
#84799
You guys all do know the differences in feature/function set's right?

In API mode '+++' won't work, in fact 'nothing' will work unless the messages you send it are in API format, so for the most part select the firmware with AT in it (unless you know what you're doing :P).

Also the EndPoint/Serial Router or Coordinator mode defines the role of the XBee. The default function set for the 2.5 XBee is "EndPoint/Router AT", which means the XBee works as an EndPoint device in Endpoint/Coordinator setups, or Serial <-> Serial devices when you have just two XBee's (what goes in comes out the other end).

The Coordinator function allows the XBee's to be used in a mesh network, with this XBee as the Coordinator (can have and coordinate multiple XBee's connected to this one).

Coordinator in AT mode is difficult as you have to enter command mode and set the "to" address every time you want to write to a different XBee.

API mode requires specific messages to be sent to it, to send your data messages, including the to address, network address, option bytes and a calculated checksum.

Slightly off-topic, but it helps to know what all the different function set's do, and which one you require.

Remember too that when programming from one to the other (AT to API, or changing the baud rate), X-CTU will not find the XBee after programming it (to reload the AT commands) until you go back and select "API mode" or modify the baud rate and reconnect.
By stevech
#84802
My experience is that with series one, in the API mode, a +++ sequence will get an OK response and you can do AT commands.

IMO most student/hobby apps should not use meshing- but rather, simple star or peer to peer (no coordinator needed).
By rtaubitz
#84814
stevech wrote: IMO most student/hobby apps should not use meshing- but rather, simple star or peer to peer (no coordinator needed).
Agree'd, that's what I was trying to get at, use the default "Endpoint AT" firmware, unless you specifically need a different feature set.

:)
By ahare
#84823
oh great! why should it happened or we simply cant restore the firmware?

i've tried whatever every suggestions that i got from here or other forum, nothing could fix the same problem. isnt that funny? same problem but different solution? work fine for one and not for others?

btw, the problem is: couldnt communicate with modem. if api, it shows unknown version and couldnt write (whatever i tried, mine is series 2). and if not api, i even couldnt get any info at all (unable to communicate...). however, if try to reset (pin 5 & 10), it says lost communication...


arrrrrrrr, 2 out 3 are gone!!!!

i know many of u face the same problem... any new suggestions?

i would appreciate any suggestions :(
By angelsix
#84825
I had same issue as you and almost all mine were bricked and got sent back to Digi, one managed to get restored successfully using the usual techniques.

Its pretty basic, if you can't re-flash the firmware using the correct technique, then its basically a gonner, Digi couldn't offer me any other solutions themselves either other than to send them back.
By rtaubitz
#84827
Are you guys changing the baud rate's or anything and then not changing X-CTU to match the new one? The default is 9600.
By angelsix
#84829
When reflashing the baud rate doesn't matter as the base rate uses 9600... at least thats what my tests showed when I used them. Mine were originally flashed at 112k I think it is, and the one that was reflashed fine was reflashed at 9600, and I tried every rate for the others to no avail.
By rtaubitz
#84830
Sorry, you're right, the bootloader for uploading firmware is at 115,200, once re-flashed the default is 9600.

Section 8.4 of the manual:
the module will send the Ember boot loader menu out the DOUT pin at 115200bps.
If the upload is interrupted with a power cycle or reset event, the EM250 will detect an invalid application image and enter bootloader mode. The entire ebl image should be uploaded again to recover.
Maybe the XBee is just always entering the bootloader, thinking the image is invalid? Can you see "BL >" at 115200? (When the xbee is powered up or reset)
By ahare
#84832
rtaubitz wrote:Are you guys changing the baud rate's or anything and then not changing X-CTU to match the new one? The default is 9600.

nope, not at all. both com port and xctu baud are same and 9600. so, how digi fixed by themselves and what is that 'usual technique'? why not we can do it by our self? i am saying because, if it is so frequent, it should be easy to solve!

a complete nightmare!
By ahare
#84834
oh, sorry forgot to mention earlier...

could that be the reason that when the firmware of xbee get corrupted, it automatically changed (or become zero) its own baud rate? so that no communications can be made? is there anyway to make a proper channel?
By rtaubitz
#84881
Did you try to see if anything shows up when plugging the XBee in while watching the port at 115200bps? If it comes up with "BL >" you're in luck.