wrong size and hfuse for Nano in boards.txt

[nerdralph]

nano.menu.cpu.atmega328.upload.maximum_size=30720 This should be 32256, & hfuse should be DE instead of DA.

[per1234]

Duplicate of #10

See the discussion there for an explanation of why it is that way.

[nerdralph]

The explanation makes no sense. boards.txt has a separate entry for the old bootloader: nano.menu.cpu.atmega328old=ATmega328P (Old Bootloader)

Also, if someone chooses the nano/optiboot, and does a "burn bootloader", the boot fuse reset vector will not match the start of the optiboot code. It'll happen to work because the undocumented 0xFFFF opcode decodes as sbrs r31, 7, on the 328p, and so the PC will eventually get to the start of the optiboot code. Even if @facchinm was intentionally relying on this undocumented behavior, I think it's still bad practice.

[ArminJo]

@facchinm Why are this values not changed too? The baud rate was changed for the new bootloader, but the other values not. I modified my boards.txt, burnt the bootloader with the new values and everything was fine. BTW: The last years I always burnt the UNO Bootloader and settings on my ~40 Nano boards, and had no problems, even with 99% code size. Do you need a PR?

[matthijskooijman]

Looking at this quickly, I think that indeed changing these values would be appropriate. There's already a submenu for old vs new bootloader, and the bootloader uses a different baud rate, so we won't have to worry about people accidentally selecting the wrong bootloader (since then uploads will simply not work at all) and ending up with a wrong max size.

@ArminJo If you tried this, I would welcome and review a PR, though I can't merge it.

@facchinm, or am I missing some important argument here?

[per1234]

The BOOTSZ fuse is set for a 2 kB boot section on the Nano boards shipped by Arduino. So if you change the upload.maximum_size then you are allowing the application code to be flashed into the boot section, which I believe could result in a "bricked" board.

[matthijskooijman]

Ah, I see. They are shipped with a smaller bootloader, but not with the right fuse setting for that bootloader size. Yeah, then increasing the max size is indeed harmful for those boards. Re-reading @facchinm's comment in #10, this is exactly what he said, maybe I should be sleeping rather than replying to tickets :-p

We might still want to support a way for people to use Burn Bootloader to replace the fuses and allow using more flash, but I'm not sure how. We could add a "new bootloader full flash" option to the submenu, but I'm not sure how we should call it so that people won't be terribly confused about what it does ("new bootloader with settings that allow full flash usage, can only be used when you've replaced the bootloader with Burn Bootloader yourself")... The current two settings are already confusing, and now at least people can just try both and use the one that works.

So, unless someone has a good suggestion on another approach, I don't think we can just fix this...

[per1234]

If people want to set the fuses for the smaller boot section and get access to the full amount of flash, they have the option of doing as ArminJo described and burn the bootloader to their Nano using the "Arduino Uno" board selection. This is a common recommendation on the Arduino forum.

It is perhaps a bit confusing that you must use use the Nano as an Uno, but people who are burning bootloaders are typically advanced enough users that I don't think it will give them too much trouble. I know that the NUM_ANALOG_INPUTS macro will be set to 6 when you do this, but I've done some surveys and found there is very little use of this macro (I believe the Firmata library was the only significant use I discovered).

"new bootloader with settings that allow full flash usage, can only be used when you've replaced the bootloader with Burn Bootloader yourself

Hahaha! I love it.

[ArminJo]

Now I got it too. @per1234 I tried to write 30994 bytes to an old bootloader on my Nano, which was hard, since I must tweak the baudrate and I was NOT able to brick the device.

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "RobotCar.hex"
avrdude: input file RobotCar.hex auto detected as Intel Hex
avrdude: writing flash (30994 bytes):

Writing | ################################################## | 100% 7.75s

avrdude: 30994 bytes of flash written
avrdude: verifying flash memory against RobotCar.hex:
avrdude: load data flash data from input file RobotCar.hex:
avrdude: input file RobotCar.hex auto detected as Intel Hex
avrdude: input file RobotCar.hex contains 30994 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 6.64s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x7800
         0x0c != 0x0b
avrdude: verification error; content mismatch
avrdude done.  Thank you.

The same result to a Nano with new bootloader, but fuse DA for 2 kByte. So there is no possibility to brick the bootloader!

[ArminJo]

@per1234 Is there a reason for the "wrong" fuse on the nanos?

[per1234]

I have also done some quick experiments like this and I got the same results of the verification error from avrdude. So maybe it's not possible to brick the board by writing data to the boot section. I don't know enough to understand what is happening here.

However, this verification error is enough of a justification to not change the fuses. I would much rather get the friendly error during compilation about my sketch being too big for the program memory than this confusing verification error during.

Is there a reason for the "wrong" fuse on the nanos?

I don't know anything more than what is written here: https://github.com/arduino/Arduino/commit/1cf34c8250658c5c4a5c488f7a7a0d7071e3430f#commitcomment-27651798 and here: https://github.com/arduino/ArduinoCore-avr/issues/10#issuecomment-371864097

[matthijskooijman]

I have also done some quick experiments like this and I got the same results of the verification error from avrdude. So maybe it's not possible to brick the board by writing data to the boot section. I don't know enough to understand what is happening here.

I think the fuses have write protection for the bootloader area configured, so the bootloader cannot overwrite itself. However, I would expect a slightly different error (involving 0xff in the verification failure), but maybe the test wasn't done on a cleanly erased chip.

However, this verification error is enough of a justification to not change the fuses. I would much rather get the friendly error during compilation about my sketch being too big for the program memory than this confusing verification error during.

But maybe this could be a third option in the menu, after all, then? If selecting the wrong option does not actually silently breaks (even though it does not break in an obvious way, at least it shows some error), then there's no chance for selecting the wrong option accidentally.

If the fuses used in production are also updated, then at some point in the future, the default could maybe be changed as well?

[facchinm]

Hi all, the problem is entirely on our side. Said that, the deprecation policy could become a huge mess if we add yet another menu entry. I'm not afraid of people bricking their boards (which is impossible given the bootloaders fuse protection) but about the avrdude verification error, which is totally unexpected particularly for newbies (since the "not enough space" error did not fire).

Open to discussion on how to tackle this (maybe an online FAQ explaining step by step how to create an overlay platform for Nanos with UNO bootloader AND right fuses)?

[ArminJo]

@facchinm Could it be an option to improve the avrdude error handling / error message?

[facchinm]

The verification error is a bit too generic to change directly in avrdude but there is a hook in java IDE that allows overriding the error message https://github.com/arduino/Arduino/blob/master/arduino-core/src/cc/arduino/Compiler.java#L558 . arduino-cli doesn't support this yet but it could be added to the backlog if needed.

[matthijskooijman]

Except that there's not really any way to detect that the error really is caused by a mismatch here, so at best we could add a "Maybe you have the wrong Nano selected" message to the error, which would probably only be meaningful if it was hardcoded to only trigger for the nano and only when the size is near full, which might be more hardcoding than we might want... Hm..