Hi…
I have the Slaesh Zigbee USB stick for years now which was working perfectly until I added many new devices. I had never flashed it with a new firmware, so I thought it was best to try a new firmware before searching for other solutions. I accidentally flashed the launchpad version of the firmware instead of the RB version… The flash/verification was successful, but the stick no longer works. I’m trying to flash the correct firmware but it seems it cannot enter bootloader mode… Anything I can do to fix this, or is the stick dead ? Any help much appreciated…
Grounding the BSL pin ( usually B0 GPIO0)
Plugging it in
Flashing with the correct firmware.
BL_EN = Bootloader Enable
That is exactly the pin you need to short to GND to enter the ROM bootloader mode.
Disconnect from power
short it while power for 2 to 3 seconds
If you see the LED remain off and the device shows up as a generic USB serial port, this is normal.
python3 cc2538-bsl.py -p /dev/ttyUSB0 -evw C2652RB_coordinator_20231226.hex
if you are using windows change /dev/ttyUSB0 to your COM port
Thank you for the detailed reply! However I tried it and again it won’t flash the RB firmware. It says “CmdException: Timeout waiting for ACK/NACK after ‘Synch (0x55 0x55)’”
Just to confirm, my USB device is the one in the image. I connected the BL_EN to the GND two pins next to it WHILE inserting it into the USB port. Kept it bridged for 3 seconds and removed the jumper wire, and then tried to flash
Near the USB connector, there’s a pushbutton likely RESET and two pads next to it labeled as GND and BLS or BL_EN these are the critical ones.
Some sticks draw more power during bootloader, try using a USB hub or another USB port on your machine, preferably one directly on the motherboard.
no blinking LEDs is usually a good sign
try forcing the bootloader
linux
python3 cc2538-bsl.py -p /dev/ttyUSB0 --bootloader-active-high --force -evw firmware.hex
windows
python3 cc2538-bsl.py -p com3 --bootloader-active-high --force -evw firmware.hex
just make sure you are using the correct port
for linux run
dmesg | grep ttyUSB
on windows
Press Win + X, then select Device Manager and check the com secction
I’m not sure which pad you refer to… Please see attached images, closeups of the two pushbuttons, and the same location but on the backside. There are pads near both the pushbuttons. I dont want to jump the wrong ones… could you please tell me which ones I need to connect together?
Many many thanks!
i think in yours the BL is the button next to RST ,
try with that one
I tried holding the pushbutton (BL) pressed while connecting to USB, I tried using a jumper wire to connect the two flat pads near the RST (but on the back surface) and also the ones near the BL on the back surface again, and I tried using a jumper wire connecting the BL_EN hole (4th from bottom to top on the image in your answer) and GND (2nd hold from bottom to top)…
Nothing works…
I also tried holding the BL button, while pressing the RST button, then releasing the RST button and after 3 seconds releasing the BL button. Again no game…
do you remember the command you use ? when you write the launchpad version
python .\cc2538_bsl.py -p “COM5” -evw “.\CC1352P2_CC2652P_launchpad_coordinator_20250321.hex”
did you try keep holding the BL button and send command?
python cc2538-bsl.py -p COM5 -e -v -w --force CC2652RB_coordinator_*.hex
if that dont work the only other option is use a debugger like
TI XDS110 but are expensive
Tried it and got the same error:
Opening port COM5, baud 500000
Reading data from .\CC2652RB_coordinator_20240710.hex
Your firmware looks like an Intel Hex file
Connecting to target…
Traceback (most recent call last):
File “D:\Users\Christos\slaesh\cc2538-bsl\cc2538_bsl\cc2538_bsl.py”, line 1161, in main_cli
if not cmd.sendSynch():
~~~~~~~~~~~~~^^
File “D:\Users\Christos\slaesh\cc2538-bsl\cc2538_bsl\cc2538_bsl.py”, line 383, in sendSynch
return self._wait_for_ack(“Synch (0x55 0x55)”, 8)
~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
File “D:\Users\Christos\slaesh\cc2538-bsl\cc2538_bsl\cc2538_bsl.py”, line 276, in _wait_for_ack
raise CmdException(“Timeout waiting for ACK/NACK after ‘%s’”
% (info,))
CmdException: Timeout waiting for ACK/NACK after ‘Synch (0x55 0x55)’
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File “D:\Users\Christos\slaesh\cc2538-bsl\cc2538_bsl\cc2538_bsl.py”, line 1297, in
main_cli()
~~~~~~~~^^
File “D:\Users\Christos\slaesh\cc2538-bsl\cc2538_bsl\cc2538_bsl.py”, line 1292, in main_cli
if QUIET >= 10:
^^^^^
UnboundLocalError: cannot access local variable ‘QUIET’ where it is not associated with a value
is your com correct?
just to make sure because i write that com5
press windows + x → device manager → check ports and coms
also make sure you’re using a data-capable USB cable. Some USB cables only provide power and not data.
on your command promt run it as administrator
Its the same cable that I used when I flashed the launchpad version, so data is ok… trying admin
last one i promise , what version of python do you have ?
python --version
or
python -V
No go even with admin…
Python version: 3.13.3
Thank you for trying to help. Much appreciated
you have all right , so i guess the only option is a debugger , but will be cheaper to buy i new one , so sorry i wasn’t able to help you there
i hope someone with more knowledge that me can help you here
the sonoff Zigbee 3.0 USB Dongle Plus V1 (ZBDongle-P) is good i have one arround for testing and i cant complain , im current using
zzh Multiprotocol RF Stick
for a few years with not problem but its gonna be obsolete in a couple of years
I purchased that as well to configure it as a router on the other floor, but I have reflashed it as coordinator now that the slaesh stick is dead I got an smlight POE one to use as a router, still expecting it to be delivered.
But the slaesh stick was operating without any issues at all, before I flashed the launchpad version by mistake …
It happend even to the most advance users is a learning experience