Automatically start BSL mode on Itead Sonoff USB stick

[sshaikh]

I successfully used this script to flash an "ITead Sonoff Zigbee 3.0 USB Dongle Plus adapter based on Texas Instruments CC2652P", so thank you for the script.

There are two ways to put this model into BSL mode, pressing the button on the board (typically requiring assembly) or running a python script to do it via software.

I don't know if this is a feature of the stick, the UART bridge or the CC2652P, but I've attached the script for your perusal, as it may be useful for cc2538-bsl to do this when appropriate.

[sshaikh]

uartLog.txt

This is the Python script originally provided. It is designed to be run on Windows but can be made generic by deleting the COM suffix attached to the name when selecting the device.

[JelmerT]

Thanks for that script @sshaikh . It looks like this is a simple toggle via the RTS and DTS lines.
This script should already be able to do this on its own, have you tried playing with these options?

--bootloader-active-high Use active high signals to enter bootloader
--bootloader-invert-lines Inverts the use of RTS and DTR to enter bootloader

[sshaikh]

I have no idea how I missed those. I'll assume that works, unless you want a positive confirmation?

[sshaikh]

FWIW neither of these options (or any combination of them) enabled BSL:

Opening port /dev/ttyUSB0, baud 500000
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

[JelmerT]

Next step would be to check the schematic of the USB dongle and see how the RTS and DTR lines are connected to make sure they're toggled correctly. Maybe probe them with both scripts and see the difference.
Do you know if schematics are available somewhere?
Which serial-USB chip are they using?

[sshaikh]

lsusb reports:

Cygnal Integrated Products, Inc. CP2102/CP2109 UART Bridge Controller [CP210x family]

More information here:

https://itead.cc/product/sonoff-zigbee-3-0-usb-dongle-plus/

But shouldn't the script be explicit about what is required? If this is out of the scope of bsl, then I'm happy to use the peculiar uartlog script for my purposes.

[JelmerT]

This is the code in their script that enters the bootloader:

def enterBoot(serialPort, delay=False):
    # delay is a workaround for bugs with the most common auto reset
    # circuit and Windows, if the EN pin on the dev board does not have
    # enough capacitance.
    # 如果开发板上EN管脚没有足够电容
    last_error = None

    # issue reset-to-bootloader:
    # RTS = either CH_PD/EN or nRESET (both active low = chip in reset
    # DTR = GPIO0 (active low = boot to flasher)
    #
    # DTR & RTS are active low signals,
    # ie True = pin @ 0V, False = pin @ VCC.
    setDTRState(serialPort, False)  # IO0=HIGH
    # setDTRState(serialPort, True)   # IO0=LOW
    setRTSState(serialPort, True)  # EN=LOW, chip in reset
    time.sleep(0.1)

    setDTRState(serialPort, True)  # IO0=LOW
    setRTSState(serialPort, False)  # EN=HIGH, chip out of reset

    time.sleep(1)

    setDTRState(serialPort, False)  # IO0=HIGH, done
    setRTSState(serialPort, False)
    time.sleep(1)

    return last_error

So it looks like both pins are active low, and RTS is connected to reset and DTR is connected to the bootloader pin. Which should be the same as in the standard configuration in this script.
So the only difference I'm seeing is the extra delays in their script.
Try adding some delays in the same spots, and see if that makes it work.

[sshaikh]

Just in case I've done it incorrectly, I was just adding the --bootloader-active-high parameter to the normal flashing command.

[JelmerT]

Just in case I've done it incorrectly, I was just adding the --bootloader-active-high parameter to the normal flashing command.

yes that's the correct way, but it looks like you shouldn't need it. (but still try it, together with --bootloader-invert-lines)

I'm guessing the delays are the issue here. You can verify with a scope on the reset and bootloader lines, or just try it with some trial and error.

[Hedda]

Nice with option to automatically try both high and low signals to make Sonoff enter bootloader when Auto BSL is supported:

https://community.home-assistant.io/t/itead-sonoff-zigbee-3-0-usb-dongle-plus-adapter-based-on-texas-instruments-cc2652p/340705

Koenkk/zigbee2mqtt#8840

"Auto BSL" will also be supported by upcoming zzhp and zzhp-lite adapters by Electrolama which will all use FT231X by FTDI:

https://electrolama.com/radio-docs/bsl/#auto-bsl

I have also confirmed that running the attached uartLog.py script does indeed make ITead's Sonoff Zigbee 3.0 Plus adapter enter bootloader mode and after that I could flash it directly with python cc2538-bsl.py -p COM5 -evw CC1352P2_CC2652P_launchpad_coordinator_20210708.hex (also tested with electrolama fork using the commans llama-bsl.py -p COM5 -b 115200 -evw CC1352P2_CC2652P_launchpad_coordinator_20210708.hex) without having open its enclosure and pressing the BRL button which I think is very convenient.

