Hi all,
I thought I had a problem with my Duemillanove w ATMega328; and so I thought I'd perform a "factory reset" - that is, burn the bootloader on flash. For this, I'm trying to use an Arduino Diecimilla as a programmer, and the Duemillanove as a target.
Needless to say, I have a problem flashing the bootloader - and I have already seen:
- Arduino - ArduinoISP (tutorial)
- Arduino playground - MegaISP
- Arduino playground - Disabling AutoReset On Serial Connection
- Arduino Forum - using arduinoISP to program standalone atmega328
I pretty much agree that the problem is the auto-reset done performed by serial (more details below) - however; that is not the mystery for me.
The mystery is that, just a couple of months ago, I performed the exactly same procedure (Diecimilla programmer, Duemillanove target, Arduino 0018 IDE, Ubuntu 10.04) - and it worked flawlessly, with no problems whatsoever! :o
So, if anyone has an idea how come everything worked few months ago - maybe it will be possible to see what is different now? And, if it is possible to perform the bootloader-burn easily again (meaning, without performing any hardware hacks)? :-?
While I admit the problem is (most likely) the serial reset, below are a few more details. Otherwise, the only significant change that I can remember, is that there was a kernel update update recently - and currently I have Linux 2.6.32-25-generic
; could that, also, be the problem?
Originally, I was so surprised the first 'bootloader flashing' went so smoothly (I had written very bad code, that kept resetting the Duemillanove each 500ms, thereby making it impossible to reprogram regularly from the IDE), I took a picture:
You'll notice I'm using wire with alligator clips, going directly to the ICSP header (at that time, I hadn't seen the tutorials above - but I believe the ICSP header pins are anyway connected to P10, P11, P12, P13 as in the tutorials); also, I'm using extern power supply on the target (Duemillanove). I cannot remember whether I did anything with the reset button (as described in How to upload code without auto reset) - I just remember that:
- First I chose Diecimilla/ATMega168 as Board (the programmer), and choose ArduinoISP sketch, and upload that to the Diecimilla
- Second I chose Duemillanove/ATMega328 as Board (the target), and Tools / Burn Bootloader / w/ Arduino as ISP
and the target Duemillanove had the bootloader reprogrammed succesfully..
Right now, I have pretty much the same setup; the Duemillanove board seems not to be exactly the same one, though. Also, unlike the original case, where the target Duemillanove was essentially bricked - here the bootloader is, basically, still fine - as I can still program the Duemillanove directly through USB. I have tried with both external power, and power supplied from the programmer Diecimilla, no change - meaning that the second step in the process above will fail with:
Using Port : /dev/ttyUSB0
Using Programmer : stk500v1
Overriding Baud Rate : 19200
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: Send: Q [51] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
(Note that I edited ~/.arduino/preferences.txt
, and added build.verbose=true
and upload.verbose=true
to get this output from the IDE, and get the right command lines used)
I first used the alligator-clips-wire as in the above image; then after a few failures, I thought I'd measure pins P10-P13 on a scope. I could then see that P11 and P12 (MISO/MOSI) are "heavily" floating whenever I attach the alligator clips (it's as if those wires with clips, acted as antennas for 50Hz mains). So, I ditched these wires, and simply cut smaller pieces of regular wire, and connected through the sockets as in the tutorial. Now there is significantly less of this floating noise, but that didn't result with success of the burning process.
Then I looked around, and found about this serial reset issue.. Then I read a bit through the ArduinoISP sketch source; and I realised there is a "heartbeat" (a PWM signal on P9) for the programmer - so I observed that on scope too. The behavior is:
- After finish of programming via USB - or after press on RESET button - P9 stays low for about a second, and then 'heartbeat' starts.
- If heartbeat is started - any click on any of the Tools menu options (including Tools menu itself) will freeze the 'heartbeat' (note, this doesn't look like reset, since with a real reset, the 'heartbeat' should start again after a second - which it does not do in this case).
- Also, most serial commands from terminal will freeze the 'heartbeat' (except '
stty -a -F /dev/ttyUSB0
' which will reset) - If a 'heartbeat' has frozen, you need to press the RESET button again - in order to get it running anew
With this in mind - I tried experimenting a bit with trying to 'burn bootloader' and closely press the RESET button on the programmer Diecimilla; and there are, basically, these outcomes:
- The RESET button was not released on time, and the 'heartbeat' is frozen; then the failure is:
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
- The RESET button has been released on time; however, the 'heartbeat' has not kicked yet in - then the failure is:
avrdude: Device signature = 0x1e9406
avrdude: Expected signature for ATMEGA328P is 1E 95 0F
Double check chip, or use -F to override this check.
Finally, if I decide to use this '-F
' option -- by running manually the command line that Arduino IDE generates:
/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
-- and if I also release the RESET button (on the programmer Diecimilla) at the right time, then avrdude
will try to program, and finally fail during verification:
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x3f != 0x00
avrdude: verification error; content mismatch
As I understand the ISP protocol, the first action that should be made, is that RESET (P10 on programmer) should be pulled low; I can only observe that on scope, when RESET (button) is released on time.
Now, I'd say that this behavior is nicely summed up in this comment:
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.
In respect to disabling the auto-reset, I also found 'Arduino Forum - disable auto-reset by serial connection':
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
Unfortunately, checking my serial port settings gives '-hupcl
', which I guess means hupcl is disabled (that setting is also enforced by running the Arduino IDE programming via USB, too):
$ 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 -crtscts
ignbrk -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
That pretty much exhausts my approaches for now; apparently the serial reset is the problem - but I cannot circumvent it by pressing the RESET button on time... But still - how could I have brought back a bricked Diecimilla earlier, and not have any such problems then; with more or less the same software/hardware combo? Did the Linux kernel maybe make a significant change in how serial calls are executed??
Well, as I'd like to know what's going on - I'd love to hear some comments or suggestions for further troubleshooting (as long as they don't involve desoldering type hardware hacks ) ,
Thanks,
Cheers!