Closed stevenlovegrove closed 6 years ago
Hi! Thanks for reporting this.
Can you also send the specific radio model number you are using? Do you have a programmable XBee S2C?
The documentation you are referring to seems to describe the firmware upgrade steps of the radio firmware, not the HCS08 application firmware... the .ebl file that is expected is the ZigBee radio firmware.
So upgrading the radio firmware via the bootloader menu is an interesting new feature that can be added, it surely expects a different payload but should work otherwise similarly to the HCS08 application frimware update. I'm still on 405E
so I need to upgrade to see if I also get the radio firmware upload option available and test this out.
I thought mine was programmable, but let's see if you agree! The radio has ic: 1945a-s2cth xb24cz7wit-004-revF written on it
Hmm, is it only 003's that are programmable?
Unfortunately, it's not a programmable variant of the module. The programmable variants have a B
designation at the end of the module and indeed, for the programmable variants, there's no 004 revision made. The equivalent programmable module for your radio would be xb24cz7witB-003
Here's the full list of S2C SKUs still available for reference. Digi is known for it's confusing list of model numbers and products 😃
That explains why I had to much trouble programming it! Thanks for the information - I'll order another and try again!
Just FYI, Digi is in progress of phasing out the S2C line (considered now legacy) which is now succeeded by XBee3 ZigBee line of modules.
Little is still known about them because the documentation they are currently providing is incomplete. The TH version of the modules should be available from Mouser end of this month. Based on the specifications it looks like they all include the HCS08 CPU (thus will be programmable) and in the future they will also be programmable via MicroPython, which will run directly on the EFM32 radio chip (Firmware of that will be coming during 2018).
Worth also noting is that the wire antenna models seems to have been abandoned, there's one with a PCB trace antenna and then with U.FL and SMA connectors.
I haven't been able to play with XBee3, but waiting for this module to stock at mouser.
Anyways, thought to let you know that the world is shifting to the new radios soon and if your project can allow delays, I think it's worth waiting for the new modules. My $0.02 :) Cheers! 🍻
I ended up buying an XBP24BZ7WITB003-revL which worked perfectly with your uploader and blink-led project, thanks! :)
I have a sparkfun xbee explorer dongle which looks as though it should have pin7 connected to the RSSI LED, but that didn't flash. I had to use a multimeter on that pin, and wait around 30 seconds for the device to boot or something before I saw the pin toggling between high and low. Additionally, the interval on my board would appear to be around 500ms, not 125ms.
Hi @stevenlovegrove, thanks for the feedback and congrats! I'm glad you got it working!
I checked that the blink-led project still default to the S2B module - I should probably change that... Can you please change the following define to CONFIG_XBEE_S2CTH
, clean and compile. I hope that helps! :smile:
Cheers! :beers:
Firstly, thanks for putting these XBee examples and fw updater online!
I have a Digi XBee S2CTH and have successfully compiled your blink_led repo (after updating the #define CONFIG_XBEE_S2CTH as per your instructions), but am having trouble flashing to my device.
When using your fwup tool, the bootloader and application version string are both empty and it outputs some slightly jumbled text between the '======' characters. Doing some reading, I found https://www.digi.com/resources/documentation/digidocs/pdfs/90002002.pdf which describes a slightly different upload sequence than you have implemented (in particular, '1' to begin XModem transfer, not 'F'). I'm guessing my device has a different version of the bootloader than you are using. If I modify your script to send '1' (or use
screen
with exec !! sx blink_led.abs.bin), I receive NAK's from the boot loader which seems to indicate CRC failures or something. This makes me think that maybe the burner is generating the wrong file type or something? In the documentation, it's stated that ebl files are expected and I don't know if the burner needs further configuration to output something like that.XCTU is able to talk with my device and modify its firmware. It reports that I currently have loaded 'ZIGBEE TH Reg' version '4060'.
Do you happen to have any ideas / suggestions?
Thanks!
Here's a gist with the output after changing the 'F' to '1' to initiate transfer (otherwise it just freezes whilst 'initiating transfer'
https://gist.github.com/stevenlovegrove/89fb14a5b9e1ff08961ba4da90d1f338#file-gistfile1-txt