[Q] About programming via the ISP/ICP

[Dave]

I am developing some software for the MEGA2560 chip and for a variety of
reasons (size, startup speed, no USB port etc) I may need to run the
code without a bootloader.

I am aware that the BOOTRST bit must be set to enable the programmer
uploaded code to be executed.

For convenience I am normally developing using the USB port and the
bootloader but when I need to test without the bootloader I am
having to set "BOOTRST" via AVRDUDES(S).

When I want to go back to using a bootloader I use the "Burn Bootloader"
option and it is apparent that it clears "BOOTRST" and I don't need to
do it via AVRDUDES(S).

My question therefore is - why doesn't "Burn via Programmer"
automatically set "BOOTRST" ??

Or have I missed something ??

Regards,
Dave

[William Westfield]

On Jul 4, 2021, at 1:39 PM, Dave <soft...@hotmail.com> wrote:

why doesn't "Burn via Programmer" automatically set "BOOTRST” ?

Good question.  Probably because the “burn bootloader” command is explicitly set up to be a multi-step command: erase chip and set fuses, upload bootloader code, set protection bits.  Three separate avrdude commands.

In contrast, the “upload using programmer” only issues a single avrdude command.

However, avrdude, at least in recent versions, will happily do multiple operations in a single command (even setting fuses and then resetting them later.  So this probably COULD be fixed.

(It’s operating on other processors, where uploading using the programmer doesn’t necessarily mean removing the bootloader, would be more ambiguous…)

BillW/WestfW

[Matthijs Kooijman]

Hi Dave,

> My question therefore is - why doesn't "Burn via Programmer" automatically
> set "BOOTRST" ??

I think the original workflow was that "Burn bootloader" is something to
do once (or at least rarely), and "Upload using programmer" is something
to do many times. Since setting up most fuses only needs to happen once,
it probably made sense to do that in "Burn Bootloader", but not during
"Upload using programmer".

However, as you say, the BOOTRST fuse is intended to be different
between both cases, as it determines whether the main application (at
the start of flash, as uploaded using "Upload using programmer") or the
bootloader (at the end of flash, uploading using "Burn bootloader") is
to be started.

However, in practice, for most cases it actually works to leave the
BOOTRST fuse unchanged (in the "start bootloader" setting). Then startup
will run from the bootloader area, which is filled up with 0xff, which
are effectively NOPs (see
https://www.avrfreaks.net/comment/1847371#comment-1847371), and once
execution reaches the end of flash, it wraps around and starts the
application as intended. I recall this did not work on all atmega chips,
but I couldn't find the corresponding bug report now. Because of this
behavior, I suspect that nobody originally realized that there was any
need to change the BOOTRST fuse, since it worked as intended (or maybe
people knowingly chose to rely on this behavior, dunno).

So then I wonder: Do you *really* need to change the BOOTRST fuse?
Does the wraparound trick not work for you? Bill Westfield theorized
that Atmega2560 doesn't support the wraparound trick (here:
https://github.com/arduino/ArduinoCore-avr/issues/246#issuecomment-51999965),
but I'm not sure that was ever confirmed or debunked.

What this trick does mean is that when using "Upload using programmer",
you cannot actually use all of the flash - the bootloader area must be
kept at 0xff. IIRC in the current boards.txt spec there is also no way
to specify a different maximum sketch size for the two upload methods,
so keeping the bootloader area clear will happen automatically anyway.

There is this issue, which is about allowing use of the bootloader flash
area, which also discusses the need to change BOOTRST when using "Upload
using programmer". I suspect that this might be the most appropriate
github issue to track this issue now:

https://github.com/arduino/arduino-cli/issues/1035

I also found another issue mentioning BOOTRST, but it *seems* that that
issue is really a couple of different things intermixed, some of which
are fixed with a USBAsp firmware update it seems:

https://github.com/arduino/ArduinoCore-avr/issues/246


I cannot comment with much certainty, but I hope sharing my thoughts and
recollections would help here.

Gr.

Matthijs