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

[Testato]

@per1234 the Burn Bootloader set the fuse to the standard arduino virtualboard fuse setting, so the serial sketch upload must work. Maybe you have a random upload problem, try 2-3 times

For the Upload using programmer, like you are experimented, the mega need 0xD9, i discovered it many months ago :-)

So Upload using programmer not change the fuse, but Burn Bootloader change the fuse, if you will use only Upload using programmer, you need change the fuse only one time, but if you pass often from Upload by SERIAL, and Upload Using rpogramming, you must manually change the Fuse every time

Are you used AVRISP mkII from inside the Arduino IDE ? This is very interesting, because it means that the rpoblem is only on USBAsp programmer

[per1234]

@NicoHood I assume you mean Atmega_Self_Read_Signature.ino? I ran it with all combinations of Burn Bootloader with USBasp/mkII, serial upload(only can do when bootloader burned w/ mkII) and Upload Using Programmer with USBasp/mkII. Atmega_Self_Read_Signature.ino shows the same fuses each time which are the expected: Low = FF High = D9 Ext = FD The Lock value is always FF with Upload Using Programmer and CF with serial upload. The bootloader content is always all FF with Upload Using Programmer and 03 with serial.

@Testato I have tried it many times always with the same result as I stated in my previous comment. It's completely consistent, not a random problem. And yes I completely understand that Burn Bootloader sets the fuses and when you Upload Using Programmer it erases the bootloader and you have to Burn Bootloader again to replace the bootloader. With the high fuse set to D9 when I Burn Bootloader using USBasp the blink on pin 13 that is coded into the bootloader doesn't happen. When I Burn Bootloader with the mkII it does. With high fuse D8 the bootloader blink happens with either programmer and serial upload also works with either.

@Testato would you mind changing the title of the issue to something like "Program doesn't run after Upload Using Programmer with USBasp" and put a note in the first comment something like: "The original issue was solved but it has been changed to a new issue as explained below." I think that would give this issue a better chance of being resolved as it's a little bit confusing how the subject changed after it was submitted.

[per1234]

Sorry, I meant to mention @cmaglie (or anyone else who has edit privileges) in the last part of that, not Testato.

[PeterVH]

I think this issue can be closed, it is due to a bug in the usbasp firmware.

See https://petervanhoyweghen.wordpress.com/2015/12/02/the-usbasp-and-atmega2560-mystery/ for an in depth (but lengthy) description.

The bottom line is this: even if the hfuse is set to 0xD8 on an atmega2560, it is possible to "upload sketch using" programmer, and the sketch will run. This can be shown by using ArduinoISP + avrdude 6.1, or any othe rprogrammer with correct support for big flash. The problem is that usbasp flashes the sketch in the wrong place: at 0x20000 instead of at 0x00000. The sketch can not run from that position.

[per1234]

I confirm that with the fixed firmware linked in PeterVH's blog post this issue no longer occurs with hfuse 0xD8.

[Testato]

Remain only one question, if i remember @NicoHood, that i helped some time ago, upload the sketch by An Arduino and arduinoAsISP sketch. If this is True, the bug is present on arduinoISP also ?

[NicoHood]

@cmaglie changed the title, but I think the issue could still exist with the mega. Someone should try, you are right @Testato

[per1234]

I just tested Arduino as ISP using the ArduinoISP.ino included with the hourly build with ATmega2560 target and I have the exact same results as I did using USBasp with the original eBay "Baite" firmware:

With mega.menu.cpu.atmega2560.bootloader.high_fuses=0xD8

• Burn Bootloader and upload via serial works.
• Upload Using Programmer completes successfully but the sketch never runs.

With mega.menu.cpu.atmega2560.bootloader.high_fuses=0xD9

• Burn Bootloader completes successfully but then there is no bootloader blink and upload via serial doesn't work.
• Sketch runs after Upload Using Programmer

I think the poor explanation of the original issue might be the cause of some confusion. It sounds like they are saying that after burning the bootloader using Arduino as ISP serial upload doesn't work but if you read the forum post it appears they were actually having the problem with the sketch not running after Upload Using Programmer.

[NicoHood]

You got the point. So the bug still exists.

The funny thing is, that on a 32u4 and 328 this fuse is unimportant it seems. The sketch runs anyways. This might be a problem if the size is near 32kb I guess. It is interesting to know why it does not happen there, i dont know why.

To fix this we have to also change the fuse with uploading. This could destroy some previous fuses, so we have to read the fuses, add/remove the bit and the write them again + the sketch. Or is there any other way?

How does the usbasp solve this issue?

[per1234]

How does the usbasp solve this issue?

I believe this is the change that @PeterVH made to the USBasp firmware to solve the issue: https://github.com/PeterVH/usbasp/commit/14af55e03c5e4f5238d8eec6f83f8360405a7193 I think the best solution would be to try to make a similar change to the ArduinoISP sketch.

Edit: The fix was originally posted to an Open RC Forum thread and PeterVH found it and posted to GitHub

[NicoHood]

Hm I dont understand what this patch does, but it seems that arduino as isp can fix it?

[Testato]

So:

1) USBAsp firmware have a bug, the new 1.5 version solved it, so the actual title on this issue permit to close it. 2) ArduinoISP.ino have the same problem, is maybe arduinoisp a fork of usbasp code ? It is needed open a new issue for trace this specific problem on ArduinoISP.ino sketch 3) @PeterVH the mystery continue :-)

[NicoHood]

1) he changed the title to the wrong name I think. Or we had two issues with the same problem for two devices. Dont make it too complicated and stay here.

[PeterVH]

Hi all! @Testato: No, that mystery is solved too. I explained it here: https://petervanhoyweghen.wordpress.com/2015/07/21/arduinoisp-reliability-and-portability-improvements: scroll to the chapter "avrdude 6.1". The combo "ArduinoISP sketch + avrdude 6.1" correctly supports flash > 128KB.

I helped voting to upgrade avrdude in the IDE to 6.1 (see arduino/Arduino#17) but that did not yet happen. Probably because the avrdude 6.1 was considered an intermediate release. I did all my tests with avrdude 6.1 also on windows, never seen a problem. Since November 2015, avrdude 6.2 is released. Maybe that makes it into the IDE once it gains some confidence.

[PeterVH]

Hmm, that explanation is not that great. The "clever fixes in avrdude 6.1" consist of sending "universal" commands to the stk500v1 programmer (Arduino as ISP) to make it send the "Load Extended Address Byte" command to the target.

[NicoHood]

So shouldnt we open another issue for avrdude 6.1? I'd also like to point out that this can be fixed with a new avrdude version as well (not yet in the upstream) https://github.com/arduino/Arduino/issues/3645

[Testato]

The simplest way is update the avrdude inside arduino environment to 6.1 or 6.2 This finally close issues like this.

Thanks to PeterVH for explanation, are you writed to the original author of usbasp so he can release sn official 1.5 version ?

[matthijskooijman]

For updating avrdude, see https://github.com/arduino/toolchain-avr/issues/17

[per1234]

The issue of the program not running after Upload Using Programmer on ATmega2560 using Arduino as ISP has been solved by the update to avrdude 6.3.0-arduino2 in Arduino AVR Boards 1.6.12.

The issue still occurs using USBasp with firmware versions other than PeterVH's 1.05 or PeterVH/bperrybap's 1.06-alpha.

[dzalf]

This might be irrelevant by now, however, I am facing this issue at the moment.

I have tried with two different USBasp boards and the code doesn't run.

I am using AVRDUDESS loaded with the latest avrdude.exe 8.0