Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
mohanmaniramesh opened this issue Feb 19, 2019 · 16 comments
Closed

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

mohanmaniramesh opened this issue Feb 19, 2019 · 16 comments
Assignees
@MrKevinWeiss
Labels
Area: toolchain Area: toolchains; everything related to compilation, libc, linking, …

Comments

@mohanmaniramesh
Copy link

hello all,

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

I'M ATTACHING THE OUTPUT OF ./print_toolchain_versions.sh
Operating System Environment

   Operating System: "Ubuntu" "18.10 (Cosmic Cuttlefish)"
             Kernel: Linux 4.18.0-15-generic x86_64 x86_64

Installed compiler toolchains

         native gcc: gcc.real (Ubuntu 8.2.0-7ubuntu1) 8.2.0
  arm-none-eabi-gcc: missing
            avr-gcc: missing
   mips-mti-elf-gcc: missing
         msp430-gcc: msp430-gcc (GCC) 4.6.3 20120301 (mspgcc LTS 20120406 unpatched)

riscv-none-embed-gcc: missing
xtensa-esp32-elf-gcc: missing
xtensa-lx106-elf-gcc: missing
clang: clang version 7.0.0-3 (tags/RELEASE_700/final)

Installed compiler libs

arm-none-eabi-newlib: missing
mips-mti-elf-newlib: missing
riscv-none-embed-newlib: missing
xtensa-esp32-elf-newlib: missing
xtensa-lx106-elf-newlib: missing
avr-libc: missing (missing)

Installed development tools

              cmake: missing
           cppcheck: missing
            doxygen: missing
             flake8: missing
                git: git version 2.19.1
               make: GNU Make 4.2.1
            openocd: Open On-Chip Debugger 0.10.0+dev-00689-g6c2020eb-dirty (2019-02-13-18:59)
             python: Python 2.7.15+
            python2: Python 2.7.15+
            python3: Python 3.6.7
         coccinelle: missing
@mohanmaniramesh
Copy link
Author

Sorry I didn't exported the toolchain path in the above ./print_toolchain_versions.sh the below one is correct

Operating System Environment

   Operating System: "Ubuntu" "18.10 (Cosmic Cuttlefish)"
             Kernel: Linux 4.18.0-15-generic x86_64 x86_64

Installed compiler toolchains

         native gcc: gcc.real (Ubuntu 8.2.0-7ubuntu1) 8.2.0
  arm-none-eabi-gcc: arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.1 20181213 (release) [gcc-8-branch revision 267074]
            avr-gcc: missing
   mips-mti-elf-gcc: missing
         msp430-gcc: msp430-gcc (GCC) 4.6.3 20120301 (mspgcc LTS 20120406 unpatched)

riscv-none-embed-gcc: missing
xtensa-esp32-elf-gcc: missing
xtensa-lx106-elf-gcc: missing
clang: clang version 7.0.0-3 (tags/RELEASE_700/final)

Installed compiler libs

arm-none-eabi-newlib: "3.0.0"
mips-mti-elf-newlib: missing
riscv-none-embed-newlib: missing
xtensa-esp32-elf-newlib: missing
xtensa-lx106-elf-newlib: missing
avr-libc: missing (missing)

Installed development tools

              cmake: missing
           cppcheck: missing
            doxygen: missing
             flake8: missing
                git: git version 2.19.1
               make: GNU Make 4.2.1
            openocd: Open On-Chip Debugger 0.10.0+dev-00689-g6c2020eb-dirty (2019-02-13-18:59)
             python: Python 2.7.15+
            python2: Python 2.7.15+
            python3: Python 3.6.7
         coccinelle: missing

@PeterKietzmann PeterKietzmann added the Area: toolchain Area: toolchains; everything related to compilation, libc, linking, … label Feb 19, 2019
@MrKevinWeiss
Copy link
Contributor

So this was attempted to be dealt with on the RIOT users list. I have not been able to reproduce the issues though. It seem like a serial connection is left open somehow. The bootloader pin should be 6 according to the rev 14 schematics and the fact that @mohanmaniramesh bricked a number of devices when changing it to pin 7 leads be to believe that it is correct.

@mohanmaniramesh please clearly how you recover from the "Timeout waiting for ACK/NACK" state. Once a device cannot be flashed how do you get it to flash again (ie. reset the computer, reopen the console, replug the board). I know I already asked this but I need to know how it gets back to being able to flash.

FYI for other maintainers, I have spent a long time with both private and public emails going back and forth. Any help to clarify or test and try to reproduce the issues are appreciated,

@mohanmaniramesh
Copy link
Author

hello @MrKevinWeiss
openmote developer Mr.peretuset only told me that bootloader pin number is 7 thats the reason i changed even i changed it for only one board before that the original code with bootloader pin 6 was bricked 4 boards
its not flashing even i restart ,replug and reopen the console also

@MrKevinWeiss
Copy link
Contributor

Ya the bricked boards won't work. You will need to reflash a program with the correct pin. I am interested in the working boards and what is done after the failed flashing attempt to get them to work.

@mohanmaniramesh
Copy link
Author

sorry @MrKevinWeiss the bootloader pin is 6 only. I checked the scematic and i asked again to the pere tuset that was his mistake he told wrong

@siddharthgpta
Copy link

@mohanmaniramesh @MrKevinWeiss
I am using the openmote-B for a research project, and had borrowed a few devices from my university lab. When I first tried to flash the devices I was getting the same error:

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

Initially, I thought that it was not selecting the right port and started looking in my /dev folder to figure out the port and found 2 ports belonging to the mote tty.usbserial-xxxx0 and tty.usbserial-xxxx1.

