UART gets avrdude stk500_getsync() not in sync resp=0x00

I bought a generic Multiwii SE 2.5 a few months back and it's been nothing but trouble ever since. I can't flash firmware on the board. I tried first using an FTDI and kept getting errors when when it came to the upload portion of flashing the board. And yes I downloaded the drivers and all. My computer just wouldn't read it. So I exchanged it and got a UART. I'm assuming that it works since I can plug it in to use Multiwiiconfig.exe. But when I try to load the firmware I get this message::::

avrdude stk500_getsync() not in sync resp=0x00

Can someone please help me???

If I understand you correctly, you are able to connect and communicate with the board through mutiwiiconfig.

Having had a look at the board's description I think I might know what is wrong. The board seems to be using the arduino's bootloader, with the help of avrdude, as a means of uploading its firmware in hex format. If that is the case, your failure to upload would point to one of two possible situations:

  1. Your board is, somehow, failing to autoreset when you try to upload the firmware.
  2. Your board is missing its bootloader.

Can you please provide me with a link to the UART cable you are using. This will allow me to determine if it is actually able to reset the board during upload.

Yes that is correct I am able to connect and communicate with the board through multiwiiconfig.exe.

Here is the link to the UART I'm using.

I see that your UART actually carried the reset pin which is great. I would like to know, however, how do you have it connected?

Disregard the above... I was actually wrong. The RST pin (used to reset the UART) differs from the DTR pin (needed to reset the multiwii).

I have it connected via the UART pins on the FC in order of .....

5v to 5v
RX to TX
TX to RX

Using the supplied 1 to 4 plug.

Is that bad what you said above? Should I order a UART with a DTR pin?

Unfortunately I don't think you will b able to use that UART to upload the firmware, well not without a bit of risk.

The FTDI cable you mentioned earlier was it one similar to this?

It was a basic breakout made by CRIUS. Here's the link....

Do you by any chance recall the errors you were getting when you tried to upload using that?

To be honest my computer never recognized the FTDI as being on a port I tried a lot of stuff including downloading the drivers. I also tried both using another computer and it was the same problem. Computer wouldn't recognise FTDI and AVRdude when using UART.

To be honest I only remember it saying error uploading but can't remember the error code.

Okay, and you say you no longer have access to that correct? I ask because your current UART doesn't have the pin necessary to reset the board, initiating the upload.

No sorry but I an order what ever I need. Just tell me what I need to make sure it has. I'd rather use a UART if at all possible just cause I'm afraid of buying another FTDI that my computer might still not recognize.

Final Edit:

Okay. I will detail what will be needed to use your present UART to program the board. Before I do so, however, I must point out that you can still try yet another FTDI board, or even another UART which supports the autoreset. Using one of those would make most of the following, bar the connection instructions, redundant.

The steps detailed below will essentially enable you to replicate the function of the FTDI using your present hardware, but will be a bit more involved and maybe even risky.

  1. You will first need to connect your current UART to the FTDI connector.


Using the above picture to locate the pins; the corresponding connection to your present UART would be (where NC means not connected) :

1: NC (for now)
2: RX
3: TX
4: VCC
5: NC
6: GRN
  1. To upload the firmware you will then need to be able to reset the board. To do this manually you will need to connect a jumper between pin one and a ground point on the board. This draws the reset pin of the on-board micro-controller to ground, resetting it and should allow the program to communicate with it.

You can generally get away with holding the board in reset (grounding the pin), until the Arduino IDE reports the size of the sketch. At which point you would remove the connection to ground, allowing the micro-controller to power-on. If all goes well this should be all that is required to update the firmware on your board.

If you are unclear on any of the above let me know and I will try my best to clarify.

All right it's a lil late tonight, but I can try tomorrow.

When you say connect a jumper from pin 1 to a ground is there a preferred grpund or any one on the board?

And thank you so much for your help.

Anyone would do. The pin just has to register a low signal for approximately 2 milliseconds to reset the controller. On a regular Arduino the same would be achieved by the reset switch, however as you are lacking one you will be forced to improvise.

Ok I hooked it up like it says above and connected pin 1 to the UART ground and still get AVRdude. But I checked it with multiwiiconfig and it does communicate with it.

Would this UART work.

Theoretically the UART you linked to above should work as it has the required DTR pin.

I am a bit hesitant to guarantee that it will though. Manually resetting the board, at the correct time, should yeild the same results as having the upload initiated by the UART.

How many LEDs are on the muliwii board?

I've only seen the two. The green light on the right hand side and the blue at the middle top. I just checked for more but it's only two.

By any chance does any of these two blink rapidly, say 3 or 4 times, when the board is just powered on?

While it's connected to the UART and plugged into the computer the green light immediately comes on and stays and the blue light flashes a series of flashes.

Also found this Diagram on UV3R projects page looking more into wiring the pair together.

The diagram above is similar to how I had you connect them previously, the difference being that your present UART lacks the DTR pin. I am, also, now more convinced that the second UART you linked to will be able to work. It has the DTR signal broken out to a pin, as well as a pad (at the back) that can be soldered to to get the CTS signal should you really need it.