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

[ghazel]

Using CC1310 on a SMARTRF06, git rev a38cfc889ebb2197b8775c79763e04c592fd4b77, I get:

~/contiki/examples/hello-world$ make TARGET=srf06-cc26xx BOARD=srf06/cc13xx hello-world.upload PORT=/dev/ttyUSB1
  CC        ../../cpu/cc26xx-cc13xx/lib/cc13xxware/startup_files/ccfg.c
  CC        ../../cpu/cc26xx-cc13xx/./ieee-addr.c
  AR        contiki-srf06-cc26xx.a
  CC        ../../cpu/cc26xx-cc13xx/./fault-handlers.c
  CC        ../../cpu/cc26xx-cc13xx/lib/cc13xxware/startup_files/startup_gcc.c
  CC        hello-world.c
  LD        hello-world.elf
arm-none-eabi-objcopy -O binary --gap-fill 0xff hello-world.elf hello-world.bin
python ../../tools/cc2538-bsl/cc2538-bsl.py -e -w -v -p /dev/ttyUSB1 hello-world.bin
Opening port /dev/ttyUSB1, baud 115200
Reading data from hello-world.bin
Cannot auto-detect firmware filetype: Assuming .bin
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'
make: *** [hello-world.upload] Error 1
rm obj_srf06-cc26xx/startup_gcc.o hello-world.co obj_srf06-cc26xx/fault-handlers.o

(I manually set the baud to 115200 which I believe is correct. 500000 failed the same way.)

[JelmerT]

The 500000 baud rate should work (this makes things a lot faster).

The timeout waiting for the ACK/NACK means there was no answer from the chip. You're sure about the connection to the chip itself? Can you test it with another program / device?

[ghazel]

I'm sure about the connection. Uniflash was able to flash the chip just fine, and hello-world worked.

[JelmerT]

Just trying to debug here: You're confident you've got the correct serial port, and you're sure the bootloader is unlocked on the chip?

[splitice]

I'm getting a similar issue with a CC2538 module straight from the factory. These modules when programmed with a firmware communicate fine over serial. Just to be sure I connected JTAG and did an erase (in-case the factory set some bits for some reason) which should reset image valid I think.

[splitice]

I can confirm the SBL is running, I set up a FTDI on the same pins on windows:

[splitice]

cc2538-bsl.py also works on Windows via the FTDI module

C:\Python27>python cc2538-bsl.py -p COM8 Opening port COM8, baud 500000 Connecting to target... CC2538 PG2.0: 512KB Flash, 32KB SRAM, CCFG at 0x0027FFD4 Primary IEEE Address: 00:12:4B:00:10:05:FF:DB

The actual hardware is a Linux SBC with the module connected via a UART

[splitice]

I think this may be related to the ZNP client attempting to start up (which uses the same serial port) causing the SBL to pick a wrong baud rate.

[splitice]

Also the first time requested after boot fails.

halley@Tinyhub:~$ python ~/cc2538-bsl/cc2538-bsl.py -p /dev/ttyS1
Opening port /dev/ttyS1, baud 500000
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'
halley@Tinyhub:~$ python ~/cc2538-bsl/cc2538-bsl.py -p /dev/ttyS1
Opening port /dev/ttyS1, baud 500000
Connecting to target...
CC2538 PG2.0: 512KB Flash, 32KB SRAM, CCFG at 0x0027FFD4
Primary IEEE Address: 00:12:4B:00:10:05:FF:DB
halley@Tinyhub:~$ python ~/cc2538-bsl/cc2538-bsl.py -p /dev/ttyS1
Opening port /dev/ttyS1, baud 500000
Connecting to target...
CC2538 PG2.0: 512KB Flash, 32KB SRAM, CCFG at 0x0027FFD4
Primary IEEE Address: 00:12:4B:00:10:05:FF:DB

[desword]

How about the TI cc2650? I have followed the steps on http://pablocorbalan.com/getting-started-with-ti-cc2650-launchpad to flush a bootloader enabled firmware on cc2650, and then try to flush the firmware using cc2538-bsl.

I have tried /dev/ttyACM0 and /dev/ttyACM1. And the change the baud into 115200. However, both of them can not work.

I am trying the example on https://github.com/spoerk/contiki/tree/master/examples/cc26xx/cc26xx-ble-client-demo

