Sonoff dongle error "XDS110 not found" about sniffle HOT 14 CLOSED

BTW if you want to use the 2M baud firmware with your Sonoff dongle, just remove this logic:

from sniffle.

What firmware version are you running on the Sonoff dongle? What’s its USB VID/PID? The prebuilt binary for v1.9.1 for CC1352P1/CC2652P1 with 1M baud rate should work.

from sniffle.

Also, which version of cc2538-bsl did you use to flash? Try the one on my GitHub account if you didn’t already

from sniffle.

Most likely, either the CC2652P chip is stuck in reset or stuck in bootloader mode. My modified cc2538-bsl script should allow the chip to properly reboot into the Sniffle firmware after flashing. Unplugging the Sonoff dongle and plugging it back in should also allow it to boot I to the Sniffle firmware.

One other possibility is that the baud rate selection logic is failing if the USB VID/PID don’t match what I expect for CP2102 based devices.

To check if the firmware is working properly, after resetting (rebooting) the chip, see if it’s putting out lines of base64 data over UART (at 1M baud for this firmware variant).

from sniffle.

"I used the branched repository to do the firmware update" (meaning your branch of cc2538-bsl specified in the instructions) and I used "sniffle_cc1352p1_cc2652p1_1M.bin" as shown in the command. It was the 1.9.1 version.

USB info is as follows:

[56087.088759] usb 3-3.1: new full-speed USB device number 13 using xhci_hcd
[56087.191424] usb 3-3.1: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
[56087.191431] usb 3-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[56087.191433] usb 3-3.1: Product: Sonoff Zigbee 3.0 USB Dongle Plus
[56087.191435] usb 3-3.1: Manufacturer: Silicon Labs
[56087.191436] usb 3-3.1: SerialNumber: 0001

I got the dongle from Slawomir and I thought the new Sniffle instructions had incorporated his input. But now that it didn't work I went back and read his instructions. And in them he describes how "old batch" CP2502N (which is what this is) would work with the existing CC1352P1 Sniffle firmware, but "new batch" CP2502 (no-N) is what would need the 900kbaud patched firmware. In his instructions he had warned not to use the 1.7 firmware, but that future firmware would be fine because it had device.enableBootloader = true and device.enableBootloaderBackdoor = true. (That's still true?)

However, now I can't attempt to re-flash with the CC1352P1 firmware, as I just get the following error:

sudo python3 cc2538-bsl.py -p /dev/ttyUSB0 --bootloader-sonoff-usb -ewv ~/Downloads/sniffle_cc1352p1_cc2652p1.out 
[sudo] password for vmuser: 
sonoff
Opening port /dev/ttyUSB0, baud 500000
Reading data from /home/vmuser/Downloads/sniffle_cc1352p1_cc2652p1.out
Cannot auto-detect firmware filetype: Assuming .bin
Connecting to target...
CC1350 PG2.1 (7x7mm): 352KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x00057FD8
Primary IEEE Address: 00:12:4B:00:29:DE:24:E4
    Performing mass erase
Erasing all main bank flash sectors
    Erase done
Writing 531148 bytes starting at address 0x00000000
Target returned: 0x43, Invalid address
Target returned: 0x43, Invalid address
Target returned: 0x43, Invalid address
Target returned: 0x43, Invalid address
Target returned: 0x43, Invalid address
...

Re "To check if the firmware is working properly, after resetting (rebooting) the chip, see if it’s putting out lines of base64 data over UART (at 1M baud for this firmware variant)." I'm not quite sure how to do that?

I tried sudo screen /dev/ttyUSB0 1000000 because I saw the baud seemed to be defined as fw/messenger.c, but there was no output (including if I pressed the "rst" button I see after I disassembled the device.)

I'm guessing this means the bootloader is dead now and I'd need to use JTAG to reflash it?

from sniffle.

Hmm, I wonder what's going on with your bootloader. The version 1.7 release was disabling the bootloader "backdoor" though I re-enabled it soon after and left it enabled with all subsequent releases. The USB VID/PID on your dongle are the same as on mine, so it should be using the correct baud rate.

I don't think your bootloader is dead, as if it got to the point you showed it's still entering the bootloader. You're using the master branch of the https://github.com/sultanqasim/cc2538-bsl repo, right?

