Can't flash Xbee Series 1 DigiMesh modules

[arnuschky]

I tried to flash a Xbee Series 1 DigiMesh module, but unfortunately it does not work.

I would be very interested in this program as it allows us to streamline our (hobbyist) production - having a person click around in X-CTU is not really an option.

I tried with and without API mode. Both times, the program responds with "xbfwup: failed to read bootloader prompt". Also I noticed that the firmware zip contains to files, a smaller .mxi file and a larger .ehx file (~133kb). I tried with the .ehx file.

If you could help me out with this problem or point me in the direction of a solution, that would be awesome. Of course, I am happy to test any changes on my own responsibility.

[roysjosh]

Hello,

What are you using to connect your computer to your xbee?

Hm, the series 2 xbees have .ebl files. I'll have to look and see if those are the same as an .ehx file.

Thanks,

Josh

[arnuschky]

Hey,

the Sparkfun Xbee explorer USB https://www.sparkfun.com/products/8687

thanks for the super-fast reply!
Arne

On Wed, 06 Feb 2013 11:50:41 -0800 roysjosh notifications@github.com
wrote:

Hello,

What are you using to connect your computer to your xbee?

Hm, the series 2 xbees have .ebl files. I'll have to look and see if
those are the same as an .ehx file.

Thanks,

Josh

---

Reply to this email directly or view it on GitHub:
#4 (comment)

[roysjosh]

Alright, please give these instructions a try and see if you can get a bootloader prompt:
http://www.digi.com/wiki/developer/index.php/Bootloader_to_force_XBee_reflash
If you do, you can enter 2 to continue the xbee boot process. I hope that you are successful, since I have not found a reference to the bootloader in the series 1 docs yet.

[arnuschky]

Hey,

I tried the instructions but this didn't work either. Apparently, it
should also work on Xbee Series 1. I am suspecting that it might be an
issue with the Xbee-USB connector that I am using (Sparkfun Explorer).
It does not have a reset button, so I have to connect GND to RST
manually for a reset. Maybe that's the reason. Do I have to reset the
module also for your program?

Cheers,
Arne

On Wed, 06 Feb 2013 17:59:06 -0800 roysjosh notifications@github.com
wrote:

Alright, please give these instructions a try and see if you can get
a bootloader prompt:
http://www.digi.com/wiki/developer/index.php/Bootloader_to_force_XBee_reflash
If you do, you can enter 2 to continue the xbee boot process. I hope
that you are successful, since I have not found a reference to the
bootloader in the series 1 docs yet.

---

Reply to this email directly or view it on GitHub:
#4 (comment)

[roysjosh]

Hm, I have a https://www.sparkfun.com/products/8687 which is what I've been using to test. It's possible that X-CTU is using another method to enter the bootloader. Digi has some proprietary/magic command which unfortunately is different for each chip (based on the serial) to do this... maybe if I ask nicely they will tell me the algorithm.

In short, if the series 1 module is unable to enter the bootloader using the current method, we are at the mercy of Digi telling us (or not) their secret.

[arnuschky]

Yes, this seems to be the case. I assumed that there's a unified method
as they aren't mentioning anything about different models on their
"how to unbrick" page. Well, I should stop to expect companies making
sense, I guess.

I'll open a support request as well and we'll see what it gives.

Thanks anyways for your awesome support!
Arne

On Fri, 15 Feb 2013 07:17:52 -0800 roysjosh notifications@github.com
wrote:

Hm, I have a https://www.sparkfun.com/products/8687 which is what
I've been using to test. It's possible that X-CTU is using another
method to enter the bootloader. Digi has some proprietary/magic
command which unfortunately is different for each chip (based on the
serial) to do this... maybe if I ask nicely they will tell me the
algorithm.

In short, if the series 1 module is unable to enter the bootloader
using the current method, we are at the mercy of Digi telling us (or
not) their secret.

---

Reply to this email directly or view it on GitHub:
#4 (comment)

[arnuschky]

Sorry, I forgot to get back to you. The support request wasn't exactly successful:

"That example is for a em-250 Ember micro used on a ZigBee devices. You are using a Freescale Micro on a DigiMesh devices. They do not operate in the same manner. Nor do they have the same menus or options. Xbee is a form factor, meaning all pins are electricaly related, but that does not mean that all functions are the same. This is a more generic method of recovery: http://todigi.blogspot.com/2010/05/xbee-obituaries-xbee-returns-from-grave.html"

I asked them again t how to enter the bootloader, but they replied with a similar evasive answer. So no luck! :(

Thanks anyways!

[roysjosh]

Hello,

I found some documentation on what needs to be done to get the magic "go to bootloader" command working. Right now it only works from AT mode (although it can flash a module to API). I'll get it working for both shortly. Please give it a try if you have time.

Thanks!

[arnuschky]

Awesome! I will try it as soon as I have the time, hopefully tomorrow. Flashing from AT to API mode is already sufficient for me as the modules are delivered in AT mode.

[arnuschky]

Does not work unfortunately. :(

Entering AT command mode...
Entering bootloader...
.
xbfwup: failed to read bootloader prompt

XBee modules are delivered in AT mode, right?

[roysjosh]

There should be a SL: line in there. I pushed this new commit to a new branch, newfwup.

[arnuschky]

Ah, I missed the branch, sorry. Here we go:

Entering AT command mode...
Entering bootloader...
SL: 408C04C5
....................
xbfwup: failed to read bootloader prompt

After this, I tried verifying the firmware using X-CTU, but unfortunately I can't even communicate anymore with the module.

[roysjosh]

An unplug/replug should get it reset to defaults again. Hmm... the only other thing I can think of is that series 1 uses a different terminal speed in the bootloader. Would you mind trying these values in src/bin/xbfwup.c line 374 (the cfsetspeed): replace B115200 with B57600, B38400, B19200 and B9600 attempting a flash each time.

[roysjosh]

http://www.digi.com/support/kbase/kbaseresultdetl?id=3402#XBee says that 38400 is the one to go with. http://www.klozoff.ms11.net/maxstream/xbee-bootloader-info.txt indicates that the bootloader protocol might be different on series 1 compared to series 2. If 38400 still doesn't give you anything, give me a few days to figure out what I need to send to the series 1 bootloader.