$ make TARGET=srf06-cc26xx BOARD=launchpad/cc2650 PORT=/dev/ttyACM1 client.upload
  CC        ../../../cpu/cc26xx-cc13xx/lib/cc26xxware/startup_files/ccfg.c
  CC        ../../../cpu/cc26xx-cc13xx/./ieee-addr.c
  AR        contiki-srf06-cc26xx.a
  CC        ../../../cpu/cc26xx-cc13xx/./fault-handlers.c
  CC        ../../../cpu/cc26xx-cc13xx/lib/cc26xxware/startup_files/startup_gcc.c
  CC        client.c
  LD        client.elf
arm-none-eabi-objcopy -O binary --gap-fill 0xff client.elf client.bin
python ../../../tools/cc2538-bsl/cc2538-bsl.py -e -w -v -p /dev/ttyACM1 client.bin
Opening port /dev/ttyACM1, baud 500000
Reading data from client.bin
Cannot auto-detect firmware filetype: Assuming .bin
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'
make: *** [client.upload] Error 1
rm client.co obj_srf06-cc26xx/fault-handlers.o obj_srf06-cc26xx/startup_gcc.o

$ make TARGET=srf06-cc26xx BOARD=launchpad/cc2650 PORT=/dev/ttyACM0 client.upload
  CC        ../../../cpu/cc26xx-cc13xx/lib/cc26xxware/startup_files/ccfg.c
  CC        ../../../cpu/cc26xx-cc13xx/./ieee-addr.c
  AR        contiki-srf06-cc26xx.a
  CC        ../../../cpu/cc26xx-cc13xx/./fault-handlers.c
  CC        ../../../cpu/cc26xx-cc13xx/lib/cc26xxware/startup_files/startup_gcc.c
  CC        client.c
  LD        client.elf
arm-none-eabi-objcopy -O binary --gap-fill 0xff client.elf client.bin
python ../../../tools/cc2538-bsl/cc2538-bsl.py -e -w -v -p /dev/ttyACM0 client.bin
Opening port /dev/ttyACM0, baud 500000
Reading data from client.bin
Cannot auto-detect firmware filetype: Assuming .bin
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'
make: *** [client.upload] Error 1

$ make TARGET=srf06-cc26xx BOARD=launchpad/cc2650 PORT=/dev/ttyACM0 client.upload
  CC        ../../../cpu/cc26xx-cc13xx/lib/cc26xxware/startup_files/ccfg.c
  CC        ../../../cpu/cc26xx-cc13xx/./ieee-addr.c
  AR        contiki-srf06-cc26xx.a
  CC        ../../../cpu/cc26xx-cc13xx/./fault-handlers.c
  CC        ../../../cpu/cc26xx-cc13xx/lib/cc26xxware/startup_files/startup_gcc.c
  CC        client.c
  LD        client.elf
arm-none-eabi-objcopy -O binary --gap-fill 0xff client.elf client.bin
python ../../../tools/cc2538-bsl/cc2538-bsl.py -e -w -v -p /dev/ttyACM0 -e -w -v -b 115200 client.bin
Opening port /dev/ttyACM0, baud 115200
Reading data from client.bin
Cannot auto-detect firmware filetype: Assuming .bin
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'
make: *** [client.upload] Error 1

$ make TARGET=srf06-cc26xx BOARD=launchpad/cc2650 PORT=/dev/ttyACM1 client.upload
  CC        ../../../cpu/cc26xx-cc13xx/lib/cc26xxware/startup_files/ccfg.c
  CC        ../../../cpu/cc26xx-cc13xx/./ieee-addr.c
  AR        contiki-srf06-cc26xx.a
  CC        ../../../cpu/cc26xx-cc13xx/./fault-handlers.c
  CC        ../../../cpu/cc26xx-cc13xx/lib/cc26xxware/startup_files/startup_gcc.c
  CC        client.c
  LD        client.elf
arm-none-eabi-objcopy -O binary --gap-fill 0xff client.elf client.bin
python ../../../tools/cc2538-bsl/cc2538-bsl.py -e -w -v -p /dev/ttyACM1 -e -w -v -b 115200 client.bin
Opening port /dev/ttyACM1, baud 115200
Reading data from client.bin
Cannot auto-detect firmware filetype: Assuming .bin
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'
make: *** [client.upload] Error 1

[JelmerT]

