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

I have a sanguinololu 1.3a, ATmega644p which I'm failing to upload anything to. At least I assume its not loading as the LED doesn't respond to the blink test. Instead I get the error; avrdude: stk500_getsync(): not in sync: resp=0x00 (with some variation at the end) I got it with the bootloader (apparently) already loaded. I am running Arduino 1.0.4 IDE with the Sanguino board additions from sanguino-0101r1.zip and Marlin-Marlin_v1 (with baudrate 250000 and motherboard 62 defined in configuration.h). From a laptop running windows 7. I'v tried changing the speed in the Board.txt and I get worse errors if I change it from 38400 so I have left it at 38400. Iv tried the walk-around that the reprap wiki suggests (releasing the reset button as upload starts) but this hasn't worked for me. I also get this error when I try to burn a new bootloader from the Arduino IDE. I don't know which 'programmer' option i should have selected but i have tried it with all of them to no avail. I think I am out of options and may have to send the hardware back. Can anyone see something I'v missed? Any help would be greatly appreciated.

When you plug in the USB, does the FTDI enumerate? Did you build the Sanguinololu yourself?

Im not quite sure what you mean by enumerate. I'm very new to all this. When I plug in the USB a new port (USB Serial Port COM8) appears in the Device manager so I select that in the IDE (its the only option). I soldered the 4 driver chips myself, other than that it was assembled when i got it.

Sorry, had my tech head on. The "USB Serial Port COM8" in your device manager means that the FTDI has enumerated, so USB to FTDI is good. The manual reset is a little tricky without the TX/RX leds. I usually hold the button down and when the sketch size display appears, give it another 750ms then release.

Do you have a jumper on the AUTO-RESET or JP25? Location appears (v1.3a) to be by pins 8,9,10 of the Atmega664.

That one enables the 100nF capacitor that would trigger the reset automatically.

I also get this error when I try to burn a new bootloader from the Arduino IDE. I don't know which 'programmer' option i should have selected but i have tried it with all of them to no avail.

Do you have a programmer? You will not be able to put a bootloader on without a programmer (or another Arduino turned into a programmer). You will have to connect with the 2x6 header on the lower right next to the reset button.

The guys I bought it from said there is already a bootloader on there. I only tried the option of burning one in the IDE because I had tried everything else and wondered what would happen! I can only connect to the Sanguinololu via a USB cable at the moment, i have minimal equipment. There is a black 2X3 header next to the reset switch. Does that help?

That’s the one. It is the In Circuit System Programmer (ICSP) header. It is the master communications to the micro-controller. If you had a AVR programmer you can connect to that header and put the bootloader or a sketch (it will overwrite the bootloader) onto the micro-controller. Your USB to FDTI to the micro-controller is through the micro-controller’s UART or serial communications (like that old modem thingy).

Did you find that Auto-Reset header next to the Atmega664 pins 8-10? I do not see a user led on the board, just the power led and it is just connected to the 5V power.

Anyhow, if you can not get it to upload with manual reset or with the enabled Auto-Reset, you more than likely have a corrupted bootloader and suggest an contacting the guys you bought it from.

I found myself writing a small essay to describe my board so I’v attached a picture instead. I don’t have the equipment to connect to the ICSP and I’m not sure I want to go to all the trouble when I paid for it to have a functional bootloader already on there. One last question before I complain to the supplier. Is there anyway that me soldering on the driver chips poorly could have corrupted the bootloader?

Of course there is risk of a electrostatic discharge (ESD) while soldering, especially when the weather is below freezing, and you will have no humidity. Unless one takes precautions like a grounding strap and usage of anti-ESD tools, your electronic devices are susceptible to greater than 10kV events.

If you take a picture of the flip side of that board, I can see if I can visually see anything standing out in you solder job.

Does the power LED seem dim to you? I know it is one of those clear reds, so it has a smaller viewing angle (top view) and did not show up in the picture. If so, you may have a short on your power circuit. If you have a DVM, you could check the voltage across the LED solder joints (should be 4.5-5 VDC on USB).

I only soldered the 4 driver chips on the top. The rest was done when i got it but here’s a picture anyway. Im pretty sure the LED is fine, its very bright (was not on when i took the photo!).

The soldering looks good to me. No bridges or cold solder joints to be seen. Probably just the bootloader is corrupted.

I would suggest to give your Sanguinololu vendor a call or email. Also, I would also consider picking up a programmer or an Arduino, could be a handy diagnostics tool in the future.

