Go Down

Topic: Second time loading sketch sync error (Read 579 times) previous topic - next topic

bpospick

I have scratch-built a duemilanove using an ATmega328P and an FTDI FT232RL.  It uses a 16MHz resonator and gets power from the USB port. For the 328P to 232RL section, t's built per the reference schematic; double checked the layout and schematic. Running Arduino 1.0.1 on a Windows 7.  Installed the standard bootloader using an UNO (SMD R2).

A sketch [in my case, Blink] will compile and upload only once after the bootloader has been installed.  However, trying to upload any subsequent sketches yields the dreaded "avrdude: stk500_getsync(): not in sync: resp=0x00" error.  This is very repeatable.  I've re-loaded the bootloader 3 times.  Each time the first upload works, but the second time produces the same error.  The blink sketch still runs after power is cycled, so the original [first uploaded] program isn't being lost after power down or after the second uploading fails.

I also tried out optiboot.  Optiboot loaded without problem, but the system choked and didn't upload any sketch; even selected the board type as both a Duemilanove and a UNO; neither worked.

Any suggestions on how to resolve this issue?

spycatcher2k

Check the fuses - The settings are in the boards.txt file. Mainly the Lock bit (0f locked - 3f ULOCKED)
Drew.
http://www.uk-pcb.co.uk - My UK Based PCB Fab & Assembly Company
Design work undertaken
SMD & Thru-Hole assembly

bpospick

They're set at:

atmega328.bootloader.unlock_bits=0x3F
atmega328.bootloader.lock_bits=0x0F


Try burning the bootloader again and before uploading Blink, change the delays to 100ms.
http://www.spcomputing.com

bpospick

Did that to prove that the original sketch wasn't still loaded into memory.  In fact, blink was modified to have different on/off times just to make sure.

I'm building up a second "bare minimum" board - just the FT232RL, 328P and associated circuitry.  This should eliminate the possibility that downstream circuits are the root cause.  More on that later...

bpospick

Found the culprit, issue resolved!!!  I had a 0.1uF cap from the /RESET line to ground.  BTW, this is not the 0.1uF cap inline between the FT232RL (DTR#) and /RESET; that one is still there.  Now I need to see the downstream effects on the peripheral circuit.

Thanks for everyone's help.

All the best,

Bob

Go Up