@desword your problem seems different from the other issues in this thread, so feel free to open a new issue.

The timeout errors you're getting means the script isn't getting any response from the chip. There's multiple possible causes, but the main one is usually hardware related. So make sure your serial connection to the chip and serial bootloader works. Then check that the SBL itself is properly configured. Also make sure the bootloader is actually running. Lastly make sure nothing else is accessing the serial line before the script.

[mohanmaniramesh]

I also have the similar Issue:

I will explain step by step:

1) I have 10 openMote-B Rev-1.4 2) I started working with RIOT. I'm confused where to and how to start so I mailed to RIOT Developer's they said as you are a beginner you can try RIOT--TUTORIALS like that
https://github.com/RIOT-OS/Tutorials 3) So I started working with the TUTORIALS, I have installed the necessary packages 4) I have connected only one OpenMote-B to my PC having ubuntu18.04 5) I went to this Directory /home/Tutorial/Task-01 6) I Provided This Comment BOARD=openmote-B make flash all term For tranfer the program into my openmote-B 7) The Code was transferred successfully and a terminal Opened there I gave PS, Reboot and Help Command that was also working well 8) Now i went the Task-02 Directory /home/Tutorial/Task-02 Here I gave this command BOARD=openmote-B make flash all term For tranfer the TASK-02 program to my openmote-B But this Time I got the Following Error ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

I got to know by my analysis there is problem with the Bootloder kind of things only openMote-B developer Mr.per tuset he said the following Hello, You have probably flahsed a RIOT image that has the wrong pin configuration for the bootloader in the Flash. To fix it: 1) Use a JTAG probe to flash an empty imatge or am image with the proper bootloader Flash settings 2) Change the RIOT image to make sure that the same bootloader Flasg setting are used For your reference, the pin that is used to trigger the bootloader on the OpenMote-B board is PORTA PIN7 using a low level. Kind regards, Pere I analysed and found the below line

