Why did the mega 2560 not work as an ISP?


I have a mega 2560 and wish to programme a ATmega644PA chip. I have read lots of posts and lots of tutorials and tried them out with no success then I found http://forum.arduino.cc/index.php?topic=65099.msg706346#msg706346 that mentioned that mega 2560 did not work for others, so rather than purchase a Arduino UNO thought it a good point to open this new thread about why the mega 2560 does not work as an ISP out of the box and provide the fix to make it work.

TESTING ArduinoISP sketch:
I have http://code.google.com/p/mega-isp/ loaded into my mega 2560 and open a serial connection to the mega 2560 and send "1 " to the mega-isp sketch and get the response “?AVR ISP?” so I know that the sketch is loaded correctly and that it is responding correctly (the ? is my way of indicating the 0x14 or other none print character). My serial speed is 9600 baud because the mega-isp sketch has Serial.begin(9600).

I have already got the latest avrdude on my Ubuntu computer but just to be safe (and also because it did not work) I built avrdude from source AVRDUDE - AVR Downloader/UploaDEr

Now I run the command
avrdude -b 9600 -c arduino -p m644p -t -vvvv -P /dev/ttyACM0

And get
Using Port : /dev/ttyACM0
Using Programmer : arduino
Overriding Baud Rate : 9600
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 done. Thank you.

Start the serial monitor again and type "1 " and it is still working. So it seems to me that the mega-isp sketch does not correctly communicate with avrdude Version 5.11svn-20111019 out of the box.

BUG FIX 1 in avrdude V5.11 - Ok so I am editing this question as I find fixes / as people tell me what to do - thus you only need to read this message and the end of the thread that I have not done anything with yet!
Nick suggests - disabled reset on the Mega - and - disable the bootloader - well I dont like the idea of that I would rather fix avrdude so that you dont have to make any hardware modifications. So as I have built avrdude Version 5.11svn-20111019 all I need to do is add a bit of additional delay into the static int arduino_open(PROGRAMMER * pgm, char * port) in arduino.c I added 1 second… it would be better to try try till it comes up but the delay is a good first patch:
/* Set DTR and RTS back to high */
serial_set_dtr_rts(&pgm->fd, 1);