As a bonus the uartLog.py script also lists all active COM ports on MS Windows (tested on Windows 10) so only have you enter the number of the COM port, but note that the script is currently hardcoded for Windows COM ports so would need to be modified before it can be used under Linux.

https://sonoff.tech/wp-content/uploads/2021/09/Zigbee-3.0-USB-dongle-plus-firmware-flashing-1-1.docx

Attatched: uartLog.zip

PS: ITead/Sonoff originally posted this docx doc here -> https://sonoff.tech/product-review/zigbee-3-0-usb-dongle-plus/

[JelmerT]

@Hedda we're trying to not have to rely on uartlog.py though. Can you confirm that cc-2538.py can start the bootloader?

[Hedda]

@Hedda we're trying to not have to rely on uartlog.py though.

I know, only wanted to let you know that I can confirm that the auto BSL feature is supported by the hardware and preflashed firmware, even though it is currently not working in the cc2538-bsl.py script. That is, as proof-of-concept I can confirm that uartlog.py can start the bootloader so it should at least techically be possible to get it working.

Can you confirm that cc2538-bsl.py can start the bootloader?

No, but I can confirm that cc2538-bsl.py can currently not start the bootloader, (and the same result with llama-bsl fork of it). I have not tried testing different delays in the cc2538-bsl.py script. Other than trying with and without --bootloader-invert-lines I have only tested changing it to different baud rate speeds).

So far only tested on Windows OS (Windows 10 operatingsystem):

C:\Temp\cc2538-bsl-master>python cc2538-bsl.py -p COM5 -evw CC1352P2_CC2652P_launchpad_coordinator_20210708.hex
Opening port COM5, baud 500000
Reading data from CC1352P2_CC2652P_launchpad_coordinator_20210708.hex
Your firmware looks like an Intel Hex file
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

C:\Temp\cc2538-bsl-master>python cc2538-bsl.py -p COM5 -evw --bootloader-invert-lines CC1352P2_CC2652P_launchpad_coordinator_20210708.hex
Opening port COM5, baud 500000
Reading data from CC1352P2_CC2652P_launchpad_coordinator_20210708.hex
Your firmware looks like an Intel Hex file
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

C:\Temp\cc2538-bsl-master>python cc2538-bsl.py -p COM5 -evw --bootloader-active-high CC1352P2_CC2652P_launchpad_coordinator_20210708.hex
Opening port COM5, baud 500000
Reading data from CC1352P2_CC2652P_launchpad_coordinator_20210708.hex
Your firmware looks like an Intel Hex file
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

[Hedda]

Which serial-USB chip are they using?

I can confirm Sonoff USB Plus dongle uses Silicon Labs CP2102N (Xpress/USBXpress Family) so at least that is correct in ITead's specifications, (where several other info look to be wrong as if they just copied mix of info from CC2531 and Electrorama's zzh).

https://www.silabs.com/documents/public/data-sheets/cp2102n-datasheet.pdf

CP2102N should be the same functionality as CP2104 which is end-of-life. (CP2102N are now common in ESP32/ESP8266 boards).

For both of those need to use CP210x USB to UART Bridge VCP Drivers if using Windows OS:

https://www.silabs.com/developers/usb-to-uart-bridge-vcp-drivers

One wrong is noted that ITead themselves are referring to the wrong device drivers for it on their own page, reviews and docs:

https://itead.cc/product/sonoff-zigbee-3-0-usb-dongle-plus/

https://sonoff.tech/product/diy-smart-switch/sonoff-dongle-plus/

https://sonoff.tech/product-review/zigbee-3-0-usb-dongle-plus/

https://sonoff.tech/wp-content/uploads/2021/09/Zigbee-3.0-USB-dongle-plus-firmware-flashing-1-1.docx

[Hedda]

Perhaps not related but noted Silabs posted a few erratas for CP2102N listing bugs and workarounds so they might be relavant:

https://www.silabs.com/documents/public/errata/cp2102n-errata.pdf

Among other things it list these errata/bug:

3.8 CP2102N_E106 – DTR/RTS behavior when port is closed
Description of Errata
CP2102N does not reset DTR/RTS when port is closed.
Affected Conditions / Impacts
When a USB host closes the CP2102N’s virtual comm port, the DTR and RTS flow control signals will remain in the same state as they were before port closure, instead of being deactivated.
Workaround
Applications interfacing with the virtual comm port must manually deactivate DTR and RTS signals through comm APIs unless the installed host driver performs this step automatically. The Windows 10 VCP Universal driver version 10.1.3 and later and Windows VCP driver version 6.7.6 and later automatically deactivate DTR and RTS when the port is closed.
Resolution
This issue is resolved in A02 devices.

