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 http://www.nongnu.org/avrdude/

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);

And more important at the end it reads the wrong signatureavrdude: Device signature = 0x98e781avrdude: 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(); Serial.print((char)STK_INSYNC); Serial.print((char)STK_OK); } else { error++; Serial.print((char)STK_NOSYNC); } break;

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

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

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.

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

Quote

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.

Please post technical questions on the forum, not by personal message. Thanks!

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.

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.

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

Quote

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!