I have an XBee PRO S2C programmable module (without the development kit - too pricy!) and need some help understanding how software transfers and the bootloader work.
I have been able to access the bootloader via a legacy version of X-CTU, and transferred a .bin file (an example Digi XBee project in CodeWarrior) across to the module via XModem Transfer. After resetting the module, I have confirmed the program has transferred and is running on the device. Now that I’ve completed this test, I would like to write my own program and transfer this in the same way to the XBee module. However, I’m not not certain how to transfer the file across to the device as I can no longer access the bootloader…
I have found the below link and followed the instructions, but it has not worked so far (this may be for a different issue):
Does anybody have any advice as to progress with this? Have I overwritten the bootloader with the file I transferred?
If the advice is to give up using this method and purchase a debugger/programmer, where can I find the correct hardware without purchasing the full development kit?
From the sounds of it when you uploaded your application , you replaced the one that was on there with yours. This erased the bootloader app. Your only option now is to use a bdm programmer.
Hi I’ve had the same issue that once an application has been loaded to a brand new module, accessing the bootloader can be a challenge. Make sure your speed settings are correct and that the shield device you are using to connect the XBee module to the computer has a “reset” button that actually resets the module properly.
If you just used one of the example programs within the SDK and uploaded a .bin file to the module, that shouldn’t have overwritten the bootloader.
I myself use following Node.js based tool to access the bootloader: http://github.com/exsilium/pxbee-fwup.js
Here’s a terminal recording of how it works: https://asciinema.org/a/Ktx4JCASIvGbVB8tL1N17tlSH
Having checked the bootloader xmodemReceive function, it seems that it’s designed not to touch the bootloader memory area:
// Commit these PACKET_SIZE bytes to flash
// Program this 128/64 byte block but only if it won't
// overlap the bootloader area.