New Nano with incorrect settings

[dmjlambert]

So, is the New Nano really shipping with incorrectly burned fuses and new 256 word Optiboot bootloader with a bunch of leading FFs?  And the specs at the store incorrectly says the bootloader takes 2K?  Is it just the IDE that is incorrect?  The board shipping incorrect and the IDE is incorrect?   Or since it will work this way, nothing is incorrect, just my opinion that it may be screwy, and it's really just fine? (it's happened before...)

https://store.arduino.cc/usa/arduino-nano

http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega328p&LOW=FF&HIGH=DA&EXTENDED=FD&LOCKBIT=0F

[pert]

So, is the New Nano really shipping with incorrectly burned fuses and new 256 word Optiboot bootloader with a bunch of leading FFs?

The official Arduino Nano (the ATmega328P-based one, not the brand new Nano Every/33 IoT/33 IoT Sense/33 BLE) sold from 2018 onward uses the same Optiboot bootloader as the Arduino Uno. Although the Optiboot bootloader does fit in a 0.5 kB boot section, the boot section on the Nano is set to 2 kB, just as with the older Nanos that use the "ATmegaBOOT" bootloader (which does require a 2 kB boot section).

More information here:
https://github.com/arduino/ArduinoCore-avr/issues/10

So boards.txt is correct and so is the information on the Nano's product page.

The primary benefit of the switch to the Optiboot bootloader is that the "ATmegaBOOT" bootloader has a bug that causes the boards using it to go into an endless reset loop after a watchdog timer reset:
https://github.com/arduino/Arduino/issues/4492
Optiboot does not have this bug.

[dmjlambert]

Perhaps I should have used the word improper, instead of incorrect.   So, it's correct the way it is, because it is as the designer intended or perhaps it is just the way it is and happens to work by accident.   

One of the benefits of Optiboot is it fits in 1/4 of the size of the old bootloader, leaving an additional 1.5K of user programming space.  So, the new design does not properly set the beginning of the bootloader section to the first instruction of Optiboot and wastes user programming space.

OK, now what happens when the bootloader is burned?  The chip is erased, which results in a flash memory full of FFFF, then the bootloader is programmed in the upper portion of memory.   Then, the fuses are set so execution starts in the middle of a bunch of FFFF invalid instructions.   As of the current version of the ATmega328P chip, FFFF just happens to do nothing (or very little depending on who you talk to).   So far, so lucky.   It seems to me it is just improper and warrants correction.   Perhaps I'm just in a mood.   

Slightly related to this, in the IDE, the upload sketch using a programmer should unprogram the boot reset vector (BOOTRST) fuse, so execution of the user program does not begin with a bunch of FFFF invalid instructions in the bootloader area and then wrap around to the low address range, or worse yet execution begins somewhat near the end of a long user program.   

[pert]

or worse yet execution begins somewhat near the end of a long user program.   

I don't see how the user program can end up in the boot section, since the Arduino IDE will fail the compilation if the program exceeds {upload.maximum_size} when you do an Upload Using Programmer.

It would be nice for Upload Using Programmer to support using the entire flash memory, since that is one of the primary benefits of using a programmer to upload.

[dmjlambert]

Ah, yes, I see.   I didn't think of that.    So, part of a user program can end up in the boot section if the IDE were enhanced to have a separate upload size in the boards.txt file, for when upload using programmer is used.   3 enhancements are really needed, and they all kind of go together (not required to go together but would be nice):

• fix the fuses so they are correct for a new Nano with smaller bootloader (just make the fuses same as for Uno).
• fix upload using programmer to use a different upload.maximum_size during compilation, that takes advantage of the whole memory.
• fix upload using programmer to unprogram the BOOTRST fuse during the avrdude command.   

[pert]

fix the fuses so they are correct for a new Nano with smaller bootloader (just make the fuses same as for Uno).

Would you also update upload.maximum_size to 32256, or just change the fuses for a 0.5 kB boot section and leave upload.maximum_size at 30720 as if the boot section was still 2 kB?

• fix upload using programmer to use a different upload.maximum_size during compilation, that takes advantage of the whole memory.
• fix upload using programmer to unprogram the BOOTRST fuse during the avrdude command.  

I think these two proposals would be nice, and quite easy to implement as well. I can't see any possible downside to it. The user is going to have to do a Burn Bootloader to go back to standard uploads anyway so that will take care of programming the BOOTRST fuse again.

Some 3rd party cores are currently dealing with this issue by adding a Tools > Bootloader custom menu. When it's set to "No bootloader", different fuse, upload.maximum_size, and bootloader.file values are used. It also doesn't define upload.protocol, which causes the Arduino IDE to do an Upload Using Programmer even when the regular Upload button is clicked:
https://github.com/MCUdude/MiniCore/blob/master/avr/boards.txt#L66-L69

[dmjlambert]

The 3rd party core way of dealing with that may be best, I'm not sure.  My experience with using 3rd party cores is limited.    There's a lot of ways to deal with it.   I suppose if the boards.txt had 2 values for each board upload.maximum_size and upload.maximum_size_programmer_upload or something like that, then the IDE could pick the appropriate parameter to use depending on what type of upload is being done.   

If no upload is done, but instead the user just picked the compile button, a deluxe IDE would compile allowing the bigger size and show a warning if the smaller size is being exceeded, and tell the user in order to fit this program on the target you'll have to upload the hex file using a programmer because the program is too big it fit both the program and the bootloader on the target.