It seems the Ebay Nano lookalikes come with the old bootloader, and I thought it might be a good idea to flash Optiboot to them instead. First, is there any reason I shouldn't do that?
Anyway, looking in IDE v1.8.8, I see an Optiboot hex file for the 328 which I assume is what will be flashed if I set up a programmer and hit "Burn Bootloader". But that file appears to be Optiboot v4.4 dated 16 October 2017, and I see elsewhere here that Optiboot is now at v8.0. If I wanted to burn the latest version, could I just replace the existing hex file with the v8 hex file for the 328? If so, where would I find that hex file? And I guess I should ask if there's any reason not to use the latest version, or if it even makes any difference for a Nano.
ShermanP:
First, is there any reason I shouldn't do that?
The only reason not to do that is that Burn Bootloader is a somewhat complicated process that some people have a lot of problems with. You can spend a lot of time struggling with it, or you can get to playing with your Nano that currently works fine. That said, I immediately burn optiboot to all my Nanos. Of course, for me, it only takes a matter of seconds because I've done it so many times.
ShermanP:
If I wanted to burn the latest version, could I just replace the existing hex file with the v8 hex file for the 328?
You could do that. It's probably easier to use MiniCore:
ShermanP:
If so, where would I find that hex file?
You can compile it yourself. You can also get optiboot .hex files here:
I'm not sure those are exactly the same as the official release of optiboot 8.0 but if not it should be pretty close.
ShermanP:
And I guess I should ask if there's any reason not to use the latest version, or if it even makes any difference for a Nano.
Probably the only reason you would care about using 8.0 for a Nano is that it has a feature that allows you to write to flash from the application:
DrAzzy:
You could also just tell the IDE it's an Uno and burn that bootloader, and thereafter call it an Uno.
Either that or the MiniCore bootloader will also give you an extra 1.5k of flash.
Yes, I saw a Julian Ilett video on making it an Uno. But I thought that the newer versions of the IDE recognized that a Nano could have Optiboot on it. In fact, I had to choose "Nano with old bootloader" to get mine to work. So I thought if you said it's a Nano, and selected Burn Bootloader, it would burn Optiboot, but still recognize it as a Nano.
That's correct, if you have Tools > Processor > ATmega328P selected. However, the Nano board definition still sets the boot section to 2 kB, even though the Optiboot bootloader fits in a 0.5 kB boot section. By using the Uno board definition (or MiniCore), you free up 1.5 kB of precious program memory on your Nano, with absolutely no disadvantages.
ShermanP:
I assume I would want the 16000000L folder from that repo for the Nano. But what baud rate would the IDE expect to see? Is it 115,200?
In that folder, there is a hex file for each of the the common baud rates. If you want 115200, use optiboot_flash_atmega328p_UART0_115200_16000000L.hex.
But that file appears to be Optiboot v4.4 dated 16 October 2017, and I see elsewhere here that Optiboot is now at v8.0. If I wanted to burn the latest version, could I just replace the existing hex file with the v8 hex file for the 328?
Yes, that would work. Version 4.4 is from 2012 or so. Arduino is conservative and hasn't made any changes to the actual code since then.
If so, where would I find that hex file?
8.0 is on the github optiboot page: Optiboot AVR Bootloader ยท GitHub The .hex file for 328p is still being provided (although in general this has become more a source for ... source, if you want custom options.) I think minicore is still at 6.2, but MCUdude's "optiboot-flash" is also updated to 8.0
And I guess I should ask if there's any reason not to use the latest version, or if it even makes any difference for a Nano.
The meaningful changes (for a Nano) in 8.0 include:
Causes failure instead of incorrect behavior, if the host tries to write EEPROM (v6)
Improves the ability to pass reset cause to the application (v7)
Allows sketches to call a function to write to flash memory. (v8)
Under some circumstances, (3) might be considered a security risk. A malicious sketch could delete the bootloader and "brick" the board. Perhaps.
8.0 might be slightly slower to upload - but not enough that anyone has actually noticed, much less complained. (older versions would program a page and begin receiving the next page at the same time. 6.0+ waits until each page program finishes. The page write takes a maximum of 4.5ms, so this could amount to about 1.2s increased programming time for a full 32k sketch (could be 5s slower on a full MEGA2560. Horrors!))
If 8.0 allows the application to overwrite the bootloader, i would call that a bug in optiboot, one that should be a priority to fix. It should be straightforward to test for this condition and block it....
Older versions would program a page and begin receiving the next page at the same time.
Free some Flash?
Freed some flash. Quite a bit, actually, since the original implementation ended up needing essentially double code to handle the section of flash that couldn't do the overlap anyway (the "NRWW section")
(Sigh. I don't seem to have actually recorded how much? This was back in 2014. If you're using MiniCore, you've been running the "slower" code for a long time. IIRC I started some discussion at the time (but I can't find it.)) There have been a number of other "shrink" modifications as well.
Oh yeah - one more difference. Version 4.4 no longer compiles to less than 512 bytes, using the version of the C compiler that comes with Arduino. (Only relevant if you need to compile the source for some reason. In which case you really want to use the github version because of the much easier customization that is provides.)
If 8.0 allows the application to overwrite the bootloader, i would call that a bug in optiboot, one that should be a priority to fix.
It looks like it should be prevented by the lock bits...
It should be straightforward to test for this condition and block it....
Maybe. All the bootloader does is load up the arguments passed to it and execute an SPM instruction. To test for a "legal" SPM, we'd (theoretically) need to decode what the arguments meant. (in practice, I'm not sure there's ever going to be a valid SPM with R0 larger than the bootloader start address...)
I guess I'm also ignorant about how Github works. If I go to one of the MiniCore link or MCUdude link and find the right .hex file, right-click on that and save it, what I get is source code. It still has a .hex extension, but it's source code, about 74K. So to get the actual .hex file, I had to left-click on the file, which makes the actual .hex file text be displayed in the text box below, then copy and paste that into a .hex file.
I'm sure I'm doing something wrong, but it's really confusing that right-click and save-as doesn't give you the file you right-clicked on. Anyway, I have the v8 .hex file now, so thanks to everyone for the links.