Arduino Mega2560 as ISP to program another Arduino Mega2560

How is that Arduino stuff Staff designed this troubleboard? I've read a lot of comments with this same problem.
Nico the best solution is the one I found I guess. Check it out.

(i dont get your first sentence)

But how does it help me?
The 1st command is crap.

The 2nd (you are probably talking about) is only a solution for Arduino Uno. I read in the optiboot post that the mega needs v2 because it is so big. But i still dont understand where the problem is. If its the pc that trys to send v2 (but its set to 1?) if its the precompiled hex file or the .ino sketch. This still doesnt help me. Ive no idea if the fuses are compatible with mega and what this should help me if the mega is not v1 compatible?

The 3rd post uses a usb device. I've got a AVRMKII clone running here but i want to integrate this Arduino as ISP to the 16u2 bootloader, thatswhy i am asking if one can get this working.

The "upload appears to work, but verification fails" appears to be the result of the memory on the 2560 being too large. The communications protocol used by ArduinoISP actually only supports 16 bits worth of address - 64k words or 128k bytes of program.
I think that AVRDUDE figures this out and uses a "raw SPI command" form for the actual programming, but it doesn't do anything similar for the read-back of flash that it does for verification. As a result, it ends up reading back the end of the first 128k of memory, which is NOT where the bootloader got put.

A lot of programmers have the same problem. We need a version of ArduinoISP that supports stk500v2.

Bootloader: the verification mismatch problem is solved, it was an avrdude bug. If you change the aduino avrdude to the last version you do not have this message.
Another important thing is that the error was only on verification, the bootloader normally work also whit the old version.

Programming: You use the Upload by programmers command under File tab ?
On the Uno after programming, and after a manual reset, the Blink work, on the Mega it is necessary change the RST Fuse. I do not know why this difference, I working on it for an exlanation.
I have a Guide, in italian, in my sign

So it is possible bootload and program via ISP the Mega :slight_smile:

Thy for the answers! This gives me a better impression.

I am using the Arduino IDE for everything. I select the mega, Arduino as ISP and burn bootloader or upload via Programmer.

I am still a bit confused. If the v1 cannot burn the bootloader to the right place, why does it still work?
Or maybe the sketch is actually v2 compatible?

Here is the AVR Dude error (with IDE up to 1.5.6):

avrdude: verification error, first mismatch at byte 0x1e000
         0xff != 0x0d
avrdude: verification error; content mismatch

With IDE 1.5.7 i can burn the Bootloader sucessfull and very fast!!! Thx for this hint!
The normal uploading is still successfull but the sketch doesnt start!

So how can we fix normal sketch uploading? Still confused about v1 and v2 and why burning still works.

The 100nF capacitor isnt needed i think. I know the 16u2 bootloader source and it seems the uploading doesnt trigger the DTR line. Maybe thats new and the documentation is old?

all version, v1 and v2 also, burn the bootloader to the right memory space, the mismatch verification is not a problem of the ArduinoISP sketch but an AvrDude bug. Infact the bootloader work also when you receive the verification error.

You do not need the capacitor on reset, it is tip for other kind of error, if your burning process finish with successfull you do not need of capacitor.
I repeat my tips for you second question, is it possible using Upload via Programmer on a Mega, but you need change your fuses for starting the program. Simply the sketch will correctly burn, but it do not run.

and what do you recommend to fix this fuse problem? Should someone fix the bug in the IDE or is it possible to add something to the sketch?

what fuses needs to be changed? ive never dealt with fuses before. I know what it is, but i never wanted to change something to not break things :wink:

Nobody know why on UNO it is not necessary change the fuses and on the MEGA it is necessary. (or at least i do not know anyone that have an answer).

for now the only way is change the fuses, the Bootrst is your target, but please study the datasheet and understand what you do, because it is possible brick the chip if you make error whit the fuse.

It would be nice of some can figure it out how this works. The you could program any Arduino with the 16u2.

See this and this:
https://groups.google.com/a/arduino.cc/forum/#!msg/developers/V_T-Uvj8hSs/h9xlGyM9cJoJ

