here is the error im gettin:

avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

i read the reponses to this post....

Quote by: Rafiki

I have assembled a Meggy, and it works, but I cannot get it to upload from Arduino. I have spent 2 full days trying, and I have done everything in their troubleshooting section, and followed the relavent threads in their forum. Here is the error I get every time:

avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

i followed the instructions given , power is on, cable is plugged in correctly, proper port selected, checked my soldering, re-installed drivers for the cable, re-installed the software .... did this on 3 computers so far and still getting the same error msg.

help????

-RIK

Unfortunately, that's a blanket error that means that something's preventing you from getting your Meggy Jr into programming mode. Could be a bad connection, bad cable, USB port secretly in use by the computer, missing capacitor, etc.

Also obvious, but have you checked the "Set RTS on close" thing if you're on Windows?

R4 and C6 are crucial for programming, but aren't used for anything else. Double check that these are the right components and that they are soldered correctly. Double-check also pins 1, 2, and 3 of the chip-- the ones closest to C6 -- and make sure that there aren't any flaky possible connections or solder bridges. If you have a multimeter, you might want to verify that end of the schematic as well; make sure that the connections really are good.

When you try programming, does the Meggy Jr reset automatically? Or, in general, how does it act?

If it *does not* reset, you *might* be able to get it to work by pressing the reset button at the right moment.

Also, what's your computer configuration, Arduino version, Meggy version (168? 328?), and cable type?

-Windell

im using windows xp (on all 3 machines ive tried)
Set RTS on close

arduino 0015 /meggy 168

cable is a FTDI USB/Serial cable that i got from EMS

checked solder points visually and with meter ... pins 1,2,3 as well as R4 and C6
also checked the pins that connect to the programming cable ... everythings making connection

the meggy plays its built in game just fine, and yes, im getting a reset when plugging in the cable, also when i hit the "send to i/o board" in the software gui.

completely stumped!

** guess it wont be going to this months robot/electronics meeting
-- have to show it off next time!

=Rik

OK, so the Meggy Jr resets when you try to upload the program, but immediately goes back to the splashscreen, rather than starting to program?

That suggests that you have the right com port selected, and that things are mostly working on the computer side of things... just possibly that the bootloader isn't talking to the computer fast enough. Could be an issue with the resistor/capacitor still-- not giving a long enough reset signal for programming to work.

Do you have the reset button installed? If so, try pressing it just before or just after the reset signal comes from the computer-- that might trigger the programming sequence to begin correctly.

Since you have a meter, also check (if you haven't) to make sure that none of those pins is accidentally connected to one of the others or to power or ground.

tried the bit with the reset switch... no luck.

rechecked the pins that connect to the programming cable .... the pin that connect the black wire and the pin to the brown wire do register connections with each other on my meter ... but from the looks of the traces, they are supposed to... ???

-thanks for the continued help!

-Rik

Yes, the black and brown lines (pins 1 and 2 of the connector) should be connected, and both of them connected to ground as well.

Unfortunately there are still several places that the problem could be-- in the cable, in the capacitor or resistor, or in some strange mismatch between the timing that your computer expects versus what Meggy expects. This is, I must say, pretty unusual. Things usually just work. I do have an alternate suggestion because it's unusual; please contact me off-forum.

Oh-- one other thing non-obvious thing that can cause this error: low batteries. Try a fresh set.

happy to say EMS was able to get to the bottom of the issue!

turns out that the reset delay was too short and xp wasnt able to respond quick enough.

got the delay time reprogrammed to the maximum wait time and now everythings working perfectly!!

thanks again for the great service!!!!!

I am having the same problem right now. I have assembled my meggy with an ATmega328 chip, and the hardware seems to be working fine, except for the programming issue. Here's what i have tried:

1. My main machine is running 64 bit Vista. I used latest drivers from the FTDI website (v2.04.16). I have also tried 32 bit Vista and 32 bit XP with the drivers that ship with Arduino 015. The behaviour is the same in all cases. The machine hardware is identical in each case (Thinkpad T61p, which has two distinct sets of USB ports, i tried both). I haven't tried a different hardware config yet.

2. When I connect the meggy, I get a reset. Also when starting to program. However, after the reset, meggy goes back to playing the previous program immediately, and I get the error below.

3. I have verified soldering connections to R4, C6, chip pins, and connector pins visually, they seem fine. I don't have a multimeter right now, but i'll double-check when I pick one up.

4. I tried your suggestion of hitting the reset button just before the reset signal from the computer, and after some trial and error I managed to successfully re-program the meggy. I have to mash the reset button several times, and occasionally I get the timing just right and programming works, leading me to believe that my soldering is fine. Most of the time, however, I miss and either get the error below, or re-reset the meggy after programming has started and get a flash write error instead.

5. I have tried fiddling with the USB port driver knobs to reduce response latency, etc, to no effect.

So far it sounds like it may be the same problem. What's involved in re-programming the reset delay? Any other advice you can give me?


--- begin error output ---

avrdude: Version 5.4-arduino, compiled on Oct 11 2007 at 19:12:32
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

System wide configuration file is "C:\Users\Simon\Programs\arduino-0015\hardware/tools/avr/etc/avrdude.conf"

Using Port : \\.\COM4
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=0x00
avrdude: Send: Q [51] [20]
avrdude: Recv:
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

Simon,
Since you *can* reprogram the Meggy Jr RGB when you press the reset button at the right time, it sounds like you have the same issue-- that the Meggy Jr is basically working, but that its reset delay is not long enough. If you tried, you would probably find that it does program OK on some other computers-- this seems to be a windows-specific issue.

We have a fix for this, but you would need to reprogram the chip with an AVR ISP programmer (such as the USBtinyISP). If you have one of those, we can send you the files. If not, you could possibly send it to us for reprogramming. If you would like to do that, please use the Evil Mad Science Shop contact form.

i dealt with windell directly ... i didnt do the re-programming....

Thanks, Windell.
I think i will end up getting a programmer, once i do i will ask you for the files.
In the meantime, i kinda got the hang of that reset button timing

Is there anything changed in your bootloader files aside from "MAX_TIME_COUNT"? I started to fiddle with the original code, but all those conditionals hurt my brain... and then everything just pointed me to the makefile.

They hurt my brain as well. I'll get around to posting the "tuned" makefile, but in the mean time, using the standard Arduino bootloader--- as burned from within Arduino --- is a fine option.

I still feel the (almost) uncontrollable urge to diddle with it, but I'll restrain myself for now.