Stormbeard I'm having the same problem. avrdude: stk500_getsync(): not in sync: resp=0x00

I'm running window 7 32 bit I have Sanguino ATMEGA644P pre built , tested and loaded with boot loader. The usb appears to work at least show the printer plug and unpluged and I can move ports tried 3, 4, 5 and 8 Software (Marlin v1) sees the different ports when I move them I've tried all the fixes I can find changing com ports holding reset down I do have the jumper on auto reset I bought a USBtinyISP AVR Atmel programmer redid the boot loader it said it worked but I still get the same error. bought an other board pre built and loaded different supplier still I get avrdude: stk500_getsync(): not in sync: resp=0x00 I have no more hair to pull out. Has anybody have an idea what to do next ?? 2 boards same problem


rji006: Stormbeard I'm having the same problem. avrdude: stk500_getsync(): not in sync: resp=0x00

I'm running window 7 32 bit I have Sanguino ATMEGA644P pre built , tested and loaded with boot loader. ... rji006

Which Arduino IDE version are you using? Also, since you have a TinyISP, can you get your fuse settings from you 644p?

Here is another frustrated customer, but it looks like a problem that some of us had with the 1284p DIP model getting noise on the UART. http://dustsreprap.blogspot.com/2011/06/sanguinololu-fuses.html


Anyhow, "Dust" seems to be still running his blog and may have some suggestions other than the fuse settings.


I'm running 023 Arduino ide upon looking looking closer the 644p it is not. It is a atmega 1284p pu1247 this is (board 2) (board 1 is the 644p board 1 it is set aside for now) I'm going back to check things to see what deference this makes as far as the TinyIsp I have not tried it on (board 2) I need to study up on the use of it. I am not sure about the fuse thing (how to change) but it sounds good. One more thing (board 2) has never been in the printer its on the bench no 12 v power just usb power no stepper diver boards plugged in. Is this OK. I've never been able to talk to it Thanks for your time rji006

Here is a handy GUI for checking fuses, burning hex etc. http://avr8-burn-o-mat.aaabbb.de/avr8_burn_o_mat_avrdude_gui_en.html

Until the fuse settings are optimized, serial communications are next to impossible. It was a bit of work to get my breadboad "mega 1284" up, and the others extensively troubleshot the problem. The results were the XTAL pins on the DIP were too close to UART0 and noise was carrying over into the serial communications (ATMEL defect), but only on SOME chips. The SMD 1284p has no troubles, and I thought it was odd the 644p had no trouble.

Just a note, the TinyISP will not be able to bootload the 1284p. The 644p (64k) flash is the limit for that programmer. If you have another Arduino, you could use it as a Arduino as ISP and get the bootloader on. You should be able to change fuses though. Other than the flash, 1284p and 644p are functionally identical.

In the end, nothing seemed to work so I sent it to a friend and he assures me that the microcontroller is dead. I complained to the guy I bought it from and he said (in a very rude e-mail!) that I must have destroyed it myself. I don't know how I could have done this. Is there a special way to plug in and unplug the board by USB? Coz that's all iv done. I'm now really nervous about trying it again as my friend fixed it. And ideas on how I could have bust it? Might I have been treating it badly by accident?

If you got a cable on the TX / RX ports, unplug him, then upload and after plug again, you need to do that every times you will want to upload something. that resolved the problem for me.

have a nice day

Hi Gentlemen I am having the same problem. Exactly same problem. If anyone solve the problem, please share with me.


Hi I managed to solve the problem already. I bought sanguino a few months ago, 2pcs. I thought bootloader is already loaded and I tried to download the sketch with Sanguino board but it was an same error shown for both Microcontroller. Now what I did was that I burn the bootloader with USBTinyISP programmer again. Then disconnect programmer and download the sketch with Sanguino. It works. So my conclusion is that it was bootloader problem.

Those who have same problem, you can try burning bootloader again and try again. Good luck. :D

I am looking for a solution to a similar problem. I have an arduino that works fine with its original atmeg chip. I have just purchased a replacement chip off e-bay, I am assured it has the bootloader in. If I upload the example 'blink' I am getting avrdude: stk500_getsync(): not in sync: resp=0x00 as well . If I put the original chip in, load 'blink in , it works fine. Is it likely that I have no bootloader in. If no bootloader on mine gives avrdude: stk500_getsync(): not in sync: resp=0x00 I suppose it could be the same with yours Stormbeard.

Based on your description, it is very likely that it is chip problem. Either chip is dead or bootloader corrupted or no bootloader. No harm trying reboot again as chip is not working anyway.