stk500_getsync() not in sync problem

Hi,

I bought some RBBB(w/atmega 328) and usb-ttl conversor board from modern-device [1]. I'm using arduino-17 IDE, ubuntu-linux (board: Duemilanove or nano w/atmega 328, port: /dev/ttyUSB0). I play with other arduino boards (mega, seeeduino) and all works ok.

First time i upload a sketch to the RBBB all works ok, i tested the sketch and runs ok inside the RBBB. After that i can't upload more sketches to the same RBBB and show the messaje:

avrdude: Send: 0 [30] [20] avrdude: Send: 0 [30] [20] avrdude: Send: 0 [30] [20] avrdude: Recv: . [00] avrdude: stk500_getsync(): not in sync: resp=0x00 avrdude: Send: Q [51] [20] avrdude: Recv: . [00] avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x00

I reheat the soldering joints on the BUB headers and RBBB header. I saw the chip is firmly seated in socket.

I tested reset button and works ok.

I think it's about auto-reset... but i dont know..

I tried it two differents RBBB boards, with the same results. upload proccess fails after the second time.

suggestions are welcome

Thanks!

[1] http://moderndevice.com/

pd: sorry about my poor english skills.

Hi there,

by any chance does your sketch use the Serial bus at all?

-Miles

Yes, this output is from a board that runs a sketch using serial line, and the others 2 RBBB have hello world blinking sketch... the output-errors are quite diferent in both cases, but with same result: cant upload after 2 time.. i tested the signals with oscilloscope and all seem to be ok, included DTR.. is it possible to upload a sketch to these RBBB using a duemilanove 328 board? i'll debug this in the future , but i need to upload a sketch for a birthday gift this week :o

Checkout the "Reset Sources" section of the Atmel datasheet appropriate for your atmega chip.

I experienced a similar issue attributed to a watchdog timer reset only yesterday, and am now surprised at just how common this type of problem seems to be. http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1258251558

I recall other discussion about how some details around mucking up the serial DTR could cause constant resets... worth a search.