search

roysjosh / xbee-comm

XBee communication libraries and utilities
GNU General Public License v3.0
38 stars 7 forks source link

Can't flash Xbee Series 1 DigiMesh modules #4

Open arnuschky opened 11 years ago

arnuschky commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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: https://github.com/roysjosh/xbee-comm/issues/4#issuecomment-13201391

roysjosh commented 11 years ago

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 commented 11 years ago

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: https://github.com/roysjosh/xbee-comm/issues/4#issuecomment-13217314

roysjosh commented 11 years ago

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 commented 11 years ago

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: https://github.com/roysjosh/xbee-comm/issues/4#issuecomment-13611039

arnuschky commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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

arnuschky commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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.

arnuschky commented 11 years ago

Module appears to be bricked; unplugging and replugging didn't change anything. Will try to recover it later.

roysjosh commented 11 years ago

Yikes, sorry about that. Check out the link I sent earlier: http://www.digi.com/support/kbase/kbaseresultdetl?id=3402#XBee which is actually a recovery guide of sorts. It looks like the series 1 radios do, indeed, have a different bootloader protocol. I'll see if I can figure it out.

arnuschky commented 11 years ago

Recovery doesn't work for some reason. I used successfully before, but now the "user action required" dialog vanishes straight away with the message "Restore Defaults cancelled by user". Weird. Did your program maybe change the baud rate or enabled API mode?

arnuschky commented 11 years ago

Never mind that, "deep recovery" seems to have worked. It helps to read a page fully before replying. :)

arnuschky commented 11 years ago

With B38400:

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

After this module was bricked again.

roysjosh commented 11 years ago

I've done a bit of research and found two things: first, the .ehx file as described by Digi was said to be encrypted, and it actually is. Second, the bootloader protocol is different. Both of these will need to be implemented before you can attempt another flash. I'll keep you up to date. Glad you were able to unbrick the xbee!

arnuschky commented 11 years ago

Yes, me too. But I would have happily wasted an XBee if that would help you with the development. Thanks for the great support and the persistence! Let me know if I should test the new bootloader and/or the encryption.

On Thu 25 Jul 2013 12:58:42 CEST, roysjosh wrote:

I've done a bit of research and found two things: first, the .ehx file as described by Digi was said to be encrypted, and it actually is. Second, the bootloader protocol is different. Both of these will need to be implemented before you can attempt another flash. I'll keep you up to date. Glad you were able to unbrick the xbee!

— Reply to this email directly or view it on GitHub https://github.com/roysjosh/xbee-comm/issues/4#issuecomment-21546685.

romixlab commented 10 years ago

Hello, I have exactly the same problem with XBP24-AWI modules (Digi Xbee Pro on the front side). But also I can't read configuration, X-CTU says "Modem configuration file not found" and update doesn't work... A year ago all worked fine (read/write config) Have any thoughts?

arnuschky commented 10 years ago

Hey,

weird. I managed to write/update all of my "bricked" modules with X-CTU using Digi's recovery method (the one you have sent me)

Sorry I can't help you further. Arne

On Fri 29 Nov 2013 13:27:43 CET, romixlab wrote:

Hello, I have exactly the same problem with XBP24-AWI modules (Digi Xbee Pro on the front side). But also I can't read configuration, X-CTU says "Modem configuration file not found" and update doesn't work... A year ago all worked fine (read/write config) Have any thoughts?

— Reply to this email directly or view it on GitHub https://github.com/roysjosh/xbee-comm/issues/4#issuecomment-29513559.

romixlab commented 10 years ago

Thanks for the quick reply) I found modem configuration files for my modules, X-CTU now can read/write settings. But when I try to flash firmware (even the same version) it prints: "Programming modem...Lost communication with modem" Tried with 3 modules

arnuschky commented 10 years ago

Weird. And you can't even program with X-CTU? This is the technique that worked for me: http://www.digi.com/support/kbase/kbaseresultdetl?id=3402 (section Xbee, "If the above steps failed..")

On Sun 01 Dec 2013 08:43:46 CET, Roman wrote:

Thanks for the quick reply) I found modem configuration files for my modules, X-CTU now can read/write settings. But when I try to flash firmware (even with the same version) it prints: "Programming modem...Lost communication with modem" Tried with 3 modules

— Reply to this email directly or view it on GitHub https://github.com/roysjosh/xbee-comm/issues/4#issuecomment-29569065.

romixlab commented 10 years ago

Turned out my USB<->USART converter, from which i powered my XBee's, had a problem with power Now I got another message about difference in baud rates... But "Info" message disappears when I connect the module=)

matthijskooijman commented 9 years ago

Not sure if you guys are still interested in this, but I just stumbled upon Digi's own C library, which seems to have support for firmware updates. I couldn't find if this also includes Digimesh modules, but here's the code in case it is useful: https://github.com/digidotcom/xbee_ansic_library/blob/master/src/xbee/xbee_firmware.c

Rohankhairnar123 commented 6 years ago

I have problem about Xbee module not detecting in X-CTU. if you have any suggestion please let me know. thank you