3.6 CP2102N_E104 – IO Exception in .NET Applications when Manually Controlling RTS
Description of Errata
The CP2102N uses the incorrect byte of the SERIAL_HANDFLOW structure (https://msdn.microsoft.com/en-us/library/windows/hardware/jj680685(v=vs.85).aspx) to control the RTS signal. Instead of looking at the first byte of FlowReplace, the device is reading the first byte of the XonLimit and interpreting that as the first byte of FlowReplace. Applications written in .NET set the Xon/Xoff limits to 160, equal to 0xA0, which the CP2102N interprets as hardware flow control, and so it returns an error when manually setting RTS.
Affected Conditions / Impacts
Applications written in .NET will see IO exceptions when attempting to manually set or clear RTS on the CP2102N.
Workaround
For .NET applications, it is possible to create a software workaround for this issue by setting the XON/XOFF limits to 0x00.
Because of additional .NET limitations, the workaround also has to enable hardware flow control, enable the port, then switch to none. These changes enable the CP2102N to properly set or clear the RTS signal manually. An example demonstrating this can be found in the following Knowledge Base article: https://www.silabs.com/community/interface/knowledge-base.entry.html/2017/11/10/cp2102n_e104_io_ex-YqAX.html If the serial port is configured in C++, directly set the DCB XON/XOFF limits to 0x00 as a workaround for this issue.
Resolution
This issue is resolved in A02 devices.

[Hedda]

ESP32/ESP8266 adapters with CP2102N A01 revision chips seem to have had similar issues on Windows OS. Some reports for those ESP devices say the issue is fixed in hardware on new CP2102N A02 revision chips and later VCP drivers for Windows OS.

For CP2102N A01 revision chips they worked around these issues by adding more and longer delays as JelmerT suggested.

Also, looks like Sonoff might got part of boot mode reset code logic for uartLog.py script from esptool and esp_rfc2217_server:

https://github.com/espressif/esptool/blob/master/esp_rfc2217_server.py#L70

https://github.com/espressif/esptool/blob/master/esptool.py#L521

espressif/esptool#136

espressif/esptool#290

espressif/esptool#399

espressif/esp-idf#3925

https://www.esp32.com/viewtopic.php?t=11913

[Hedda]

@guozi7788 Any chance you could report this issue to relevant personnel at ITead/Sonoff and get them to submit a fix in a patch?

Summery, "Auto BSL" is currently not working in the c2538-bsl script on Windows OS (Windows 10) with the SONOFF Zigbee 3.0 USB Dongle Plus by ITead even though its hardware does support "Auto BSL", this is likely due to the CP2102N USB-to-UART chip would need some additional delays added to the script, probably because of bugs in hardware or some issue Microsoft serial interface in Windows.

Please inform ITead/Sonoff that c2538-bsl is the most popular firmware upgrade script used by the community for flashing Texas Instruments based Zigbee USB dongles and having "Auto-BSL" (automatic reset and boot to bootloader via software) fully supporting SONOFF Zigbee 3.0 USB Dongle Plus by ITead would make it possible for the script to automatically enter BTL boot mode and perform the firmware upgrade without the need for to open the enclosure which would make the whole firmware upgrade procedure more convenient and user-friendly.

That is, having "Auto-BSL" being support in c2538-bsl for the SONOFF Zigbee 3.0 USB Dongle Plus by ITead would make the "uartLog.py" script recommended in ITead/Sonoff's existing firmware upgrade instructions obsolete and make it so much simpler for new users and beginners to upgrade the firmware using this c2538-bsl script as an easier to use tool. Also note that the c2538-bsl is a cross-platform script so it should work on all operating systems.

https://sonoff.tech/wp-content/uploads/2021/09/Zigbee-3.0-USB-dongle-plus-firmware-flashing-1-1.docx

The current instructions from ITead/Sonoff suggest using the "uartLog.py" script attached in that Word document to enter the bootloader and then use TI's Flash Programmer 2 to flash the firmware, both of which are today only compatible with Microsoft Windows operating system, and that combination is not very convenient or easy to use, so not user-friendly at all.

[guozi7788]

@Hedda
thanks for your advice.

uartLog.py is only used as a production testing tool to verify whether the dongle enters the boot mode, and it has not been given more uses.

As far as I know, the product manager is evaluating your needs，and you can check with your previous contacts for relevant progress.

[Hedda]

uartLog.py is only used as a production testing tool to verify whether the dongle enters the boot mode, and it has not been given more uses.

@guozi7788 Actually, uartLog.py as a zip file with it is attached to https://sonoff.tech/wp-content/uploads/2021/09/Zigbee-3.0-USB-dongle-plus-firmware-flashing-1-1.docx which is linked to from https://sonoff.tech/product-review/zigbee-3-0-usb-dongle-plus/ so FYI, anyone who bought the Sonoff Plus Dongle who want to upgrade the firmware is currently likely to follow that document and many will thus probably use that uartLog.py script to reset to boot mode rather than having to use a screwdriver to open the enclosure of the dongle, ...and as read it myself too I also posted a quick and dirty guide on how to achieve the wanted result using uartLog.py here at https://community.home-assistant.io/t/itead-sonoff-zigbee-3-0-usb-dongle-plus-adapter-based-on-texas-instruments-cc2652p/340705/105 as well as a copy of that guide here Koenkk/zigbee2mqtt#8840 (comment)_

Quick and dirty guide for how-to upgrade firmware on this Sonoff USB Plus Dongle from Windows OS without opening its enclosure:

The main benefit of this method is that don't need to open the dongles enclosure/casing, (this method could also be made to work across Windows, MacOS and Linux platforms if modify uartLog.py or better yet patch cc2538-bsl with working delays for CP2102N dongle uses).

1. Install Silabs CP210x drivers (if not already installed/available, at least needed on Windows).
2. Install Python for Windows (Windows Installer version)
3. In command-prompt run: python -m pip install --upgrade pip setuptools wheel ​gevent cc2538
4. Get "uartlog.zip" ZIP file package from either Sonoff docx or cc2538-bsl issue #113, open/unpack "uartLog.py" to ex. "C:\temp" then in command-prompt run: C:\temp\uartLog.py to get option and enter correct number for COM port (note that this step would no longer be needed in the future if and when "Auto BSL" gets patched with working delays for Sonoff USB Plus dongle in the cc2538-bsl script).
5. Download latest firmware from https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin and unpack to example "C:\temp" then in command-promt run: python cc2538-bsl.py -p COM5 -evw_ _C:\temp\CC1352P2_CC2652P_launchpad_coordinator_20210708.hex (replacing COM5 with correct COM port and right name/version and location of unpacked firmware file).

Again, this guide could relatively easily be translated to Linux or Mac OS and be further automated via scripting, (the problem there is that the uartLog.py script from Sonoff has been hardcoded for Windows COM ports so the port manager in it needs to be modified).

Tip! cc2538-bsl can be replaced by experimental llama-bsl fork if willing to test it, though it has same "Auto BSL" delay issue with Sonoff USB Plus dongle, but developer of llama-bsl is considering adding several additional features that will make it more user-friendly than cc2538-bsl:

https://github.com/electrolama/llama-bsl/issues

PS: ITead/Sonoff own developers could of course have made this much simpler if they themselves submitted patches to cc2538-bsl script.

[JelmerT]

Could you try the version in this branch: https://github.com/JelmerT/cc2538-bsl/tree/feature/ITead_Sonoff_Zigbee-delay

Try it:

• without options
• with --bootloader-invert-lines
• with --bootloader-active-high
• with both --bootloader-active-high --bootloader-invert-lines

if none of those work, try increasing the delay

cc2538-bsl/cc2538-bsl.py

Line 239 in efc9412

time.sleep(0.1)

all the way op to 1

[guozi7788]

@Hedda
I made a temporary modification and added a ‘sonoff’ parameter to automatically enter boot.

python cc2538-bsl.py -p COM19 -evw CC1352P2_CC2652P_launchpad_coordinator_20210708.bin sonoff

I tested it on windows and it looked like it worked correctly, you can try it.

https://github.com/guozi7788/cc2538-bsl/blob/master/cc2538-bsl.py

[Hedda]

Could you try the version in this branch: https://github.com/JelmerT/cc2538-bsl/tree/feature/ITead_Sonoff_Zigbee-delay

Try it:

• without options
• with --bootloader-invert-lines
• with --bootloader-active-high
• with both --bootloader-active-high --bootloader-invert-lines

if none of those work, try increasing the delay

cc2538-bsl/cc2538-bsl.py

Line 239 in efc9412

time.sleep(0.1)

all the way op to 1

@JelmerT Have now tested each of those options on my Windows 10 computer increasing the delay in that time.sleep(0.1) on line 239 testing 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 08., 0.9, and 1 but unfortunatly no better result. Keep getting the same timeout error:

ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

[Hedda]

@Hedda I made a temporary modification and added a ‘sonoff’ parameter to automatically enter boot.

python cc2538-bsl.py -p COM19 -evw CC1352P2_CC2652P_launchpad_coordinator_20210708.bin sonoff

I tested it on windows and it looked like it worked correctly, you can try it.

https://github.com/guozi7788/cc2538-bsl/blob/master/cc2538-bsl.py

@guozi7788 I tested and https://github.com/guozi7788/cc2538-bsl/blob/master/cc2538-bsl.py does work with "sonoff" argument.

guozi7788@9f9060b

Looks much more complicated than just adding some delay(s) but does indeed work with Sonoff Plus Dongle on Windows 10 OS.

C:\cc2538-bsl-master-guozi7788>python cc2538-bsl.py -p COM5 -evw CC1352P2_CC2652P_launchpad_coordinator_20210708.hex sonoff
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-----------ready to update-------------
Opening port COM5, baud 500000
Reading data from CC1352P2_CC2652P_launchpad_coordinator_20210708.hex
Your firmware looks like an Intel Hex file
Connecting to target...
CC1350 PG2.0 (7x7mm): 352KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x00057FD8
Primary IEEE Address: 00:12:4B:00:24:C2:77:03
    Performing mass erase
Erasing all main bank flash sectors
    Erase done
Writing 360448 bytes starting at address 0x00000000
Write 104 bytes at 0x00057F988
    Write done
Verifying by comparing CRC32 calculations.
    Verified (match: 0x8c73378a)

C:\cc2538-bsl-master-guozi7788>

[dm82m]

also working on mac here:

(sonoff) ➜  sonoff python cc2538-bsl.py -p /dev/tty.usbserial-1420 -evw CC1352P2_CC2652P_launchpad_coordinator_20210708.hex sonoff
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-----------ready to update-------------
Opening port /dev/tty.usbserial-1420, baud 500000
Reading data from CC1352P2_CC2652P_launchpad_coordinator_20210708.hex
Your firmware looks like an Intel Hex file
Connecting to target...
CC1350 PG2.0 (7x7mm): 352KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x00057FD8
Primary IEEE Address: 00:12:4B:00:24:C2:BA:FF
    Performing mass erase
Erasing all main bank flash sectors
    Erase done
Writing 360448 bytes starting at address 0x00000000
Write 104 bytes at 0x00057F988
    Write done
Verifying by comparing CRC32 calculations.
    Verified (match: 0x8c73378a)
(sonoff) ➜  sonoff

[JelmerT]

@guozi7788 that's a great temp fix, but I can't pull that into the script of course. It's basically just the 2 separate scripts in the same file.

I don't have the hardware, so I can't look further into this. If anyone is willing to send me the HW I should be able to connect it to a logic analyzer or scope and see what's going on.

I more than welcome any PRs that integrate the functionality into the script of course.

[Hedda]

@guozi7788 that's a great temp fix, but I can't pull that into the script of course. It's basically just the 2 separate scripts in the same file.

That is fully understandable. Hope that ITead/Sonoff will ship you a free dongle so that you can take a deeper look at this issue!

PS: I also suspected it and posted a related comment in Zigbee2MQTT discussion in -> Koenkk/zigbee2mqtt#8840 (reply in thread)

with the special version of cc2538-bsl there is no more need for uartlog.py right?

Well, it achieves the wanted result for the end-user but the intial version of cc2538-bsl fork by @guozi7788 should really just be seen as a temporary workaround (or proof-of-concept), because as it does now it just take all the boot mode reset code from uartLog.py script and copy it into the cc2538-bsl.py script with an argument, so in practice not much different from running the uartLog.py and cc2538-bsl.py scripts separately after each other like in my quick-and-dirty guide above, and that solution is probably unlikely to be accepted 'as is' and merged into upstream cc2538-bsl by JelmerT (or to llama-bsl)

So while you can use it for now it would be best to get proper delays in upstream cc2538-bsl by JelmerT, so keep eye on -> JelmerT/cc2538-bsl#113

[Hedda]

FYI, according to comment in this discussion on the is a modified version of BSL Scripter that also got BSL working with CP2102:

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/802610/msp430f6736-msp430f6xxx-uart-bootloader-via-usb-bridge-ic?ReplyFilter=Answers&ReplySortBy=Answers&ReplySortOrder=Descending

That discussion also links to these other discussions which goes into much deeper details about how that solution works exactly:

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/734713/using-a-cp2102-with-bsl-scripter---a-solution

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/723144/msp430fr5969-bsl-configuration-using-cp2102

https://community.silabs.com/s/question/0D51M00007xeOSgSAM/controlling-gpio-pins-cp2102n?language=en_US

So apparently this other type of invoke sequence pattern needed is well known by other developers using CP2102N / CP2102

[Hedda]

I don't have the hardware, so I can't look further into this. If anyone is willing to send me the HW I should be able to connect it to a logic analyzer or scope and see what's going on.

I more than welcome any PRs that integrate the functionality into the script of course.

@chiakikato read in Koenkk/zigbee2mqtt#8840 you have access to Sonoff Zigbee 3.0 USB Dongle Plus and already done some analyzing of it, any chance you could analyze further to find exact invocation sequence and pattern needed to invoke "Auto BLS"?

[JelmerT]

I got my hands on a unit and have implemented the correct sequence to start the bootloader automatically.

The new option is now --bootloader-sonoff-usb, and you can find the PR here #114
Please test and add any issues to the PR.

Thanks everyone!

[Hedda]

The new option is now --bootloader-sonoff-usb, and you can find the PR here #114
Please test and add any issues to the PR.

Nice! Will try to get time to test this weekend. But if and when we know it is working will that "sonoff" parameter still be required?

I'm not aware of any other HW that uses this connection, so I'm naming the option after the specific hardware. In the future this should probably get a more general name like --bootloader-imply-gate or something. (the truth table is an imply and nimply port)

Could otherwise CP2102 UART-to-USB chip or just USB "description" be detected then automatically use the correct sequence?

[JelmerT]

the needed sequence between the "standard" connection (RTS and DTR connected 1 to 1 to reset and the bootloader pin) and the connection in the sonoff stick is quite different. So I don't think we could do them both automatically, I'd need to test with some different hardware though. If we could that'd be great, since then it would be transparent for all hardware.
Another option is to try 1 sequence, check if the chip responds, then try the other one. But this would add quite some delay while programming, because you're waiting for that timeout first.

Just detecting the CP2102 would not be a good idea, since many boards use that chip, or could use it in the future, and might not be connected in the same way to the radio being programmed.
Itead also is still using the standard VID and PID for the CP2102, so we can't detect on that either.

[Hedda]

I got my hands on a unit and have implemented the correct sequence to start the bootloader automatically.

The new option is now --bootloader-sonoff-usb, and you can find the PR here #114 Please test and add any issues to the PR.

I can now confirm that with PR here #114 with --bootloader-sonoff-usb parameter is working for me on Windows 10. Thanks!

cc2538-bsl.py -p COM5 -evw --bootloader-sonoff-usb CC1352P2_CC2652P_launchpad_coordinator_20210708.hex

C:\Temp\cc2538-bsl-master-sonoff>cc2538-bsl.py -p COM5 -evw --bootloader-sonoff-usb CC1352P2_CC2652P_launchpad_coordinator_20210708.hex
sonoff
Opening port COM5, baud 500000
Reading data from CC1352P2_CC2652P_launchpad_coordinator_20210708.hex
Your firmware looks like an Intel Hex file
Connecting to target...
CC1350 PG2.0 (7x7mm): 352KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x00057FD8
Primary IEEE Address: 00:12:4B:00:24:C2:77:03
    Performing mass erase
Erasing all main bank flash sectors
    Erase done
Writing 360448 bytes starting at address 0x00000000
Write 104 bytes at 0x00057F988
    Write done
Verifying by comparing CRC32 calculations.
    Verified (match: 0x8c73378a)

C:\Temp\cc2538-bsl-master-sonoff>

[Hedda]

Just detecting the CP2102 would not be a good idea, since many boards use that chip, or could use it in the future, and might not be connected in the same way to the radio being programmed.
Itead also is still using the standard VID and PID for the CP2102, so we can't detect on that either.

I have reported that before to ITead that it is an issue they are using default VID, PID, and Product Description for CP2102 USB device identification. Important to note is that they are also using the default "product description" from Silabs.

Got a reply from them that they plan on changing the Product Description String value field to “Sonoff Zigbee 3.0 USB Dongle Plus” on EEPROM in CP2102N for their next batch in order to at least make "product description" unique so that applications can use "product description" to automatically detected it.

USB discovery in Home Assistant can already differ from different Zigbee adapters based solely on "product description" in USB chip EEPROM, (Itead however answered that they will continue using standard VID and PID in future batches as changing those would mean requiring releasing custom device drivers for CP2102). More info about that here -> https://community.home-assistant.io/t/community-help-wanted-to-whitelist-all-compatible-zigbee-and-z-wave-usb-adapters-for-automatic-discovery-in-home-assistant-os/344412

There are already a few "product description" for known CC2652 adapters in https://github.com/home-assistant/core/blob/dev/homeassistant/components/zha/manifest.json

   {"vid":"10C4","pid":"EA60","description":"*2652*","known_devices":["slae.sh cc2652rb stick"]},
   {"vid":"10C4","pid":"EA60","description":"*tubeszb*","known_devices":["TubesZB Coordinator"]},
   {"vid":"1A86","pid":"7523","description":"*tubeszb*","known_devices":["TubesZB Coordinator"]},
   {"vid":"1A86","pid":"7523","description":"*zigstar*","known_devices":["ZigStar Coordinators"]},

[Hedda]

Got a reply from them that they plan on changing the Product Description String value field to “Sonoff Zigbee 3.0 USB Dongle Plus” on EEPROM in CP2102N for their next batch in order to at least make "product description" unique so that applications can use "product description" to automatically detected it.

FYI, ITead looks to have their Sonoff branded CC2652P based USB dongles back in stock again for $10.99 (US) at least for now:

https://itead.cc/product/sonoff-zigbee-3-0-usb-dongle-plus/

No changelog announcement yet to let us know whether the USB chip in this batch has a unique Product Description String.

[Hedda]

FYI, ITead now posted a program (blob) that should let users themselves update the product description string on already shipped Sonoff dongles to supposedly match the same description already written to CP2102N EEPROM the latest batch of their dongles:

https://www.facebook.com/SONOFF.official/posts/2927251720919807

Tested that program myself on a Windows 10 computer and it did not work for me (program just closed without any messages).

Sad that ITead did not instead choose to release a CP2102N write tool based on this open-source cp210x-program by VCTLabs:

https://github.com/VCTLabs/cp210x-program

The point of having a unique custom product description in USB-to-UART chip is to allow USB auto-discovery, like the example in:

https://community.home-assistant.io/t/community-help-wanted-to-whitelist-all-compatible-zigbee-and-z-wave-usb-adapters-for-automatic-discovery-in-home-assistant-os/344412

[tboy72]

Hello!
I also messed up the SONOFF USB ZIGBEE after router firmware the flash.
Unfortunately, flash again doesn't work at all.

D:\Utils\cc2538-bsl-feature-ITead_Sonoff_Zigbee-delay>cc2538-bsl.py -p COM6 -evw --bootloader-sonoff-usb CC1352P2_CC2652P_other_coordinator_20210708.hex
sonoff
Opening port COM6, baud 500000
Reading data from CC1352P2_CC2652P_other_coordinator_20210708.hex
Your firmware looks like an Intel Hex file
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

Is there another solution to the problem, or has USB become completely brick?
Thanks!

[ZetaPhoenix]

FYI, I just got new adapters and they show up as Sonoff Zigbee 3.0 USB Dongle Plus

[Hedda]

I also messed up the SONOFF USB ZIGBEE after router firmware the flash. Unfortunately, flash again doesn't work at all.

D:\Utils\cc2538-bsl-feature-ITead_Sonoff_Zigbee-delay>cc2538-bsl.py -p COM6 -evw --bootloader-sonoff-usb CC1352P2_CC2652P_other_coordinator_20210708.hex
sonoff
Opening port COM6, baud 500000
Reading data from CC1352P2_CC2652P_other_coordinator_20210708.hex
Your firmware looks like an Intel Hex file
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

Is there another solution to the problem, or has USB become completely brick?

Yeah should have used the "CC1352P2_CC2652P_launchpad_*.zip" image file and not "CC1352P2_CC2652P_other_*.zip" image file.

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin

Did you try removing enclosure and manually hold physical boot-button while plugging into USB-port?

https://sonoff.tech/sonoff-zigbee-3-0-usb-dongle-plus-firmware-flashing-2/

If you messed up the bootloader firmware then believe only way to unbrick hardware is to flash with cJTAG, see details on that here:

https://electrolama.com/radio-docs/advanced/flash-jtag/

The debug adapter for CC2652/CC1352 needs to support 2-pin cJTAG (a.k.a C-JTAG or c/JTAG) and not just common JTAG SWD as TI CC2652 debug does not use SWD and SWDCLK, etc. but instead only TMS and TCK (cJTAG is not SWD/SWDCLK).

Texas Instruments XDS110 JTAG debug probe is a bit expensive but cheap clones of it should work, ex:

https://aliexpress.com/item/4000751867419.html

The official TMDSEMU110-U XDS110 JTAG Debug Probe from TI also looks to be out-of-stock now too.

https://www.ti.com/tool/TMDSEMU110-U

Looking at pictures on ITead's product page you see that no SWD and SWDCLK pads are exposed.

So will probably need cJTAG debug probe with TMS and TCK like Texas Instruments XDS110 or clone.

[Hedda]

FYI, I just got new adapters and they show up as Sonoff Zigbee 3.0 USB Dongle Plus

Yeah some partial progress at least. Unfortunately, the script ITead posted that should let users themselves update the product description string on CP2102N for Sonoff dongles already shipped before does not seem to work:

https://www.facebook.com/SONOFF.official/posts/2927251720919807

Again sad that ITead did not choose to release a CP2102N write tool based on this open-source cp210x-program by VCTLabs:

https://github.com/VCTLabs/cp210x-program

That way both new and existing owners of it could utilize an automatic discovery feature if it is added.

[Hedda]

FYI, after updating several times and helping others with different setups I have broken down my tested steps to flash firmware mentioned from #114 into this basic guide for flashing ITead SONOFF Zigbee 3.0 USB Dongle Plus adapter.

This guide uses the cc2538-bsl tool from JelmerT's latest "master" branch on GitHub and could easily be made to work on all operating systems. I tested on Windows OS but others have done this on Linux and Mac OS by using different Serial/COM-port addressing as the steps should otherwise be the same.

1. Install Silabs CP210x device drivers (CP2102N USB-to-UART bridge / USB-to-Serial converter chip) needed for Windows OS and Mac OS, (this also required a reboot of my operating-system).
2. Install Python (in my case I installed and tested with Python for Windows 3.10.1).
3. Launch command-prompt (cmd.exe) as elevated Administrator. Upgrade pip with python -m pip install --upgrade pip, (if pip is not available then first run python -m ensurepip --upgrade), then pre-install dependencies fro cc2538-bsl from PyPi via pip command: pip install wheel pyserial intelhex python-magic
4. Optional but recommended: Download and install zigpy-znp via pip/PyPI with pip install zigpy-znp then perform NVRAM backup by following instructions in TOOLS.md (also find more details ZNP radio backup procedure at https://github.com/zigpy/zigpy/wiki/Coordinator-Backup-and-Migration) for Windows backup command should be something like python -m zigpy_znp.tools.nvram_read COM5 -o nvram_backup.json and optionally also backup Zigbee network via python -m zigpy_znp.tools.network_backup COM5 -o network_backup.json.
5. Download cc2538-bsl on GiHub from its "master" branch, (and not via pip/PyPI), unpact the zip to a folder then launch command-promt (cmd.exe) as elevated Administrator and run its setup.py to install its dependencies (should include "setuptools", "wheel", "pyserial", "intelhex", and "python-magic" packages).
6. Get latest firmware (I tested latest "CC1352P2_CC2652P_launchpad_*.zip" image available from its "master" branch at this time. Alternatively, you could get the latest "beta" version from the develop branch). Regardless make sure to get the correct image file as should be the one for "launchpad" (and not for "other)"!
7. Stop any applications or services that might be connected to the Zigbee adapter via serial port (ex. Home Assistant's ZHA integration, Zigbee2MQTT, ioBroker, Jeedom, etc.). In my case, I ran the update on another computer so nothing to stop there.
8. Run command to flash from command-promt (cmd.exe) launched as elevated Administrator, example with firmware release available at this time: python cc2538-bsl.py -p COM5 -e -v -w --bootloader-sonoff-usb CC1352P2_CC2652P_launchpad_coordinator_20211217.hex

Obviously need to replace number in "COM5" with the port # actually shown used under ports in Device Manager on Windows on your computer as the OS will just assign the next available Serial/COM-port.

Also, if using Linux or Mac OS instead of Microsoft Windows then the COM# serial device path after -p will be different when set the port to use, (like for example /dev/ttyUSB0 or /dev/ttyUSB1) and might need different Silabs CP210x device drivers (CP2102N USB-to-UART bridge / USB-to-Serial converter chip) for your operating system, on Linux might have to run Python with sudo, and read that many on Linux successfully run sudo python cc2538-bsl.py -e -v -w --bootloader-sonoff-usb CC1352P2_CC2652P_launchpad_coordinator_20211217.hex without setting serial device path with -p for port to use.

[JelmerT]

FYI, I just got new adapters and they show up as Sonoff Zigbee 3.0 USB Dongle Plus

Yeah some partial progress at least. Unfortunately, the script ITead posted that should let users themselves update the product description string on CP2102N for Sonoff dongles already shipped before does not seem to work:

I tried making the script work on macOS and also tried the alternative tools, but had no success updating the descriptor or vid pid on mine. Manually selecting the port is not the worst, but it's unfortunate we can't make it happen automagically for those first units that were sent out with the standard descriptors.

I'm going to close this issue since the original problem is now pulled into main and works. For auto detecting the sonoff hardware, please open a new issue or even better a PR.

Thanks everyone for your contribution.

[Hedda]

FYI, I just got new adapters and they show up as Sonoff Zigbee 3.0 USB Dongle Plus

Yeah some partial progress at least. Unfortunately, the script ITead posted that should let users themselves update the product description string on CP2102N for Sonoff dongles already shipped before does not seem to work:

I tried making the script work on macOS and also tried the alternative tools, but had no success updating the descriptor or vid pid on mine. Manually selecting the port is not the worst, but it's unfortunate we can't make it happen automagically for those first units that were sent out with the standard descriptors.

@JelmerT Maybe you could look into VCTLabs cp210x-program to change the CP2102N "product description" string? See:

https://github.com/VCTLabs/cp210x-program

Note! Do not change the VID or PID as then will new a new device driver too, so only change the "product description" string.

PS: I will create a new separate issue with a request to auto-detect known dongles based on information provided on USB chip.