Yup, another Meggy programming question. The good news is that my Meggy is built and working well. I can't wait to get my code on it.

The problem:
This familiar bastard: avrdude: stk500_getsync(): not in sync: resp=0x00

The setup:
-FTDI Programming cable (I got the Meggy super kit).
-Meggy Jr with pre-burned ATmega328 from the EMSL shop.
-Arduino0014 on Windows XP.
---->board selected: Duemilanove w/ATmega328 (I've also tried Duemilanove w/ATmega168, no change)

Troubleshooting so far:
-Went through the Arduino troubleshooting guide, and scoured the forums already.
-Checked for things polling USB, I don't *think* there are any.
-Fixed the "Set RTS on close" thing, but I'm unplugging and replugging before each attempt anyway.
-Checked all the solder joints on J2, C6 and R4, and pins 1, 2, and 3 on the AVR. They all look solid.
-I haven't tried two different computers, but rebooting the same 'puter into Ubuntu and using arduino0013 yields "board not responding" which is probably the same problem?
-Tried programming using an external power source (this was mentioned as the solution to one person's problem in the forums).

One funny thing I did notice is that all the pins of J2 have the expected voltages on them, except pin 1 which is at 0v. With no cable connected, shouldn't R4 pull this up to Vcc? A little tracing reveals that on the AVR side of C6 I have 5v, and on the J2 side I have 0v. The solder looks good and solid. Is this just C6 preventing my multimeter from measuring the voltage on that pin right, or is something up?

My Programming procedure:
1. Plug in FTDI cable to USB and Meggy.
2. Turn Meggy on. Attack of the Cherry Tomatoes starts playing.
3. Click "Upload" in Arduino environment.
4. After a few seconds, the Meggy resets at couple of times, but immediately starts playing instead of programming (what *should* a Meggy that's being programmed look like?)
5. Get the sync error from above.

So, I think that's sufficiently exhaustive. Any ideas, anyone?

Thanks,
-Leander

First of all, it sounds like you're doing everything right-- you're obviously being thorough and careful.

To use the '328, the Arduino Tools menu must have the ATmega328 option selected. Double check that you have the "Meggy End" of the FTDI cable oriented correctly. Double check, with the Arduino Getting Started ( http://arduino.cc/en/Guide/Windows ) guide as a reference, that you have the FTDI USB driver installed correctly and that the correct serial port is *visible* to the Arduino program and selected under the "Serial Port" menu. Do not unplug after every attempt-- just make sure that the right port shows up there. Try a fresh set of batteries-- if your power is marginal that could cause this sort of problem.

Since you have a multimeter, you could (with the Meggy Jr disconnected and and powered down) use the continuity checker to test between the shoulders of the pins of the chip and the pins of the TTL connector. The capacitor connected on the reset line is supposed to do what you've already seen-- prevent a DC connection between the cable and the reset pin. Also double check to make sure that there aren't accidental connections (short circuits) between any of the relevant pins.

One other thing to try would be editing the boards.txt file. It is possible-- but I really hope it is not the case --that our shipper accidentally sent you "the wrong" ATmega328, from an older batch that was burned before Arduino 13 and 14 came out. If that's the case, then the upload speed line in the boards.txt file should be edited to 19200, down from 57600. (See this discussion for example.)

I hope that one of these suggestions works. If not, let me know, and I'll see where we could go from there.

Windell, thanks for the quick reply!

After trying all the stuff you suggested, it turns out it *is* my computer after all - programming with my wife's MacBook worked fine on the first try (and the 328 I got does indeed program at 57600bps).

That leaves why my machine doesn't get along under either Windows or Ubuntu (Intrepid). I tried using a serial sniffer program under windows, and it doesn't show anything but avrdude talking to the Meggy. I wonder why the same machine wouldn't be able to talk to the Meggy under 2 OSes? Is there anything special needed to program the Meggy on linux?

Thanks again,
-Leander

Well, that's odd. I don't know of any reason that it should not be working like that. It suggests to me that there might be some obscure factoid yet lurking in the Arduino forums that will solve the issue.

One thing to be aware of is that serial programming requires not just the regular serial lines, but also manipulation of the reset line. Early Arduino boards required that you physically press the reset button when you programmed them-- we use an "auto-reset" design to avoid this. If the reset line is not being properly manipulated, you might be able to get it to reprogram by pressing the Meggy Jr (optional) reset button just at the moment when it starts to program.

It's a long shot, but there could actually be something hardware-wrong with the USB port on that computer-- try a different port if it's got one, just in case.

I tried all of the USB ports on this machine with no change, so if something is up there it's probably the USB chipset. I did discover by downloading the serial communication example that the Meggy *can* talk normal serial back to this machine.

It does seem like it's something to do with manipulating the reset line properly - when I porgram, the meggy either resets right away and then doesn't program, or resets when avrdude finally gives up. I've tried tweaking around the various parameters in the FTDI driver's settings page with no change.

So I'm looking around for stuff related to that on the arduino forums. Nothing yet, but I'll keep looking.

Thanks again for all the help,
-Leander

Further hacking reveals that it is indeed a problem with tripping the reset line - if I'm extremely lucky poking at the Meggy's reset button while starting avrdude, I can get it to program successfully. Once the meggy gets into programming mode everything seems fine, but it's *really* tricky to get the timing right.

Some analysis with the multimeter reveals that it is at least possible for DTR (==the line connected to RST on the AVR, right?) to get set/reset properly on my machine. Could it be that avrdude is waiting too long after blipping DTR to start sending data, and if that's true, how might I change that? It would explain the reset-but-no-program thing.

Hacking on,
-Leander

Well, this does seem to get more complicated, doesn't it? The fundamental timing of the avrdude software running under different operating systems-- I believe --needs to be the same in order for it to work correctly. So it's hard to imagine that it's strictly a timing problem, since it works on one version.

What's the make and model of your computer? Have you checked the voltage on the USB "reset" line? I'm just wondering if there's something different about the hardware that we haven't figured out yet.

(One possible workaround would be to reflash your Meggy Jr with the standard Arduino bootloader, which gives a three-second delay at turn on, giving ample time to push the reset button by hand. But, that would require that you push the button, and still requires an AVR programmer to do replace the bootloader....)

Truly it does. Ah well, it's worth it, the Meggy is that cool and also hardly the last thing I'm going to want to program with an FTDI cable....

My computer is an Acer AspireOne (mechanical HD version), dualbooting XP and Ubuntu 8.10.

I did discover today that it *is* possible to program under linux with arduino-0013 on the same machine pretty reliably if I reset the meggy just as avrdude starts producing output. Takes a little timing, but much more tolerant than under windows for whatever reason - I can probably operate this way, but at this point I've got me vendetta...

I'll do a little poking tonight with how things behave under linux. When I was messing around under windows, I did notice that DTR (sanity check: green wire on the FTDI plug) would be 5v when virtual comport was closed, and 0v when it was open. However, toggling it manually in a terminal emulator that allowed me to do so didn't have any effect on the voltage - only whether the port was 'open' or not according to the OS. I'd thought this was just a bug in the terminal program I was using, but it seems to behave the same way under linux.

Blipping RTS does reset the Meggy quite reliably. Would it be a bad idea if I just hack avrdude to do this before it starts talking?

Thanks for keeping with this, I know it's getting to be a bit of a saga...

-Leander

Success! My RTS-blipping idea seems to work, at least under linux. If anyone's interested, I'll post a detailed explanation of how to do it without recompiling avrdude.

Windell, thanks for all your help. It's the community and support that really make Making.

-Leander