interesting the hoodloader, i sent you a pm.
i can write a new virtualboard for resolve the "Not Run Mega problem"

we fixed the problem. fuse BootRST must be set to 1. to execute the program. Somehow its not needed for an uno.
stay tuned on further hoodloader releases :wink:

NicoHood:
we fixed the problem. fuse BootRST must be set to 1. to execute the program. Somehow its not needed for an uno.
stay tuned on further hoodloader releases :wink:

Great.

BootRST must be set to 1.

That seems odd. Exactly what are your (working) fuses set to, now?

Add this to your boards.txt and burn the bootloader once. The bootloader is not used, its just to change the fuse. Then you can upload via isp and the sketch will load

## Arduino Mega w/ ATmega2560 Testato Mega ISP Version
## -------------------------
mega.menu.cpu.atmega2560T=ATmega2560 (Testato ISP Version)

mega.menu.cpu.atmega2560T.upload.protocol=wiring
mega.menu.cpu.atmega2560T.upload.maximum_size=258048
mega.menu.cpu.atmega2560T.upload.speed=115200

mega.menu.cpu.atmega2560T.bootloader.high_fuses=0xD9
mega.menu.cpu.atmega2560T.bootloader.extended_fuses=0xFD
mega.menu.cpu.atmega2560T.bootloader.file=stk500v2/stk500boot_v2_mega2560.hex

mega.menu.cpu.atmega2560T.build.mcu=atmega2560
mega.menu.cpu.atmega2560T.build.board=AVR_MEGA2560

It was uploading sketches via ISP that wasn't working?
It's possible that that doesn't work on 2560, but does work on 328, because the program counter wrap-around happens differently on a chip with more than 64kwords of flash. On a 328, if you start in the "bootloader section" at 0x3F00 (where there isn't any actual code), it will execute relatively useless but unharmful instructions till it gets to 0x3FFF, and then wrap around to location 0x0, where your sketch actually begins. On a 2560, if the bootloader section starts at 0x1F000 and muddles along to 0x1FFFF, I'm not sure whether it will wrap to 0x0 (your sketch), or to 0x10000 (middle of nowhere, where it will eventually wrap again.)

I can't find this clarified in the documentation. Not that you need a "long" jump/call or to use EIND to change the high bit during normal program execution.

westfw:
I'm not sure whether it will wrap to 0x0 (your sketch), or to 0x10000 (middle of nowhere, where it will eventually wrap again.)

Hi westfw,
on the 2560 at the end of the flash the PC do not jump to 0x0, I discover this behavior some months ago and found that we need modifie the fuses.
NOrmally in the arduino board the high_fuses=0xD8, we need it change to D9 (the submenu' code posted here is mine ;))

but Arduino team do not know this ? when it create the "Upload via Programmer" tab/option i test it (i write a guide on it in my sign) and discover that this command do not work on Mega.
I do not know if we must manage this behaviour like a Bug, (bug on Mega, or bug on Uno, depend what the team means whit Upload via Programmer)
I think the team wants to exploit the behavior of the ProgramCounter on the UNO, so the team do not want that the user must change the Fuses, but did not realize that this trick work only on the 328 :slight_smile:
What do you think ?

Hi there,
yes! A Bug's it!
I can use an Arduino Mega 2560 a 328P flashen- without problems.
I can not flash with an Arduino Mega 2560 a Mega 2560.
This only works with foreign hardware or complicated changing the software.
But no one understands. What is this?
Greeting and fun
Andreas

P.S. I try to just:
Arduino Maga 2560 -> Mega 2560
http://www.ebay.de/itm/Mikrocontroller-Atmel-ATMega2560-ATMega-SMD-Adapter-/271224130246?pt=Bauteile&hash=item3f2637cac6

It is equally a bug that the "bootrst" fuse is left programmed (0) on a m328 when you do "upload using programmer." It only works if the sketch is short enough not to overlap where the bootloader WOULD be...

This was apparently reported a long time ago, but never understood well enough to fix. I've added a comment to the bug.

the lenght is not a problem, because in the board.txt you have the maximum sketch value, so if you do not change the original boards.txt you do not have problem.