I then tried flashing the device with port tty.usbserial-xxxx1 using the command:

$ BOARD=openmote-b PORT=/dev/tty.usbserial-xxxx1 make flash

This was the command that was being called for flashing though:
{path_to_RIOT}/dist/tools/cc2538-bsl/cc2538-bsl.py -p "/dev/tty.usbserial-14200" --bootloader-invert-lines -e -w -v -b 460800 {path_to_RIOT}/examples/gnrc_networking/bin/openmote-b/gnrc_networking.bin

This did not work as the script for some reason was still taking the old port (i.e. tty.usbserial-xxxx0). So I manually copied the command and modified the flashing command to use port tty.usbserial-xxxx1:

{path_to_RIOT}/dist/tools/cc2538-bsl/cc2538-bsl.py -p "/dev/tty.usbserial-14201" --bootloader-invert-lines -e -w -v -b 460800 {path_to_RIOT}/examples/gnrc_networking/bin/openmote-b/gnrc_networking.bin

I was successfully able to flash the code and able to use make term on this port. Hopefully this helps someone who is stuck in a similar situation.

@mohanmaniramesh
Copy link
Author

mohanmaniramesh commented Mar 10, 2019 via email

@MrKevinWeiss
Copy link
Contributor

For future reference you can overwrite the flasher port by setting the PORT_BSL={desired_port}. The PORT= variable should only be for the term.

@mohanmaniramesh can I close the issue?

@mohanmaniramesh
Copy link
Author

mohanmaniramesh commented Mar 13, 2019 via email

@guyyst
Copy link

guyyst commented Apr 11, 2019

I'm having the exact same issue and verified that cc2538-bsl.py is being called with the correct port, but it's still always failing with

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

I can reset the board over JTAG just fine and flash successfully, but having to do that every time can't be the solution.

@mohanmaniramesh
Copy link
Author

mohanmaniramesh commented Apr 12, 2019 via email

@guyyst
Copy link

guyyst commented Apr 12, 2019 •
edited
Loading

I think you may have misunderstood, my issue is not with an incorrect call to the cc2538-bsl.py script.

This is the output of make flash BOARD=openmote-b:

make flash BOARD=openmote-b
Building application "hello-world" for "openmote-b" with MCU "cc2538".
[...]
{path_to_RIOT}/dist/tools/cc2538-bsl/cc2538-bsl.py -p "/dev/ttyUSB1" --bootloader-invert-lines -e -w -v -b 460800 {path_to_RIOT}/examples/hello-world/bin/openmote-b/hello-world.bin
{path_to_RIOT}/examples/hello-world/bin/openmote-b/hello-world.bin
Opening port /dev/ttyUSB1, baud 460800
Reading data from {path_to_RIOT}/examples/hello-world/bin/openmote-b/hello-world.bin
Cannot auto-detect firmware filetype: Assuming .bin
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'
make: *** [{path_to_RIOT}/examples/hello-world/../../Makefile.include:538: flash] Error 1

And by checking ls /dev/tty* I can clearly see that my board is indeed on the port /dev/ttyUSB1, so copying and pasting the call to cc2538-bsl.py wouldn't help anything.

To demonstrate I can directly call:

{path_to_RIOT}/dist/tools/cc2538-bsl/cc2538-bsl.py -p "/dev/ttyUSB1" --bootloader-invert-lines -e -w -v -b 460800 {path_to_RIOT}/examples/hello-world/bin/openmote-b/hello-world.bin

and as expected get the output:

opening port /dev/ttyUSB1, baud 460800
Reading data from {path_to_RIOT}/examples/hello-world/bin/openmote-b/hello-world.bin
Cannot auto-detect firmware filetype: Assuming .bin
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

@siddharthgpta
Copy link

Is /dev/ttyUSB1 the only USB device you can see?

Can you tell us the output of:

ls /dev | grep -i usb

@guyyst
Copy link

guyyst commented Apr 13, 2019 •
edited
Loading

Sure:

ls /dev | grep -i usb
ttyUSB0
ttyUSB1
vboxusb

ttyUSB0 has never worked, even when the bootloader has been enabled via JTAG. It always throws the Synch (0x55 0x55) error. And vboxusb is obviously just a virtual box adapter.

@siddharthgpta
Copy link

I'm not sure what's causing the issue. Did ttyUSB1 work at any point, if so when did it/what caused it to stop working?

@guyyst
Copy link

guyyst commented Apr 13, 2019

ttyUSB1 has always worked when the device on that port has an unlocked bootloader.

If I reset the device with JTAG every time before trying to flash a new image everything works just fine, but that can't be the intended solution.

As the header file of the OpenMote-B suggests, the bootloader backdoor should be enabled, it just doesn't seem to work for me.

#define CCA_BACKDOOR_ENABLE       (1)
#define CCA_BACKDOOR_PORT_A_PIN   (6) /**< BSL_BOOT Pin */
#define CCA_BACKDOOR_ACTIVE_LEVEL (0) /**< Active low */

@MrKevinWeiss MrKevinWeiss mentioned this issue Jun 13, 2019
Closed
@MrKevinWeiss MrKevinWeiss mentioned this issue Jul 12, 2019
Merged
@LeoLee0097 LeoLee0097 mentioned this issue Aug 10, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@MrKevinWeiss MrKevinWeiss

Labels
Area: toolchain Area: toolchains; everything related to compilation, libc, linking, …
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@PeterKietzmann @siddharthgpta @MrKevinWeiss @guyyst @mohanmaniramesh