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

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.)

About this issue

  • Original URL
  • State: open
  • Created 7 years ago
  • Comments: 39 (5 by maintainers)

Most upvoted comments

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)

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

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

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.

To those, who see ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2 (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

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