I noticed that the binary size you were trying to flash seems wrong (too big). I then noticed you're flashing the ".out" ELF file rather than the .bin binary. I provided binary ".bin" files for the 1M baud versions of the firmware to use with the bootloader. The ".out" ELF files are to be used with TI DSLite utilities for flashing with the debugger. If you go back to flashing the ".bin" file for 1M baud rate, it should work. Alternatively, if you want to convert the 2M baud firmware to a ".bin" file suitable for the bootloader, you could use the command objcopy -I elf32-little -O binary sniffle_cc1352p1_cc2652p1.out sniffle_cc1352p1_cc2652p1.bin.

from sniffle.

I also wonder if your particular Sonoff dongle has some CP2x02x variant that works at 921600 baud but not at 1M baud. Mine is fine at 1M baud. If you have an oscilloscope or logic analyzer, you could probe the UART signals after flashing firmware with the bootloader.

from sniffle.

Flashing output should look like this:

[sultan@sprocket builds]$ ~/Downloads/cc2538-bsl/cc2538-bsl.py -p /dev/ttyUSB0 --bootloader-sonoff-usb -ewv sniffle_cc1352p1_cc2652p1_1M.bin 
sonoff
Opening port /dev/ttyUSB0, baud 500000
Reading data from sniffle_cc1352p1_cc2652p1_1M.bin
Cannot auto-detect firmware filetype: Assuming .bin
Connecting to target...
CC1350 PG2.1 (7x7mm): 352KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x00057FD8
Primary IEEE Address: 00:12:4B:00:2E:20:C9:75
    Performing mass erase
Erasing all main bank flash sectors
    Erase done
Writing 360448 bytes starting at address 0x00000000
Write 104 bytes at 0x00057F980
    Write done                                
Verifying by comparing CRC32 calculations.
    Verified (match: 0x84e4485a)

from sniffle.

You're using the master branch of the https://github.com/sultanqasim/cc2538-bsl repo, right?

Yep

$ git remote -v
origin	https://github.com/sultanqasim/cc2538-bsl.git (fetch)
origin	https://github.com/sultanqasim/cc2538-bsl.git (push)
$ git branch
* master

I then noticed you're flashing the ".out" ELF file rather than the .bin binary.

OK, yes you're right, for the default CC1352P image test I was using the .out instead of the .bin which I used in the original 1M test. And yes, it looks like the original sudo python3 cc2538-bsl.py -p /dev/ttyUSB0 --bootloader-sonoff-usb -ewv ~/Downloads/sniffle_cc1352p1_cc2652p1_1M.bin command does continue to work, so it was only the .out vs. .bin which was causing the Target returned: 0x43, Invalid address errors.

After I re-ran that, I do now see output when I do sudo screen /dev/ttyUSB0 1000000. The output doesn't decode to any ASCII though (if any of it is supposed to?).

I was also able to successfully run the objcopy -I elf32-little -O binary sniffle_cc1352p1_cc2652p1.out sniffle_cc1352p1_cc2652p1.bin and then flash the resulting .bin file. And again I got some serial output, just nothing that decoded to ASCII.

With both the images, the result is still the OSError: XDS110 not found error if I provide no -s /dev/ttyUSB0 argument, and no output if I provide a -s /dev/ttyUSB0 argument.

Before I hook up the logic analyzer to the UART to try and debug the baud it's using, I think I first want to just wait to get 2x new dongles in the mail, and see what revision of the hardware they are. If they're what Slawomir calls the "new" hardware (with the 1MBit limit) then I'll try the default flash image again and see what the result is.

Thanks for the help so far. I'll let you know hopefully tomorrow.

from sniffle.

If you're seeing data on UART that's a good sign. The output should be well formed base64 ASCII with CRLF separators, if the baud rate is set correctly. What you see with screen or miniterm should look something like:

