Program doesn't run after Upload Using Programmer with USBasp (Mega2560)

[cmaglie]

EDIT: The original issue from google code has been solved. This issue is still open to keep track of uploading problems using USBAsp programmer, see comments below for details.

This is Issue 388 moved from a Google Code project.
Added by 2010-10-28T20:36:23.000Z by rdlsoftware@gmail.com.
Please review that bug for more context and additional comments, but update this bug.

Original description

What steps will reproduce the problem?

1. Wire up a connection between the Arduino Duemilanove and Mega 2560
2. Upload ArduinoISP (from IDE 021) to Arduino Duemilanove
3. Upload a new bootloader to a Mega 2560 via the 'programmer'

What is the expected output? What do you see instead?
After uploading, the mega should accept new sketches.

What version of the Arduino software are you using? On what operating
system? Which Arduino board are you using?

Arduino 021. Arduino Duemilanove as ArduinoISP (version from IDE 021), Arduino Mega 2560 as target hardware. Windows 7 64 bit.

Please provide any additional information below.
See http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1287952386 for original post of issue.

[WestfW]

"Upload using programmer" does not unset the "BOOTRST" fuse, so the chip will be started at the bootloader start address after such an upload, even though the bootloader has been erased. Apparently this works (most of the timer) on a m328 because the PC wraps around at the end of flash, but it breaks on a 2560 because the PC wraparound works differently (wraps to 0x10000 ?) It should break on a m328 as well, if the uploaded sketch has code that ends up positioned beyond the normal bootloader start address.

"Upload using programmer" should unset (set to 1) the BOOTRST fuse. (Unfortunately, I think this means added a new fuse value to boards.txt)

[matthijskooijman]

@NicoHood, this seems to be the bug we talked about in #arduino yesterday. WestfW seems to have properly diagnosed the problem and explains why this problem doesn't occur on a 328.

Interestingly enough, this problem also doesn't occur on my Pinoccio boards, which use a 256rfr2, which is very similar to the 2560 in many regards (but perhaps not this one?)

[WestfW]

(Hmm. The simulator wraps from 0x1F000 to 0x00000, not supporting my theory. But I'm not sure I trust the simulator with anything that might be so chip-specific... Does anyone have a 2560 system with some form of on-chip-debugging usable?)

[matthijskooijman]

I have a JTAG adapter here that I could probably try on my mega. No time today, perhaps later this week (feel free to remind me if I don't respond before the end of the week).

[Testato]

i also have a jtag and the Mega, i can try on weekend.

But you have writed on the Wrong Topic, this one is for a problem on the normal Bootloader, the people that open this do not have the Upload via Programmer Option (he is on 0,21 IDE)

Re-read what it typed:
............................
3. Upload a new bootloader to a Mega 2560 via the 'programmer'

What is the expected output? What do you see instead?
After uploading, the mega should accept new sketches.
.............................

[Testato]

i tried whit Atmel-ICE programming, via ISP, and the program start normally. It is not important if the BootRst is 0 or 1. So only on ArduinoIde is there this problem. It is a bug inside Arduino Upload Using Programmer command ?

[NicoHood]

Any progress?

[matthijskooijman]

I just noticed arduino/Arduino#2277, which reports a wrong upload.maximum_size setting for the mega (which has just been fixed in git). Perhaps that's related to this bug as well? I haven't checked if the maximum_size setting actually influences the upload through bootloader process in any way (no time right now), but I just wanted to share the thought.

[Testato]

i think no:

1. because if you upload the simple Blink, only 1K of code, the problem is present (the wrong maximum size is not reached in this case)
2. the wrong maximum size may create, whit a very big sketch, problem to the bootloader, because it overwrite the bootloader section in the flash, but do not have relation with the Upload Using Programmer problem

@cmaglie Please divide this topic in two issue, because, like I writed, the original topic was different from the "Upload Using Programmer" problem.
The original issue "Upload a new bootloader to a Mega 2560 on IDE 021" it is solved many time ago.

[matthijskooijman]

Given the original issue was solved already, and duplicating an issue is not possible on github AFAICS, let's just use this issue to track the "new" issue about uploading sketches to the mega?

I agree on both or you points. However, I was thinking that the maximum_size settings was perhaps used in some other way, such as to add a JMP 0 instruction at the start of the bootloader section when you use upload using programmer. I don't think this happens, but if it was it would explain why the mega isn't working while others are.

[per1234]

From reading the comment from @Testato on this topic: http://forum.arduino.cc/index.php?topic=126160.msg1839705#msg1839705 it seems the solution is to change
mega.menu.cpu.atmega2560.bootloader.high_fuses=0xD8
to
mega.menu.cpu.atmega2560.bootloader.high_fuses=0xD9
in boards.txt which disables the Boot Reset vector(BOOTRST=1). I tried it and my results are that using USBasp to Upload Using Programmer Blink.ino to Mega 2560 with the high fuse set to 0xD8 it uploads successfully but the LED doesn't blink. Doing the same thing with high fuse set to 0xD9 the LED does blink as expected. Using Atmel AVRISP mkII the LED blinks with either fuse setting.

[per1234]

After I have done Burn Bootloader with the high fuse set to 0xD9 using USBasp the bootloader no longer works(I get avrdude: stk500v2_ReceiveMessage(): timeout when I try to upload over serial). If I use the mkII to Burn Bootloader with the high fuse set to 0xD9 then the bootloader works and Upload Using Programmer with USBasp also works.

[NicoHood]

I was helping on that too at that time.
The weird thing is, that chips like the 328 or 32u4 dont care about the bootloader setting, while the mega seems to do. But if you say another uploader avoids this issue, maybe it detects that and places a jump to 0x0000 if this address wasnt used in the hex file?

You could try to read back the memory of the mega and see what happens. Maybe the programmer changes the fuses by default. @nickgammon has some very useful tools for doing this:
https://github.com/nickgammon/arduino_sketches