/* Sleep to allow the Arduino board to reset /


  • drain any extraneous input
    Now the avrdude gets the basic communication with the mega-isp working but I get a couple of protocol error messages:

    avrdude: Send: A [41] . [80] [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
    avrdude: Recv: . [14]
    avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x14
    avrdude: Send: A [41] . [81] [20]
    avrdude: Recv: . [10]
    avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x10

    avrdude: Send: B [42] . [82] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [ff] . [ff] . [ff] . [ff] . [01] . [00] . [08] . [00] . [00] . [01] . [00] . [00] [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [01]
    avrdude: stk500_initialize(): (b) protocol error, expect=0x10, resp=0x01

And more important at the end it reads the wrong signature
avrdude: Device signature = 0x98e781
avrdude: Expected signature for ATMEGA644P is 1E 96 0A

BUG FIX 2 in mega-isp - Looking at the trace (and also I implemented a second USART connection to the mega 2560 to confirm with additional debug output to the second port) its obvious that the avrdude code sends a burst of signon messages without giving the mega-isp code time to process the received messages. So avrdude keeps on getting the responses to each of these messages that it sent earlier -
avrdude: Recv: . [14]
avrdude: Recv: . [10]
till the mega-isp code has finally processed all the signon messages. Oops… thats the root cause of the problem because avrdude has moved on so it sees the response to signon as a response to the next message that it has sent… thus the string of protocol error from avrdude. So the fix for this is to catch the first signon message and before responding clean out the receive buffer then send the STK_INSYNC / STK_OK message that the avrdude is waiting for. Then the avrdude sends its next message and mega-isp will respond to that message correctly because its the first message in the receive queue. The fixed sketch int avrisp() function now has:
uint8_t ch = getch();
switch (ch) {
case ‘0’: // signon
error = 0;
if (getch() == CRC_EOP) {
// empty the input stream
while (0<Serial.available()) getch();
} else {

I have wired the mega 2560 up to the ATmega644PA processor as described in http://arduino.cc/en/Tutorial/ArduinoISP

I have made no other alterations (because the tutorial http://arduino.cc/en/Tutorial/ArduinoISP does not ask for further modifications) and it seems to me that no other modifications should be needed.

With these two fixes - one to avrdude - and the other to mega-isp - I can now enter the interactive terminal and get all the great features that avrdude provides. I have now tested out programming etc and have not found a problem and the mega 2560 does work as an ISP.

In the thread below Coding Badly et al suggest a better fix for the mega-isp code. Rather than empty the input stream blindly

      // empty the input stream
      while (0<Serial.available()) getch();

Its better to set a flag and empty the input stream checking for each new command. If a new different command is received then clear the flag and proceed as normal. This fix will avoid the chance that avrdude could send two signon messages that mega-isp handles then receives the third signon message and fails. I have not tried this slightly better fix yet so just refer you to the quotes from Coding Badly and @westfw

This… http://code.google.com/p/arduino/issues/detail?id=730 …plus this… http://forum.arduino.cc/index.php?topic=88649.msg673833#msg673833 …except using @westfw’s strategy of clearing initSent on all successful commands… http://forum.arduino.cc/index.php?topic=88649.msg673869#msg673869

When I try this fix I will clear initSent on every command other than signon because till initSend is cleared mega-isp would be un-responsive to future signon messages.
In addition johnwasser points out below that we might need STK500V2 protocol rather than STK500V1 protocol.
Great comments from these guys, I am still working on avrdude team to fix the first and most basic problem where avrdude starts before mega-isp has come out of reset.

How have you wired it?

Also, have you disabled reset on the Mega? See the comment on the linked site:

June 2011 Haven't tried it, but perhaps the fastest way to get ArduinoISP working on the UNO is to disable the bootloader. Then when the board resets it goes right into ArduinoISP. Note: you will want some way to re-enable the bootloader.

Check this.

I have a mega 2560 and wish to programme a ATmega644PA chip.

Program, or install a bootloader?


I updated my first post with the two bug fixes (one for avrdude and the other for mega-isp). The new versions should work for all isp actions (installing bootloader or installing sketch). Hope these bug fixes help someone. I have contacted the avrdude and mega-isp teams and hope to get the bug fixes included at some point in the main code.


Thank you for taking the time to write about your experience.

I have contacted the ... mega-isp team and hope to get the bug fixes included at some point in the main code.

Don't hold your breath. You are at least the second person to report the problem with ArduinoISP...
Status: WontFix

I know I've helped a few folks get past it.

For the record, your solution has a race condition that makes it unreliable.

Thanks for this solution, especially the patch for avrdude. Is avrdude still being maintained? The last release was 3 years ago...

Anyway, with your solution, reading a chip via ISP worked, but writing did not (with a generic 'not responding' error). BUT the ArduinoISP sketch that comes with the current IDE (1.0.5) did work, for both reading and writing. I successfully programmed another Mega2560 and its Atmega16u2.

And BTW, if you change the heartbeat pin in the script to pin 13, you should be able to see the programmer working without any additional LEDs.

Hi Coding Badly et al,

Please provide a code fix for the observation that you make:

For the record, your solution has a race condition that makes it unreliable.

In my opinion the fix detailed above does not introduce any additional race condition that was not already present. Instead the fix to mega-isp actually improves the operation by limiting the number of signon responses that are made to one, if you like the last one mega-isp receives. After all for a signon attempt its only the last one that should have any significance, the earlier attempts are redundant. As I commented above

it would be better (for avrdude) to try, try till it comes up

Indeed a three way handshake where avrdude confirms that it saw the response would ensure that the two way communication channel has started as with the two way handshake its not obvious to the mega-isp code that its response has been received by the avrdude code, however more complex fixes would likely require changes to stk500 startup code that the avrdude arduino startup is based on and since stk500 code is well established perhaps the additional code churn would not be worth the effort?

Anyway I can confirm that I have been using my fixed versions of avrdude and mega-isp for some time now with no obvious problems and I dont have to make any modifications to the mega2560 board to get it all working. Now all I need is for openocd to support atmega644!

Please provide a code fix for the observation that you make:

For the record, your solution has a race condition that makes it unreliable.

This... Google Code Archive - Long-term storage for Google Code Project Hosting. ...plus this... ISP! - #25 by Coding_Badly - Microcontrollers - Arduino Forum ...except using @westfw's strategy of clearing initSent on all successful commands... ISP! - #26 by westfw - Microcontrollers - Arduino Forum

In my opinion the fix detailed above does not introduce any additional race condition that was not already present.

So what? A race condition is a bug. In this case, it's a bug with a published fix.

One possible problem is the ArduinoISP/MegaISP sketch uses STK500V1 protocol and I think the 644, like the 1280 and 2560, need STK500V2.