I bought some clone NANOs with type-c long time ago, and discover it's with old-bootloader and also with the chip "328PB".
Recently for easy programming I loaded those with new bootloader. had to flash with -F.
(used USBASP for flash, UNO for Bootloader)
All went okay, and those NANOs now programming with default board settings in Arduino IDE.
But then I selected "UNO" board by mistake, and those NANO still getting programmed without any error.
Then I Plugged in clone UNO. and tried to programmed it with "NANO" board selected in IDE. and the UNO getting programmed without any error....!!
In short, NANO & UNO are getting programmed, when IDE board set to any UNO or NANO.
I'm quite sure, it doesn't happened like this before (even with clone boards). Is it normal..? My main concern is if it is okay...??!!
My IDE version 2.3.6. (I'm suspecting the new IDE version)
Extra info:
All are using CH340 programmer.
I'm sure I didn't changed UNO's bootloader, it was always connected via USB.
I loaded new bootloader to Six NANO... so can't load UNO bootloader to all of them if anyone suspecting.
Selecting Tools > Board > Arduino AVR Boards > Arduino Uno from the Arduino IDE menus was not a mistake in this case. You should use the same board configuration you had selected at the time you burned the bootloader. So if you had Tools > Board > Arduino AVR Boards > Arduino Uno selected from the Arduino IDE menus at the time you burned the bootloader, then you should use that same menu selection when uploading as well.
This leaves the question of why you are able to upload to the two boards even when you have the incorrect Tools > Board menu configuration:
The UNO R3 and the "new bootloader" Nano boards both use the same Optiboot bootloader. So this is why you can successfully upload to either board while Arduino IDE is configured for the other.
However, there is a significant difference in the configuration of the two boards that you should be aware of:
The configuration fuses of the UNO R3's ATmega328P microcontroller have been configured to reserve a 0.5 kB boot section, leaving 31.5 kB of flash memory available for use by your compiled sketch program binary.
Due to a mistake on the part of the Arduino company, the configuration fuses of the Nano's ATmega328P microcontroller have been configured at the factory to reserve a 2 kB boot section (even though it is superfluous to the requirements of the Optiboot bootloader, which fits in a 0.5 kB boot section), leaving 30 kB of flash memory available for use by your compiled sketch program binary.
Arduino IDE displays a memory usage summary in the compilation output. For example:
Sketch uses 444 bytes (1%) of program storage space. Maximum is 32256 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.
The percentage calculation and "maximum" is based on information defined in the board definition (not provided by reading actual configuration of the microcontroller).
Here is the information in the definition of the "Arduino Uno" board:
and here for the "Arduino Nano" board (with the Tools > Processor > ATmega328P configuration AKA "new bootloader):
You can see that each board definition reflects the configuration fuse settings of the ATmega328P on the hardware as it comes from the factory, with the "Arduino Uno" board definition being configured for the 31.5 kB of available flash memory on that board's ATmega328P, and the "Arduino Nano" board definition being configured for the 30 kB of available flash memory on that board's ATmega328P.
So if you select Tools > Board > Arduino AVR Boards > Arduino Nano", and Tools > Processor > ATmega328P from the Arduino IDE menus and then compile or upload to an UNO R3 board, or a Nano board to which you have performed a "burn bootloader" operation while Tools > Board > Arduino AVR Boards > Arduino Uno was selected, then the memory usage report will be incorrectly based on a maximum program size of 30 kB. And Arduino IDE will even spuriously fail the compilation if the compiled binary size exceeds 30 kB, even in the case where it actually would fit in the 31.5 kB that is available on the hardware!
Shouldn’t this be fixed in the boards.txt file? I have 13 Nano boards the drove me nuts because when I selected Arduino Nano from the Board menu, it defaulted to ATMega328P (which it has) and failed to program! I had not used them in quite awhile (they were in storage for a long time while I moved) and they worked the last time I used them. After I found them in storage, I brought them home to tinker with them and they failed to program until I eventually changed it to the ATMega328P (old bootloader) and it finally worked. So to eliminate the headache months down the road I burned the bootloader for the ATMega328P version which is the Optiboot bootloader. I saw it was MUCH smaller (502 bytes) and supports faster upload speeds etc etc! Great! That means I gained some memory back for my sketches!!
WRONG! It does upload faster using the new bootloader, but it did not gain the memory space back! And now I know why!
Your explanation sums up what I had suspected. I like things simple and straightforward! If I use a Nano, I select it and it should work the exact way I expect it to. When I use an Uno, same deal. I shouldn’t have to try to think “Oh did I use the UNO to burn the boot loader on my Nano to gain the extra 1.5K?”
So I think these things should be in the boards.txt file!
Bottom line is, I’m going to modify my boards.txt file to reflect the correct settings to preserve my own personal sanity! But then every time the core AVR boards gets an update, I will have to do it all over again. Unless they fix it!
Thanks for your very clear and concise explanation that keeps what left of my hair I have left!
P.S. As of this post I have 1.8.7 of the Arduino AVR Boards core installed. Just incase some one wondered or asked. And it still has this same BUG (that’s what I am calling it since it is not correct).
Hi @BLUE_AG. The "Arduino Nano" board definition in the boards.txt file is designed to support the manufactured boards. It is correct in that context (even if the configuration of the manufactured boards is suboptimal).
The way forward would be to update the manufacturing procedure, and then add yet another variant of the board configuration for use with the boards manufactured after that change. Something like this:
ATmega328P
ATmega328P (New Bootloader, Old Fuses)
ATmega328P (Old Bootloader)
The customers who purchased an official board after the time of that change would need to select the "ATmega328P" option. The customers who purchased an official board after the "new bootloader" switch in 2018, but before the fuses update would need to select the "ATmega328P (New Bootloader, Old Fuses)", and the customers who purchased an official board prior to 2018 (or a 3rd party clone/derivative board from a manufacturer still using the old bootloader) would need to select the "ATmega328P (Old Bootloader)" option.
The Arduino company decided that it wasn't worth the extra disruption and complexity to produce yet another variant of the board.
Could you explain the differences? What do you mean be “old fuses” The boards I have are the same. I updated them all for the 502 byte Optiboot Bootloader but the definitions still have the Flash Memory for the boot loader reserved for 2K. I updated my copy of the boards.txt file to reflect the update and it works fine. I gained the 1.5K back.
Here are those changes:
##This is to adjust for Optiboot Loader
nano.menu.cpu.atmega328.upload.maximum_size=32256
nano.menu.cpu.atmega328.upload.speed=115200
##Again to adjust for smaller Optiboot Loader
nano.menu.cpu.atmega328.bootloader.low_fuses=0xFF
nano.menu.cpu.atmega328.bootloader.high_fuses=0xDE
nano.menu.cpu.atmega328.bootloader.extended_fuses=0xFD
The only real changes I made were in the SRAM available and the High Fuse setting. Everthing else was the same. So I am curious to what FUSE settings changed for the “newer” boards. I believe the Upload BAUD rate was already updated to the faster rate for Optiboot.
I hope this helps. I saved a copy so when the board manager is updated or reloaded, I’m certain the boards.txt file will be restored to it’s original “broken” state. It doesn’t make sense since the Optiboot code is smaller and they updated it for the Uno but not the Nano. A missed detail I am sure or no one cared. I’d call that lazy!
What disruption? If you flash a new Bootloader and the size changes, why not be thorough and update it so it’s not protecting more space than it actually takes up? Shrinking down the bootloader to save more space was the point so why reserve the same amount the old boot loader takes up? They did it on the UNO so it makes sense to update it the same way on the Nano.
Yes, but note that the missed detail was in the manufacturing procedure, not in the "Arduino AVR Boards" platform.
I already explained this. It is confusing for users to have to figure out how to configure the Tools > Processor menu for the specific variant of the board they happen to have. We still get support requests here all the time from people who can't upload to their board because their board has the old bootloader, but they don't have Arduino IDE configured accordingly. Likewise, we see reports from people who can't upload to their board with a new bootloader because they found some advice to configure Arduino IDE for use with boards that have an old bootloader.
It is certainly reasonable to argue that the benefits of creating yet another variant of the board outweigh the harm, but you can't deny that doing so will have harmful effects.
(that’s what I am calling it since it is not correct).