Go Down

Topic: Second time loading sketch sync error (Read 594 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
 


Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

Arduino
via Egeo 16
Torino, 10131
Italy