3
\$\begingroup\$

I'm new in this field and I'm working with ardupilot APM 1 (atmega1280), and I got this

error: avrdude: stk500_getsync(): not in sync: resp=0x00

while I was uploading. I've read so many articles on internet and I tried everything to make the board working. I've started having problem three months ago and I always solve it in maximum six days, but now the problem is more frequent and I can't solve it anymore.

These were the things that I tried:

Does anyone have some idea?

Is the board broken?

Is an hardware problem?

EDIT: Verbose of the upload:

avrdude: Version 5.11, compiled on Sep  2 2011 at 19:38:36
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\arduino-0100-relax\hardware/tools/avr/etc/avrdude.conf"

         Using Port                    : \\.\COM20
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Recv: 
avrdude: stk500_getsync(): not in sync: resp=0x00

avrdude done.  Thank you.
\$\endgroup\$
10
  • 1
    \$\begingroup\$ What is 'the right board' and what exact command is executed that throws the error? You may have to enable verbose output in the Arduino IDE Settings. \$\endgroup\$
    – jippie
    Jul 3, 2013 at 12:05
  • \$\begingroup\$ Thank you for helping me. The board is "Arduino Mega (ATmega1280)" and I'm going to add the verbose to the question. \$\endgroup\$
    – DarkCoffee
    Jul 3, 2013 at 12:23
  • 1
    \$\begingroup\$ I had exactly the same problem this morning setting up avrdude using Atmel Studio 6. In the end I found that my Arduino UNO board used a different baud rate (115200) to the 57600 that I was told to use. Not sure if this is the same for you though.. \$\endgroup\$
    – Dave
    Jul 3, 2013 at 12:39
  • 1
    \$\begingroup\$ I also read that Comm numbers > 9 can cause issues, and that changing the port can fix things. Again, this is just one of many possible 'fixes' that are about. 1 error, many causes :/ \$\endgroup\$
    – Dave
    Jul 3, 2013 at 13:57
  • 1
    \$\begingroup\$ If you are dealing with an FTDI USB-serial cable, first disconnect it from the board and use the cable by itself. Get a little piece of wire or a small value resistor and connect the transmit pin to the receive pin. Open a terminal program, disable hardware flow control, and type something. Depending on if the wire is installed or not, you should get one more copy of each character than without (half duplex - 2 copies with, 1 without, full duplex 1 copy with none without). If you can't even open the port, you have a bad cable, wrong driver or are trying the wrong com port. \$\endgroup\$
    – Chris Stratton
    Jul 3, 2013 at 14:40

2 Answers 2

Reset to default
3
\$\begingroup\$

This is not a very explicit error, I give you that. It could be lots of things, but I think I remember I had this particular error a while back because of bootloader issues.

The bootloader on most arduinos listens for a few seconds on the USART, checks and copies a code if it receives a correct one or otherwise just gives up, then calls the main program and does not run in the background. Therefore when the uploader tries to communicate with the board, it might be already running the main program and be unresponsive, hence the "not in sync". The simple fix is to hit "upload", wait for the program to compile, and reset the board just when the program starts being uploaded. There must be a second leeway, but it has always solved the problem.

I think I remember it's also possible to upload a code compiled for another board, which prevents proper synchronisation once the wrong code is uploaded. Not sure under which conditions this can happen (probably when the bootloader is uploaded and run together with the main program as one single program), but that would be worth investigating if none of that works.

Last resort, I'd buy a programmer (it's a good investment) and upload a fresh bootloader+blink program.

Either way, I'd look at the bootloader code of your platform online. Not only there might be the answer to your problem, but you'll also find the baudrate you're supposed to talk to the board with (19200 in the newest versions, it seems). If you never tempered with the bootloader, it should be the stock one.

Without external components connected to force short circuits on the outputs etc. it is virtually impossible to break a board by experience.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ I tried alot things before i come here. But this solution solved my problem. \$\endgroup\$
    – Raghu
    Sep 20, 2020 at 17:30
  • 1
    \$\begingroup\$ Pressing reset just as the flash is about to start was the solution for me. Thanks! \$\endgroup\$
    – Chris
    Jun 5, 2022 at 17:38
0
\$\begingroup\$

I had exactly the same problem. I tried installing the IDE on another laptop and uploaded the program from that laptop. Problem solved. Then I came back to my laptop, uninstalled the IDE and re-installed it and then it worked.

However, I wasn't satisfied because I couldn't find the source of the problem, so I tried running everything again the same exact way. I found the problem but not sure if that can be the actual cause of it:

In my project, I needed to carry out serial communication between an Arduino and MATLAB (GUI). In order to see/verify the output (type) of the MATLAB (GUI) serial data, I used HyperTerminal and also virtual serial port emulator. I noticed that every time when HyperTerminal is running or VSPE is running while my serial monitor is on it screws up the uploading feature of the program. I'm not sure if its because of the VSPE or HyperTerminal, but reinstalling the IDE worked for me.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.