Not in sync: resp=0x10, protocol error resp=0x54

Hello all, thanks for reading.

My first board - Freeduino Maxserial from Fundamental Logic. Purchased as kit with Atmega 328 and assembled by me.

It seems to be generally working well after assembly - on powerup, power LED lights, and the pin13 LED displays a blinking pattern: 2 blinks, then a “fade in” blink. I believe this means the bootloader is present on the Atmega and the device should be ready.

Hooked up to the COM1 port on Windows Vista machine. Arduino IDE is set for COM1 (no other choices) and the Board is set to the Duemilanove w/ Atemega 328.

Here are the results of uploading the Blink sketch with upload verbose mode.

avrdude: Version 5.4-arduino, compiled on Oct 11 2007 at 19:12:32
         Copyright (c) 2000-2005 Brian Dean <link snip>

         System wide configuration file is "G:\arduino-0015-win\arduino-0015\hardware/tools/avr/etc/avrdude.conf"

         Using Port            : \\.\COM1
         Using Programmer      : stk500v1
         Overriding Baud Rate  : 57600
avrdude: ser_open(): setting dtr
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Recv: 
avrdude: stk500_getsync(): not in sync: resp=0x10
avrdude: Send: Q [51]   [20] 
avrdude: Recv: 
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x54
avrdude done.  Thank you.

When I hit “Upload”, after a couple seconds, the pin13 LED changes its blink sequence to 3 blinks, fade-in blink. It gets through this sequence twice before erroring. So, something is talking, but the upload isnt completing.

I’ve hit all the common issues and troubleshooting tips, so Im rather stuck. Can anyone indicate whether this sounds like a software problem (IDE settings), hardware problem (I screwed up the assembly somehow) or what-have you? Little lost on this one.

Thanks again everyone,

Do you have the option to test the board on a machine not using V*sta ?

Thank you for the suggestion, I will be able to test it with a different machine on XP once the work week starts, and mac/linux if necessary to get other results.

Googling around a bit, I see a few indications that Vista may have some serial port issues? If I have any luck on another OS, I'll definitely report my findings.

Is there any good primer on the nature of this handshake that is happening (or in my case, failing)?


Today I'm able to try this out on a windows XP machine. Different symptoms, still a net loss however.

With power and no serial connection: Pin13 LED is "blink, blink, fade in, repeat" With power and serial connection: Pin13 LED is "blink blink" once, then "fade in, fade out" repeating. I guess this is promising, but I havent found anywhere spelled out what these blink codes really translate to.

No longer getting "resp=0x54", now just the dreaded "Not in sync: resp=0x00. Protocol error, resp=0x51".

Ive still got the board selected right, Ive tried it with speeds set at 57600 and 19200. Tried it with varying permutations of "reset, upload, wait". Tried it with the Rx/Tx pins shorted as indicated on the troubleshooting page.

Some posts on this forum have me wondering if I should try to simplify life by replacing the 328 with a 168.

Is there anything I can do to query the board directly to see if I can validate anything thats going on here? Any way to echo from the RS232 chip to verify thats working OK? A way to ping the bootloader directly with hyperterminal?

any further contribution is definitely appreciated. Without much further luck, i feel I might get a second, prebuilt board with USB and the works out of suspicion of accidental damage during construction.


Well if you have shorted the RX/TX pins (and removed the atmega before) what did you see ?

Did you get an echo of everything you send to the chip. This could be done with the serial monitor or even the infamous Hyperterm. Should be independent of port speed too. If that works reliably, the bootloader may have gone to the fritz. If you were thinking about getting an AVR programmer (25$ range) this is the time. A replacement chip should work too.

You raise a good point for the echo test. I jumpered the pins on the serial cable to make sure the port was working (it is - great reference here for anyone interested:, then took the chips out of the board and jumpered the pins on the RS232 socket to duplicate that test (still good). Also took the chance to generally check that there werent any short circuits or anything from the DB9 connector through the RS232 socket. Everything seems pretty good there.

Now, Im still a novice at a lot of this, so i may have interpreted the diagram wrong, but to take the Atmega out of the equation, I should be able to short pins 9&10 on the RS232 (R2Out, T2In, aka Rx/Tx) with the RS232 installed, attach power and have a successful echo test on the terminal, correct?


(edit: 9&10, not 8&9, just a typo there)

Well, when shorting the RX/TX pins on the RS232 cable you only test if your PC’s serial port and the cable work or not.

Nothing more.

You haven’t tested if the signal actually gets to the microcontroller. That can only be done by shorting the RX/TX pins directly on the cpu’s socket after removing the chip.

Right, right, I appreciate that. Thats the "test the assumption" case. I kept on typing RS232 in my last post instead of differentiating it from the Max232, ie the actual chip. Sorry about that.

My goal was to determine if I could tell whether the Max232 serial comm chip is working or borked. With the chip installed, shorting the RX/TX pins on it should take the rest of the board out of the equation and provide an echo test through the chip, no? (unless Im misunderstanding an aspect of the chip's function).