upload using programmer & optiboot

[ObviousInRetrospect]

Why is upload using programmer disabled when optiboot is configured?

I have an application that uses optiboot for OTA firmware updates. But its a PITA in the development cycle to export the firmware and run it through the external loader. I don't have or want a serial-driven auto reset circuit and those pins are connected to another mcu anyway. It would be far more convenient if upload using programmer concatenated the bootloader with the hex and wrote both (or just erased/wrote the app section).

[SpenceKonde]

Well, if you did upload using programmer, you could no longer use the bootloader because a UPDI programmer, which is the only other kind of programmer I know of and which the core ships with support for, is likely to execute a chip erase, wiping out the bootloader, then upload the sketch starting from the start of the application section. And that's if the fuses were set correctly from previous bootloading; If they weren't, it'll work even worse and even more confusingly. If the BOOTEND fuse set on the chip and what the compiler thinks it's set for don't match, the hardware will think the vector table starts at a different location than the compiler does.

Code that's intentionally do that can set the IVSEL bit before enabling interrupts, but if you compiled thinking you had a bootloader section, but didn't, every interrrupt would cause you to jump to the empty first page, skid along to 0xFF's until you hit reset and triggered the dirty reset protection (see Ref_Reset). And if you didn;t set IVSEL because you didn't think you were set to use a bootloaded but you are, you'll jump to the same byte as the interrupt vector but on page 1, effectively resulting in deterministically random behavior. It drove me insane when I ran into it, because I could recognize parts of the sketch behavior there, but they were all out of order.

So on modern AVRs, because the bootloader is now at the beginning of the flash, "Upload using programmer" with an optiboot definition very likely means "Upload sketch that behaves completely wrong".

Am I missing something? If it uses Optiboot, then why do you need to export and use external tool?

[ObviousInRetrospect]

I propose that upload using programmer do a combined "burn bootloader" and "burn the application after the bootloader". No reason you can't write the app and the bootloader in the same UPDI session. I think at one point I tested combining the hex for the bootloader with the hex for the rest of the firmware.

The specific reason this would be useful in my case is I have the bootloader serial port pointed at an esp32. The reason for optiboot is to allow OTA updates to be pushed down from the ESP32. But it is inconvenient for the dev/test cycle when the board is at a computer to have to run the updates through the ESP32 (which ordinarily receives them slowly over LoRa). Also optiboot at 1s timeout doesn't work well interactively without auto reset (which I don't really want).

At the moment I select "no bootloader" when I am doing quick iterations, live with the minor differences in behavior, and hope I remember to re-burn the bootloader. But even then I have to do a first upload through a special avr-corrupted recovery path when really it would be better if the firmware were loaded together with the bootloader.

[dpetican]

I agree with @ObviousInRetrospect That is my exact use case as well. Essentially the final combined burn is a production line burn. Otherwise you have to burn the bootloader then upload the production sketch through the ESP32. Of course you could just concatenate the bootloader binary to your program binary and use Microchip Studio to flash the chip. But thats prone to errors. Actually I would just like to be able to export the combined binary from Arduino and use Microchip to do the programming. A lot faster when you are doing 100 boards.