define CCA_BACKDOOR_PORT_A_PIN (6) /*< BSL_BOOT Pin /

by Pere Tuset approval i changed the pin number 6 into 7

but then also not working and again he said like this Hello, This is really unfortunate. I am not very familiar with RIOT, but there must be something else going on. For example the CCA configuration is stored in Flash as described in this file -> https://github.com/RIOT-OS/RIOT/blob/master/cpu/cc2538/vectors.c The specific line is : 0xe0ffffff | (CCA_BACKDOOR_ENABLE << 28) | (CCA_BACKDOOR_ACTIVE_LEVEL << 27) | (CCA_BACKDOOR_PORT_A_PIN << 24) If done the math and it matches the configuration I am unsing on my projects, so that should work. One thing to try is using a slower baudrate (i.e. 400000) just in case.

but I'am confused where to change what to change i did so many thing i have total 10 in that 5 boards are locked remaining 5 boards are there i'm fearing to check more things please help me out of this

(I got the idea to recover the other 5 openmote-B board using JTAG programmer I'm going to make it work)

But i sould work with other boards by solving this error

Thanks

[dony71]

Just trying to debug here: You're confident you've got the correct serial port, and you're sure the bootloader is unlocked on the chip?

@JelmerT, so if booloader is locked, then will get ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)' .... Is this normal ?

l# python3 cc2538-bsl.py  -p /dev/ttyUSB0
cc2538-bsl.py:971: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if int(value) % int(device.page_size) is not 0:
cc2538-bsl.py:976: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if int(value, 16) % int(device.page_size) is not 0:
Opening port /dev/ttyUSB0, baud 500000
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

[JelmerT]

@dony71 A timeout can have multiple reasons, but a locked bootloader is one of them. The chip just doesn't answer because it's not listening. But if there is a problem your chip wouldn't answer either for example

[dony71]

@JelmerT I read somewhere need to do mass erase on the flash so that backdoor bootloader can be enable. I have raspberry pi and have installed openocd on it. Do you know how to do mass erase flash using openocd?

[JelmerT]

@dony71 You'd need to connect to the chip with a jtag programmer to enable the serial bootloader.

quick google search brought me to this https://gist.github.com/hwhw/fc43892785aa84913d03495c97b0f25a which seems like a good explanation.

[inspire1969]

Hello Everyone..!! I am getting this error ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)' ../../platform/openmote-cc2538/Makefile.openmote-cc2538:51: recipe for target 'openmote-demo.upload' failed make: *** [openmote-demo.upload] Error 1 rm openmote-demo.co obj_openmote-cc2538/startup-gcc.o

I have read all the things which are mentioned above and applied it also but still it showing this error. Can anyone help me in this regard?

[knoopx]

fyi: I also was getting the error but it turned out to be brltty udev rule messing with the device. after commenting the udev rule as stated in https://unix.stackexchange.com/questions/670636/unable-to-use-usb-dongle-based-on-usb-serial-converter-chip I was able to flash without further problems.

[inspire1969]

Hi Everyone, I also have this error but it was solved.  Please check your openmote before inserting it. Sometime the mote is also not working. Other than that i donot face this problem more.  Regards, Ali Shoaib 

On Thu, 13 Jan 2022 at 16:12, Víctor @.***> wrote:

fyi: I also was getting the error but it turned out to be brltty udev rule messing with the device. after commenting the udev rule as stated in https://unix.stackexchange.com/questions/670636/unable-to-use-usb-dongle-based-on-usb-serial-converter-chip I was able to flash without further problems.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.Message ID: @.***>

[djgrazzy]

I had this issue and solved. Hope this is helpful but all I done on Windows 10 was update from Driver Version 6.7.4.261 to 11.1.0.53. Unplugged and re-plugged the dongle and flashed.

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

I had previously used steps in this video https://youtu.be/4jqQCxjlRDU

But was trying to follow this one https://youtu.be/4eYnURcDrWw

[nielsnl68]

I do have the same issue, just brought this sonoff ZBDongle-P 3.0 USB dongle and wanted to upgrade my firmware with your phyton script. Doing so i got the same error as mentioned above.

There are a lot of suggestions but i'm not clear with path i need to take, i'm a newby on using the zigbee dongle.

[bglnelissen]

For future readers. I tried to flash my dongle which gave a Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)' error. I found that there was an other instance trying to use the dongle (zigbee2mqtt docker container). When I did quit the container it all worked as expected.

While running the docker container (error).

./cc2538-bsl.py -p /dev/ttyUSB0 -evw ~/CC2652RB_coordinator_20211114/CC2652RB_coordinator_20211114.hex 
Opening port /dev/ttyUSB0, baud 500000
Reading data from ~/CC2652RB_coordinator_20211114/CC2652RB_coordinator_20211114.hex
Your firmware looks like an Intel Hex file
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

After stopping docker:

./cc2538-bsl.py -p /dev/ttyUSB0  -evw ~/CC2652RB_coordinator_20211114/CC2652RB_coordinator_20211114.hex 
Opening port /dev/ttyUSB0 , baud 500000
Reading data from ~/CC2652RB_coordinator_20211114/CC2652RB_coordinator_20211114.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:23:90:D5:3B
    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: 0x12cd0a42)

[inspire1969]

Hi Bastiaan Nelissen, Have you put the connection right for putting it into boot mode? I was also having a same problem in the end i came up with a damage node. I suggest you to take a multimeter and check every IC on the node.

Regards, Ali Shoaib

[cpaius]

had the same timeout issue. Simply resolved that by adding --bootloader-sonoff-usb flag.

[RafBois]

I don't understand why I have this error and I don't think anyone in this post has fixed the problem?

lrwxrwxrwx 1 root root 13 Nov 17 21:45 usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20220816140554-if00 -> ../../ttyACM0

sudo python3 cc2538-bsl.py -ewv -p /dev/ttyACM0 --bootloader-sonoff-usb . /CC1352P2_CC2652P_launchpad_coordinator_20220219.hex

sonoff Port d'ouverture /dev/ttyACM0, baud 500000 Lecture des données de . /CC1352P2_CC2652P_launchpad_coordinator_20220219.hex Votre micrologiciel ressemble à un fichier Intel Hex Connexion à la cible... ERREUR : Délai d'attente pour ACK/NACK après 'Synch (0x55 0x55)'

[Bastibilly]

@bglnelissen , thanks for these elements. How did you stop the docker ? Thanks again !

[bglnelissen]

@Bastibilly

@bglnelissen , thanks for these elements. How did you stop the docker ? Thanks again !

I might just have done a ps ax and killed it using its PID.

[brightisolutions]

Hi,

I followed those steps but get into an error and can t manage to update the firmware.

bisol@bisolpc001:~/cc2538-bsl$ ls -la /dev/serial/by-id/

total 0

drwxr-xr-x 2 root root 60 ian 6 08:44 .

drwxr-xr-x 4 root root 80 ian 6 08:44 ..

lrwxrwxrwx 1 root root 13 ian 6 08:44 usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20220811190441-if00 -> ../../ttyACM0

bisol@bisolpc001:~/cc2538-bsl$ sudo python3 cc2538-bsl.py -ewv -p /dev/serial/by-id/usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20220811190441-if00 --bootloader-sonoff-usb ./CC1352P2_CC2652P_launchpad_coordinator_20220219.hex

sonoff

Opening port /dev/serial/by-id/usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20220811190441-if00, baud 500000

Reading data from ./CC1352P2_CC2652P_launchpad_coordinator_20220219.hex

Firmware file: Intel Hex

Connecting to target...

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

bisol@bisolpc001:~/cc2538-bsl$

Also tried using /dev/ttyACM0 but same result

Any idea what I can do ? Thanks a lot

P.S. Doing this on a fresh ubuntu installation and no docker present there...

[bglnelissen]

Hi,

I followed those steps but get into an error and can t manage to update the firmware.

bisol@bisolpc001:~/cc2538-bsl$ ls -la /dev/serial/by-id/

total 0

drwxr-xr-x 2 root root 60 ian 6 08:44 .

drwxr-xr-x 4 root root 80 ian 6 08:44 ..

lrwxrwxrwx 1 root root 13 ian 6 08:44 usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20220811190441-if00 -> ../../ttyACM0

bisol@bisolpc001:~/cc2538-bsl$ sudo python3 cc2538-bsl.py -ewv -p /dev/serial/by-id/usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20220811190441-if00 --bootloader-sonoff-usb ./CC1352P2_CC2652P_launchpad_coordinator_20220219.hex

sonoff

Opening port /dev/serial/by-id/usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20220811190441-if00, baud 500000

Reading data from ./CC1352P2_CC2652P_launchpad_coordinator_20220219.hex

Firmware file: Intel Hex

Connecting to target...

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

bisol@bisolpc001:~/cc2538-bsl$

Also tried using /dev/ttyACM0 but same result

Any idea what I can do ? Thanks a lot

P.S. Doing this on a fresh ubuntu installation and no docker present there...

I had similar issues when an other instance trying to use the dongle. Try to figure out who/what is using the dongle.

[ArkadyGamza]

To those, who see ITEAD_SONOFF_Zigbee_3.0_USB_DonglePlusV2 (note V2 in the end), I guess you have ZBDongle-E model, which is based on a different chip (EFR32MG21). Obviously, you should not try to flash it with CC2652P image. Please refer to https://community.home-assistant.io/t/itead-s-sonoff-zigbee-3-0-usb-dongle-plus-v2-model-zbdongle-e-based-on-silicon-labs-efr32mg21-20dbm-radio-mcu-now-sold-for-19-99/442695

[Bastibilly]

To those, who see ITEAD_SONOFF_Zigbee_3.0_USB_DonglePlusV2 (note V2 in the end), I guess you have ZBDongle-E model, which is based on a different chip (EFR32MG21). Obviously, you should not try to flash it with CC2652P image. Please refer to https://community.home-assistant.io/t/itead-s-sonoff-zigbee-3-0-usb-dongle-plus-v2-model-zbdongle-e-based-on-silicon-labs-efr32mg21-20dbm-radio-mcu-now-sold-for-19-99/442695

And may I add something : to those trying to flash this V2 version of the SONOFF dongle because of issues with zigbee2mqtt in home assistant, just add "adapter : ezsp" to your configuration file and it will work :

data_path: /config/zigbee2mqtt socat: enabled: false master: pty,raw,echo=0,link=/tmp/ttyZ2M,mode=777 slave: tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5 options: "-d -d" log: false mqtt: server: mqtt://core-mosquitto:1883 user: mqtt_user password: *** serial: port: /dev/ttyACM0 adapter: ezsp home_assistant: true permit_join: false frontend: true

[thijstriemstra]

For the ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus I received the same error (Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)') with Windows 10 using COM4. Adding --bootloader-sonoff-usb worked as pointed out by @cpaius.

Full command (using Python 3.10 on Windows 10):

python.exe cc2538-bsl.py -p COM4 --bootloader-sonoff-usb -evw CC1352P2_CC2652P_launchpad_coordinator_20221226.hex

[ph4r05]

I have CC2562P + CP2102N with 3 buttons RST, K1, K2 (not an official Sonoff). There is no Boot button.

I was not able to boot into bootloader, not even with --bootloader-sonoff-usb. In CC2538/CC26x0/CC26x2 Serial Bootloader Interface I noticed that if there is an image loaded, bootloader can be invoked with bootloader backdoor if currently loaded image has it enabled.

After checking https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/Z-Stack_3.x.0/bin/README.md I noticed that firmware usually uses DIO_13 or DIO_15 for bootloader backdoor pin (SET_CCFG_BL_CONFIG_BL_PIN_NUMBER). I hold these pins to low/gnd while RST hold-release and got into bootloader mode. If firmware has bootloader backdoor disabled, cJTAG / JTAG flash erase is needed to get to the bootloader.

[volkmarnissen]

Today, I got the same error Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

After investigation I found out, that my Sonoff Stick had another processor SONOFF Zigbee 3.0 USB Dongle E TI EFR32MG21 + CH9102F. Flashing of Firmware is not needed for this stick.

This can also be an explanation for the issue.

[l-i-n-k]

Hi. I’m joining the ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)' club 😭

My goal: Make the Sonoff Dongle work as a repeater in my Fibaro HC3 based environment

My hardware setup is Mac OS X based (Intel iMac) and a Sonoff Dongle Plus plugged in to the USB of the Mac

ls /dev/tty* | grep usb
/dev/tty.usbserial-0001

A few weeks ago I did successfully flash the firmware:

% python3 cc2538-bsl.py -ewv -p /dev/tty.usbserial-0001 --bootloader-sonoff-usb ./CC2652RB_router_20221102.hex sonoff Opening port /dev/tty.usbserial-0001, baud 500000 Reading data from ./CC2652RB_router_20221102.hex Your firmware looks like an Intel Hex file Connecting to target... CC1350 PG2.1 (7x7mm): 352KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x00057FD8 Primary IEEE Address: 00:12:4B:00:29:E8:BB:A8 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: 0x230d0f6f)

I think you might agree that this was not the right firmware to flash. The script I followed did point me to this. After checking this table the launchpad version is recommended.

Some sources point out that the bootloader might be "locked" after using the wrong firmware 😵‍💫

I still hope that it’s just the OS update or there’s a backdoor I didn’t try so far.

Current situation:

% python3 cc2538-bsl.py -ewv -p /dev/tty.usbserial-0001 --bootloader-sonoff-usb ./CC1352P2_CC2652P_launchpad_coordinator_20230507.hex sonoff Opening port /dev/tty.usbserial-0001, baud 500000 Reading data from ./CC1352P2_CC2652P_launchpad_coordinator_20230507.hex Your firmware looks like an Intel Hex file Connecting to target... ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

I also tried to open the device and hold down the "boot" button while inserting to the USB port and tried multiple variations of releasing it.

🔒 Is it really locked?

[kenschbacher9]

I am facing the ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55) as well.

My goal: I want to flash my Slaesh CC2652-stick as a router with the latest Z-Stack firmware from KoenkK.

After succesfully flashing my SONOFF Zigbee-Dongle Plus I have accidentally flashed my Slaesh-stick with the launchpad firmware CC1352P2_CC2652P_launchpad_router_20221102.hex as well instead of chosing the CC2652RB_router_20221102.hex. Flashing unfortunately worked like a charm, but now I cannot reflash anymore.

Any ideas how to reanimate my Slaesh CC2652?

[tube0013]

you will need to hold the gpio defined in the launchpad fw for bsl Low during boot to get it into bootloader mode. the bsl pins are shown in the chart in the z-stack fw repo.

[kenschbacher9]

you will need to hold the gpio defined in the launchpad fw for bsl Low during boot to get it into bootloader mode. the bsl pins are shown in the chart in the z-stack fw repo.

Thank you very much! It worked indeed :-) GPIO15 with GND

[ppsirius]

@tube0013 or @kenschbacher9 on what GPIO15 you talking about? What I should hold to go to bootloader mode because flag neither button don't work and I still getting :

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

Thanks for info

[optikas]

Hold K1 button (DIO15) BSL Trigger Pin while plunging in USB dongle, Dongle will enter to bootloader