EBAzcjsuIwAAAMQl5iGp6b/lW0Ya/0wAAhVQdly32epOIZmk+oeWE6SS005l/84=
CRCoFDwuDgAAALQlwwwIpjBxSFDeQ4b8NGU=
DRCHhDwuGQAAAMElQBfMcrkbyUUCARoCCgwK/0wAEAUNHI03aw==
CRAlhjwuDgAAALQlwwwIpjBxSFDMcrkbyUU=
BxBrhzwuCAAAAMElRAbMcrkbyUU=
DRCgiTwuGQAAAL4lYBe/PqYx73ACARoCCggK/0wAEAUlGKwMyg==
ERB2tDwuJgAAAMQl5iTuYaprg2Ud/y0BAgABEBYdcDD500s3v2E1ECoAvBkYXX2H/Uo=
CRB8tjwuDgAAALQlwwwIpjBxSFDuYaprg2U=
BxDCtzwuCAAAAMQl5AbuYaprg2U=
ChBcujwuEAAAAL4lYA7EQ+4vx/MH/0wAEgIUAA==
CRCyuzwuDgAAALQlwwwIpjBxSFDEQ+4vx/M=
BxD5vDwuCAAAAL4lRAbEQ+4vx/M=
DRA7/TwuGwAAALUlQBkOhf58810CARoCCgwM/0wAEAc4H0q2plgI
CRDp/jwuDgAAALMlwwwIpjBxSFAOhf58810=
BxAvAD0uCAAAALYlRAYOhf58810=
EBBMOD0uIwAAAMQl5iGp6b/lW0Ya/0wAAhVQdly32epOIZmk+oeWE6SS005l/84=
ERCNej4uJgAAAMUl5iTuYaprg2Ud/y0BAgABEBYdcDD500s3v2E1ECoAvBkYXX2H/Uo=
DRDS9D4uGQAAAL8lQheK4wG03ngCARoN/0wAFggAF74zVbzZzQ==
ChAoCD8uEAAAAL8lQg7PR79mgO0H/0wAEgIAAA==
EBADIz8uIwAAAMYl5iGp6b/lW0Ya/0wAAhVQdly32epOIZmk+oeWE6SS005l/84=
CBApMD8uDAAAAMElRgoBO2xqqEADA/P+

from sniffle.

I remember seeing some SiLabs documents claiming a 921600 baud limit, while others claimed a 1M baud limit. This document suggests the CP2102N supports 3M baud.

My current guess is that your Sonoff dongle’s hardware doesn’t like 1M baud but it may be OK with 921600 baud. I might just lower the baud rate of the “1M” firmware to 921600 baud if that’s the case. Mine works fine with 1M baud but I haven’t checked which USB-UART chip it has.

from sniffle.

Try the new 1.9.2 release with the slower 921600 baud rate for the 1M build variant on your Sonoff dongle. Hopefully it'll work.

from sniffle.

v1.9.1 "just worked" on the new dongles that I just purchased. As did v1.9.2.

I also confirmed v1.9.2 worked on the previous dongle that I got from Slawomir. This confirms that its chip can handle 921600 but not 1000000 baud.

It turns out I was not reading Slawomir's document correctly, because I had assumed he gave me a faster one, not a slower one. However, this was incorrect. The one he gave me has the "CP2102" chip, which is what's rate limited to 921600 apparently.

The new dongles that were freshly purchased off Amazon have the "CP2102N" serial chips,

Those can handle the 2M baud, which I confirmed by flashing the "sniffle_cc1352p1_cc2652p1.bin" that I created with the previous objcopy command, and then connecting via serial and seeing valid Base64 output. I suspect that if you open your device you'll see you have a CP2102N chip, which is why the 1Mbaud worked for you. And while I could see valid serial output I couldn't sniff data using sniff_receiver.py. I tried changing the 921600 to 2000000 in fw/messenger.c but that just yielded various errors. What all would need to be changed to support the 2Mbaud on devices which support it?

Also while I now have them all nominally working, I would note the fresh one I tried only worked if an explicit -s /dev/ttyUSB0 argument was given, otherwise they still had a OSError: XDS110 not found error. So FWIW it seems like they aren't auto-detected. But that's just a nicety and I'm fine with closing this ticket if you'd like.

from sniffle.

Thanks for confirming, that makes sense. My Sonoff dongle indeed has the CP2102N.

The auto-detect logic right now looks for the USB VID/PID of TI XDS110 debuggers, since such devices are likely to be boards meant for use with Sniffle. The CP2102(N) USB VID/PID could be anything, and I don't want to send data to arbitrary serial port enabled devices in case it breaks some other devices the user may have plugged in. However, I could look for the USB descriptors of the Sonoff/Itead dongle specifically for a more selective and safer auto-detection.

It would be nice to use the full 2M baud rate for dongles that support it, though I would need to figure out a way to distinguish between CP2102 and CP2102N, given that they have the same USB VID/PID. Other options could be to try 2M baud at first, and if it doesn't work, try falling back to 921600, and/or providing a command line option to specify the baud rate.

from sniffle.