Using Port : /dev/ttyUSB0 Using Programmer : stk500v1 Overriding Baud Rate : 19200avrdude: Send: 0   avrdude: Send: 0   avrdude: Send: 0   avrdude: ser_recv(): programmer is not respondingavrdude: stk500_recv(): programmer is not respondingavrdude: Send: Q   avrdude: ser_recv(): programmer is not respondingavrdude: stk500_recv(): programmer is not responding
avrdude: ser_recv(): programmer is not respondingavrdude: stk500_recv(): programmer is not responding
avrdude: Device signature = 0x1e9406avrdude: Expected signature for ATMEGA328P is 1E 95 0F Double check chip, or use -F to override this check.
/path/to/avrdude -C/path/to/avrdude.conf -v -v -v -v -patmega328p -cstk500v1 -P/dev/ttyUSB0 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xDA:m -Ulfuse:w:0xFF:m
avrdude: verifying ...avrdude: verification error, first mismatch at byte 0x0000 0x3f != 0x00avrdude: verification error; content mismatch
This could be because the auto reset circuit is being triggered and making your seeeduino think the sketch is for it. You could try disabling it.
The solution lies in proper setup of the serial connection, and requires no extra hardware or hardware modification. You must have to disable HUPCL on linux and DTR on Windows
$ stty -a -F /dev/ttyUSB0 speed 19200 baud; rows 0; columns 0; line = 0;intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^A; eol = <undef>;eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtsctsignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff-iuclc -ixany -imaxbel -iutf8-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt-echoctl -echoke
The easiest way is to stick a larger value capacitor between gnd and the reset pin. I use a 10uF - works a treat. It has the effect of 'swallowing' the small ground pulse transferred by the 0.1uF auto reset capacitor and preventing the board from resetting. It avoids the current drain of holding it high with a resistor. too.
Just my 2 cents:Place a capacitor of 1 or 2 microfarad between reset and ground.You don't have to try different resistors.The reset from the ftdi chip is disabled and the reset button works normally without the "huge" current of 40 mA.Remove the cap and everything is normal.
The capacitor trick with the 10uF was mine, it looks like it doesn't take much to stop it resetting if a 100nF works Smiley Like you a 10uF was what I had to hand, I have some 100nF as well but I didn't think that would be big enough.
The problem is that the ftdi-sio driver's data toggle and the ftdi-sioadapter's data toggle are now at risk of starting out (opening of ttyUSB0) outof sync. I'm sure this is the problem because it's seemingly random, and, whenit occurs, it corrects after a few data transfer attempts. As you'll see below,this is a new problem which the ftdi-sio driver didn't used to have. He'susing a Debian system, so my references to kernel releases are what thatdistribution calls them.His ftdi-sio adapter worked fine up until, and including, kernel 2.6.32-3-686.Then, when he upgraded to kernel 2.6.32-5-686-18, the problem started to occur.It still occurs on Debian Unstable's kernel 2.6.32-5-686-19, and it even stilloccurs on Debian Experimental's kernel 2.6.35-rc6-686, so I suspect this is aproblem which hasn't been addressed yet.....Ah, the infamous dtr/rts issue.....Ok, we need to get this settled once for good. I copied some otherpeople who reported similar trouble. Let me try to summarize again whatI believe is the problem.The USB protocol of this chip has two functions to modify the hardwarehandshake lines. One is FTDI-SIO-SET-FLOW-CTRL-REQUEST and the otheris FTDI-SIO-SET-MODEM-CTRL-REQUEST. To fully enable or disable DTR/RTSlines, appearantly both commands need to be sent to the chip. ... [snip - good discussion, read at source] ...Unfortunately, I see no good way to fix this and still keep all existingusers happy as they're simply dealing with with wrong settings and thedriver can't guess which mode the user actually needs. So people shouldreally fix their clients.
Then Alan's patch 4175f3e31 ("tty-port: If we are opened non blocking westill need to raise the carrier") came in in 2.6.32-rc8 which changedthe behaviour for all serial drivers by directly raising the DTR/RTSlines upon each device open.