Windows administrator-level AVR core update?

Apologies if this is covered elsewhere, I know I'm a bit late to dealing with this issue.

My understanding of the current "state of play" for Arduino Nanos is:

  • To use Nanos sold by Arduino after January, 2018, you need to install AVR Core 1.6.21 via the Tools > Board > Boards Manager menu item
  • Updating the AVR core in this way puts the changes in the Users/(username)/AppData/Local folder and is therefore a per-user, per-machine fix
  • There is no current downloadable Windows build that enables the 1.6.21 core by default

My question is: Is anyone aware of an administrator-level fix for this issue? For single-user systems the current status is frustrating but ultimately not a big deal since it can be fixed with a little googling and 15 seconds of update time.

But in a multi-user environment it is a nightmare. I have 100 users who log on to 18 different machines; dealing with a per-user, per-machine solution results in a ton of confusion -- and we already have to manage the level of confusion, because once all of this is set up they still need to keep track of which nearly-identical Nano boards use the "ATmega328P" processor and which use the "ATmega328P (old bootloader)" processor. (In the short term I'm painting all my new Nanos red...)

If anyone has found or created a solution that forces the 1.6.21 core for all users on a machine, either directly via administrator action or indirectly via a per-user login script, or some other sneaky means, I would love to learn about it. Or, even better, if I'm wrong about one of my assumptions and there's an even easier solution out there, that'd be fabulous too.

Thank you!

sbanzaert: - To use Nanos sold by Arduino after January, 2018, you need to install AVR Core 1.6.21 via the Tools > Board > Boards Manager menu item - Updating the AVR core in this way puts the changes in the Users/(username)/AppData/Local folder and is therefore a per-user, per-machine fix

Correct.

sbanzaert: - There is no current downloadable Windows build that enables the 1.6.21 core by default

There is no production build but the hourly build has it. That version is actually not terribly different from Arduino IDE 1.8.5 (see: https://github.com/arduino/Arduino/compare/1.8.5...master) since most of the development work done since that release has been getting pushed to the beta build. Deploying a non-release version of the IDE to 100 users is not generally best practices so you'd need to evaluate that decision carefully. I just thought I should mention that your statement was not 100% correct.

sbanzaert: My question is: Is anyone aware of an administrator-level fix for this issue? For single-user systems the current status is frustrating but ultimately not a big deal since it can be fixed with a little googling and 15 seconds of update time.

I think you can do this by putting the Arduino IDE into portable mode, then installing Arduino AVR Boards 1.6.21. That will cause it to be installed to the portable subfolder of the Arduino IDE installation folder instead of Users/(username)/AppData/Local/Arduino15. You can find more info about portable mode here: https://www.arduino.cc/en/Guide/PortableIDE

You also could just manually make the minimal changes introduced between Arduino AVR Boards 1.6.20 and 1.6.21:

That's literally all that has changed. There are no changes to the toolchain.

How do I know if the Arduino Nanos I buy on eBay are subject to this requirement?

What happened is that Arduino finally decided to start using the much better Optiboot bootloader that has been used on the Uno for years. The Uno bootloader was compiled to communicate at 115200 baud rather than the 57600 baud of the old bootloader. So they had to change the boards.txt entry for the Nano board with the new baud rate and also pointing to the optiboot bootloader file for when people do Tools > Burn Bootloader.

For backwards compatibility they added a Tools > Processor > ATmega328P (Old Bootloader) menu. Note that the default selection of the menu is Tools > Processor > ATmega328P, which has caused many people to have problems with their non-optiboot Nanos after updating to Arduino AVR Boards 1.6.21.

If you have the Nano on hand you can just try an upload. If you're using Arduino AVR Boards 1.6.21 and the upload fails with Tools > Processor > ATmega328P then you have the old bootloader. If it succeeds then you have the new bootloader.

If you are wondering what you will receive when you purchase a Nano clone that's tricky. I'm not sure whether the cloners are even aware of the change yet. Even after they change to the new bootloader there is probably a lot of stock of Nanos with the old bootloader out there that they probably won't bother to re-flash. I'd suspect the same goes for backstock of genuine Nanos. You could ask the seller but many of them consider the product just a widget and may have never used one so they might just tell you whatever they think will make you buy it.

The best way to be sure of what bootloader is on your board is simply to flash the known bootloader to it. You can use an extra Arduino as an "Arduino as ISP" programmer or just buy a cheap USBasp clone to make it even easier. If you're doing this I recommend (assuming it's an ATmega328P Nano) that you select Tools > Board > Arduino/Genuino Uno before burning the bootloader and then use the Nano as an Uno from then on. The reason is that, even though they used the same bootloader as the Uno, Arduino forgot to update the fuses to change from a 2 kB boot section to the 0.5 kB boot section allowed by Optiboot. This negated one of the primary benefits of switching to the new bootloader. So you get an extra 1.5 kB of program memory by using a Nano as an Uno.

Thank you. I didn't know there was a source for hourly builds so that's good to know about, though as you note it's probably a bad idea to roll it out to a 100-user environment. I'm only slightly less nervous about updating the AVR core by hand in place... I wonder how that might interact with the board manager. I'll probably be juuuuust dumb enough to try it out in lab tomorrow. But all of these not-great options are being measured next to Plan A, where students have a slightly daunting flow chart to work through just to get Blink to upload.

(I realize I represent a corner case where I have maybe 200 Gravitech and Arduino Nanos of various vintages kicking around, but breaking backwards compatibility like this is close to my perfect nightmare scenario. It's going to take years for my concentration of Optiboot Nanos to get to 100%. That the Nanos being sold by Arduino for the last 8 weeks can't be programmed by the most up-to-date public IDE (without mucking around with the AVR core) is honestly a decision I find totally baffling.)

Thank you for that great information.

What's even more baffling is that they didn't set the BOOTSZ fuses, so the switch to optiboot doesn't even get you the extra space for the sketch. What the hell were they changing it for?!

I'd be inclined to either start bootloading all the nanos (probably as unos, like pert suggested) or using clone nanos with the old bootloader on them...

This sort of halfassery we have to put up with from the Arduino team is really disappointing at times.

I actually lied about the hourly build. I had downloading as I wrote that intending to verify what I said before hitting post and then forgot about it. It's supposed to update every hour if there is a new commit but hasn't done so since 01/03 despite there having been several commits since that time.

The other benefit of changing from the old bootloader to Optiboot, besides their lost opportunity to free up 1.5 kB of flash is that the old bootloader goes into an endless reset loop after a watchdog reset. That's a very bad experience for the person who ends up in that situation by running some code that should work fine and a major limitation once you realize that you can't use the watchdog. So there is something good about the change. The sad thing about the boot section thing is that if they weren't going to change the boot section then they could have recompiled Optiboot for 57600 baud communication and done the upgrade without any breakage at all. Optiboot Nanos and regular Nanos would have been intercompatible, with no mandatory package update and no need for a special menu selection to use the old boards.

I agree with DrAzzy about the best solution being to change the bootloader on the Nanos so they are all consistent with each other. Even after updating Arduino AVR Boards, having a mixture of Nanos with old bootloader and new bootloader is going to cause endless confusion for students and teachers both. Turn some of your Nanos into "Arduino as ISP" programmers with cables made out of jumper wires taped together so that it's very fast to make the connection to the target board every time and enlist some helpers. Once you have things set up it's a very simple process: Plug the programmer cable into the target board, click Tools > Burn Bootloader, wait for process to finish, unplug the target from the programmer cable, repeat.

For sure one of my summer projects is going to be making an auto-Nano-programmer with an ISP socket and a big red button to re-flash the target bootloader. That’s actually what we started doing before we knew what was going on – we handed the new Nanos out to about 40 students with absolutely no idea about the incompatibility and solved it at the time by re-flashing the (now-classic) bootloader. That’s probably one of the reasons I’m so crabby about this – we shouldn’t have had to learn about this via a DigiKey blog post. When they changed the Uno bootloader, every Uno that was sold for a while came with a sticker that said “go get the new IDE!” I guess “go figure out how to update your AVR core to 1.6.21” doesn’t quite fit on a sticker.

Meanwhile I recommend red Rustoleum as a temporary solution, at least for disambiguation (photo attached)…

Haha, I just noticed I was trying to teach someone from MIT how to flash a bootloader. I didn't read the bio before.

This has been incredibly helpful, and not just for the chance to vent a little. We use Nanos a lot, and we have a bunch of custom-built controller boards that mate with the Nanos (which is why I'm so invested in them) but I don't keep up with the development side at all, so all the information about the dev process and the possible solution scraped from Github was super-useful. This is probably a sign that I should keep an eye on the dev side more...

pert: Haha, I just noticed I was trying to teach someone from MIT how to flash a bootloader. I didn't read the bio before.

He's a physicist. http://www.cdio.org/cdio-action/people/steve-banzaert

,