Standalone Arduino with sparkfun USB - not working

Hello, I’m following the guide here at in order to add USB functionality to my stand-alone arduino and it doesn’t work. First, I thought it might have been the 18.43 Mhz crystal I was using since it wasn’t 16 Mhz, so I bought the only 16 Mhz anything I could find and it was a “canned oscillator” which has 4 pins. After arduously looking for the datasheets(for the chip and the crystal), I finally hooked it up and the circuit ran like it’s supposed to but the USB doesn’t work! Anyways, here’s their picture and mine afterwards.

(Right click and select “view picture” or some equivalent to view it fully.)

Sorry for the mess, but it was originally that way. It’s used to run an electric scooter, so it’s kind of complex. Just ignore all the other wires that don’t connect the crystal and sparkfun FT232R breakout board to the arduino chip and you’ll be fine.

I plugged it in, made sure I had the correct port by checking the device manager, tried to upload the program and… nothing. Well, actually, the USB device’s Red TX LED will blink 3 times with half second pulses, and then there’s a 7-9 second wait, and it’ll blink once more and then I get the inevitable error message:

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

Which seems synonymous with, “There’s a problem”. It seems that this error message can correspond to many different types of problems, so I don’t find it particularly helpful(Well, basically, if the arduino doesn’t receive the signals in the way it’s supposed to, it’ll get this message so I’ve found. I’ve accidentally inserted the chip backwards into the IC socket on the arduino dev board and I got the same error message.)

So, any ideas? The circuit seems to work like it originally designed, so it appears the canned oscillator is working and I can’t help but think it’s reliably sending a 16mHz clock signal, so I thought it was the breakout board. After comparing the two pictures above for many times, I arrived to the conclusion: They’re identical. I even went back to the drawing board and physically compared datasheets just to make sure the tutorial had it correct! Anyways, the circuit’s positive rail is indeed 5 volts so no problems there. And it appears I soldered the header pins correctly since it’s conducting. Suspecting the breakout board might have been bad, I soldered another one together and kept a hawk eye on the temperature of the chip using a thermometer I had and it had the same problems. Interestingly, if I disconnected all the wires from the breakout board but leave the USB cord attached, the LEDs light up in the same sequence, so it doesn’t seem the TX/RX leds are particularly helpful.

Sorry not sure, but just to clear things up, if you say burned the "blink" demo sketch to the chip using an arduino board, then popped out the chip and put it in your breadboard, does it flash at a rate of 1Hz? This is a good test to see if your crystal is working.

Secondly, when the chip is in your breadboard, are you resetting the board just (i.e. 1 second) before you start the sketch upload? It doesn't look like you have hooked up the DTR line, so you couldn't rely on the "autoreset" feature. I'd probably choose the "Arduino NG or older with 168" option (if that's the chip you are using) in the Tools->Board drop down.

The chip came from an Arduino Diecimila and I'll try timing the chip(counting the number of blinks in a minute) to make sure its outputting a faithful 1Hz signal.

Anyways, the reset button is hooked up to "don't reset"(High) so it never resets. Does it need to be reset before the sketch is uploaded? How would the "DTR line" be set up if that's needed? I find it surprising that this would be a necessary step but yet it wasn't mentioned in the tutorial.

Ok, it blinked 30 times in exactly 60 seconds, so I think it's pretty close to being 16 mHz.

I just uploaded some new code to send data over the serial lines and the RX Led on the USB sparkfun adapter was blinking furiously. I checked the serial console and... the data was being received!

When I tried to upload a new sketch, the RX led was still blinking furiously and it seemed the arduino program was hanging. It wasn't even producing an error message! That's a first. :D So I grabbed the old wire and sent the reset line low to reset it, and the characteristic uploading blinky blinky sequence from the RX and TX leds were emitted and it said uploading was a success! Oh, this is so cool! I can now program and check up on my electric scooter(diagnostics) when I'm out riding with my ultra-light EEE 901 laptop! Awesome!

Thanks for helping me out! I really appreciate it! Now, I must ask... how would I connect it so it'd "auto reset"?

No worries - as usual I'll assume the cheque is in the mail.

That tutorial was written before the auto-reset feature was introduced. Notice however this step from the tutorial

"This is where we add the small tactile switch so that we can reset the Arduino whenever we'd like and prepare the chip for uploading a new program. A quick momentary press of this switch will reset the chip when needed. Add the switch just above the top of the Atmega chip crossing the gap in the breadboard. Then, add a wire from the bottom left leg of the switch to the RESET pin of the Atmega chip and a wire from the top left leg of the switch to ground. "

This is how all the arduinos used to be, and the reset button is still there incase auto-reset isn't working. I'd say get this working first before trying auto-reset.

As for how to make auto-reset work, check out the schamtics for the USB breakout board, and the scematics for the newer USB arduinos. I think it's just a 100nF capacitor between the DTR line and the reset pin, but you'll need to check that.

Ok, I just checked the schematic and it appears that this "DTR" line was on the FT232R chip and not the atmega168 chip that I presumed. Anyways, it appears that both the RTS and DTR line on the FT232R chip are individually connected by 100 ohm resistors to the reset input, so it seems it "pulls it down" more than the pull-up resistor "pulls it up" when its active! The pull up resistor is about 10k, so I'm guessing the reset voltage is 1/100th of the supply voltage, so yep... that's how it works methinks. I don't understand why two lines are connected to the reset line, however... it seems only technically one would be needed to drive reset low.

Hey which schematic were you looking at?

If you go here…

the .pdf schematic does show the RTS and DTR lines both connected to RESET via resistors, BUT

there is a note below the link to the schematic

Note that R2 is not mounted and that R3 has been replaced by a 100 nano-farad capacitor.

The newest board schematic shows the capacitor

That sucks. I don't believe I have a .1 uF capacitor. The closest I have is .47 uF.

It won't hurt it to try. Capacitor values can often be an art, not a science!

I'd stick it in and if it works, keep it there untill I could get a 0.1uF

Oh, the .47uF capacitor I had was actually an electrolytic which might be a problem since .1uF capacitors are typically ceramic and the one is the schematic is unpolarized.

I think I just need to get a bunch of .1uF capacitors. Considering how you're supposed to use them "like candy" for noise control, it seems kind of foolish to only have two hanging around.

I left the RTS line unattached and just connected a .01 uF ceramic capacitor(it's only 10 times less capacitance) and it worked! Thanks a bunch! And, don't worry, your cheque is in the mail. :P

Atmel AVR chips are placed in the programming mode by pulling the reset pin low. Check the datasheets. The resistor the pulls it high will be of a bigger resistance, say and I’m guessing 10K ohm. The resistor that pulls it low is, I’m guessing again 1k ohm. Take a look at a schematic of a board from Atmel, Olimex or an Arduino for some good resistor values to use.