Are there too many different bootloaders in the Arduino world?

[elecdonia]

I’m doing several projects which require a small MCU with true 5V I/O. Atmel AVR devices are a perfect match for my needs. And because the Chinese offer a vast quantity of “Arduino compatible” boards for <$10 USD each, I stocked up. This speeds up breadboarding and debugging. My end products will likely contain “bare metal” AVR devices, but I’m not starting out that way.

I created this topic about bootloaders because some of these Chinese boards I received in Jan. 2023 came with really strange bootloaders:

1) A so-called “revised/upgraded Arduino-compatible 3V/8MHz pro-mini” board labeled “the simple.” By selecting board: “Arduino pro mini” in the Arduino IDE I successfully loaded one sketch into it. The sketch works fine, but afterwards the bootloader on this board totally lost its capability to connect to the Arduino IDE or to AVRDUDE. I’m using an adafruit FTDI friend which functions perfectly with 10 other (older) pro-mini boards, both 3V/8MHz and 5V/16MHz. Only this new “the simple” pro-mini board is acting strange. Fortunately it is still fully accessible with ICSP and a hardware programmer. Looking at it with ICSP I observed its bootloader is still there in flash. It didn’t get overwritten or erased. But it certainly doesn’t work now. This bootloader is 2k bytes, which seems kinda large to me. I’m about ready to load a different bootloader onto it. I use the 512 byte Optiboot along with “minicore” on several of my older pro-mini boards. I think I will try that with “the simple.”

2) I got a Chinese mega2560pro board which works nicely but has the largest bootloader I’ve ever seen on an Arduino-compatible board: 8k bytes. Compare that to most renditions of Optiboot which are 512 bytes. A bit of searching revealed the 256k AVR requires a whole different bootloader known as “STK500v2” in order to handle its gigantic address space. The person who originally developed the STK500v2 bootloader equipped it with a nifty self-contained debugging monitor which could be accessed by opening a serial terminal and typing “!!!” within 3 seconds of resettting the board. Unfortunately any sketch containing !!! would crash the boot loading process. Therefore the STK500v2 bootloader was soon revised to totally disable access to its internal debug monitor. But the debug monitor code is still in there today, occupying most of the 8k bytes. Ghost code? I realize that wasting 8k of flash isn’t a big deal for a 256k MCU. But this whole deal just seems really strange to me.

3) Next I started reading discussions about Arduino bootloaders on several different forums and observed that fully 50% of the threads are about being unable to use the bootloader. The most common fault is “error message says STK500 protocol won’t sync between board and AVRDUDE.”  Well, that’s exactly the message I’m getting from my “the simple” pro-mini clone board. But it worked perfectly… …one time. I wonder if the bootloader on it is some ancient version from the earliest days of Arduino?

If you are still with me I would like to learn which Arduino-compatible bootloaders you love and which ones you hate. Cheers!

[westfw]

You an put Optiboot on everything, including the 2560 boards.  Use one of MCUDude's or SpenceKonde's "cores", and/or refactor your thinking to decide that all ATmegaxx8 boards are "Unos."
Here's some history:

• Original Arduino bootloader is ATmegaBoot, which takes 2k and runs at a relatively low bitrate.  It uses stk500v1 protocol.
• It also had some bugs, and modified versions were distributed by Adafruit and Sparkfun.
• The Arduino Mega ships, and it has so much memory that that a fancier bootloader (including a "monitor" capability) is used - stk500v2 boot.  It also permits more than 64kwords to be uploaded, which stk500v1 didn't (at least, theoretically.)
• Optiboot shipped on the Uno.  At 512bytes, it frees up 1.5k for user programs (which no one really cares about, since the m328 has a whopping 32k!)  Inexplicably, upgrading old ATmega8 and ATmega168 boards does not catch on.
• Somewhere between (2) and (6), billions of "clone" vendors spring up and start shipping boards that are basically the same as one of the existing Arduino boards, but have ... who knows what bootloader on them.
• Optiboot is modified to support many more chips.  A cooperative hack between Optiboot and avrdude permits it to support more than 64kwords.
• Arduino adds (pretty good) 3rd-part board capability.  MCUDude implements most of the ATmega chips, SpenceKonde implements most of the ATtiny chips.  All using Optiboot.  (MCUDude adds some features, like a callable vector to write flash.  Optiboot is now at v8.1, and has Optiboot-x for mega0/xtiny and OptibootDX for AVR-Dx.  Arduino is still shipping version 4.4  Sigh.)
• Arduino starts shipping the Nano with Optiboot instead of ATmegaBoot.  If you have old Nanos, you have to set the board for "(old bootloader.)"
• Arduino ships mega0-based boards (Nano Every and Uno WiFi 2) that don't use a bootloader at all.
• "Native USB" platforms need an entirely different bootloader to talk USB.
• Non-AVR platforms need a different bootloader.

STK500 protocol won’t sync between board and AVRDUDE.

AVRDude error messages are not always the best.  "Can't sync" is what you're likely to get for a whole host of problems like: "you set wrong port", "the chip has a different bootloader", "your cable is bad", "Your USB/Serial Driver chip is bad", "Your AVR is bad", "You have something interfering with the serial port on the AVR", "There is no bootloader on the chip", "The bootloader is OK but the fuses are wrong", etc.

[NorthGuy]

My end products will likely contain “bare metal” AVR devices, but I’m not starting out that way.

Then your project will not have an Arduino bootloader and you will have to re-do all your Arduino work. If you want to go bare metal, start bare metal. This will save you lots of time and effort.

[elecdonia]

You can put Optiboot on everything, including the 2560 boards.  Use one of MCUDude's or SpenceKonde's "cores", and/or refactor your thinking to decide that all ATmegaxx8 boards are "Unos."
Here's some history: <snip>

Thanks for your suggestions and for providing both the history and context of Arduino bootloaders.

I’m thinking I will standardize by installing Optiboot on all of my Arduino-compatible boards which contain an AVR MCU, and especially on the Chinese clones which come with bootloaders.

I’ve used Optiboot and “minicore” on pro-mini boards and I give both an excellent rating. I may go this way with my larger boards too, since there is also a “mega core” variety available from MCUDude.

[elecdonia]

My end products will likely contain “bare metal” AVR devices, but I’m not starting out that way.

Then your project will not have an Arduino bootloader and you will have to re-do all your Arduino work. If you want to go bare metal, start bare metal. This will save you lots of time and effort.

By “bare metal” I am just referring to not using a factory-built pro-mini in my project (although using a pro-mini this way is a reasonable choice for one-off projects). In the past I’ve used the MCUDude cores, typically “minicore” along with Optiboot, by installing these directly onto AVR parts. I also put headers on my boards for connecting a USB to logic-level serial cable. This worked well for me. It provided bootloader access for firmware upgrades without needing a factory-built Arduino board.

[Buriedcode]

My end products will likely contain “bare metal” AVR devices, but I’m not starting out that way.

Then your project will not have an Arduino bootloader and you will have to re-do all your Arduino work. If you want to go bare metal, start bare metal. This will save you lots of time and effort.

By “bare metal” I am just referring to not having a factory-built pro-mini on my board (although using a pro-mini this way is a reasonable choice for one-off projects). In the past I’ve used the MCUDude cores, typically “minicore” along with Optiboot, by installing these directly onto AVR parts. I also put headers on my boards for connecting a USB to logic-level serial cable. This worked well for me. It provided bootloader access for firmware upgrades without needing a factory-built Arduino board.

I've started this for smaller projects, as a sort of half-measure. The convenience of a well supported bootloader system, without being completely reliant on specific hardware. I obviously don't trust this for "mission critical" work, but for my own projects and smaller commerical ones, it works fine.  Speeds up development a lot, and then it isn't much of a leap to drop the "Arduino" thing altogether.

[westfw]

Then your project will not have an Arduino bootloader and you will have to re-do all your Arduino work.

This is completely false.  The Arduino bootloaders are all completely separate and non-interacting with the user applications, whether they are "Arduino sketches" or programs written in some other development environment.  You can write Arduino sketches without using the bootloader (saves 0.5 to 8k of memory) (there's even an "upload using programmer" command), or you can use the Arduino bootloaders with non-Arduino applications.

The worst that is likely to happen is that for newer chips (ARM in particular), you may have to rebuild the application with a new segment start address for the vectors.  There are no run-time dependencies on the bootloader, and the bootloaders do their best to put the chip in a "just reset" state before starting the application.

[Peabody]

In your first example, in addition to selecting the Pro Mini in the IDE, did you also select the 8MHz version?  It just seems to me that if you were able to upload a sketch via the FTDI once, there's no reason why you couldn't do it again unless your IDE settings are different, or there's a bad connection.  Nothing would have changed the bootloader.

[NorthGuy]

You can write Arduino sketches without using the bootloader (saves 0.5 to 8k of memory) (there's even an "upload using programmer" command)

Really? I didn't know that.

[HwAoRrDk]

The only way an Arduino sketch could be dependent on the bootloader is if it called routines that were present in the bootloader's code. But AFAIK, the Arduino framework does not do that.

I seem to recall that there is some bootloader for AVRs that provides some of its routines as callable helpers for in-app flash programming, but I don't remember where I saw that or which one it was. But use of such would certainly be an explicit choice by the application developer.

[westfw]

I seem to recall that there is some bootloader for AVRs that provides some of its routines as callable helpers for in-app flash programming

The latest Optiboot has this feature, added by MCUDude..

And yes, if you want to write flash from your application, you have to have a function in the "bootloader section", because only the bootloader section is allowed to write to flash.

[elecdonia]

In your first example, in addition to selecting the Pro Mini in the IDE, did you also select the 8MHz version?  It just seems to me that if you were able to upload a sketch via the FTDI once, there's no reason why you couldn't do it again unless your IDE settings are different, or there's a bad connection.  Nothing would have changed the bootloader.

Yes, I'm familiar with this. I have plenty of pro-mini boards, both 8MHz and 16MHz. They use different baud rates depending on both the MHz and the type of bootloader installed on them. At this point I have MCUDdude "MiniCore" on all of them. There have been recent updates to both MiniCore and the Arduino IDE itself, so I'm in the process of confirming I have the most recent updates installed. I do need to install the latest Arduino IDE package (1.8.19) because I'm still using 1.8.9, which has worked perfectly until I got these new clone pro-mini boards. The PC is Windows 10.

What I find strange about these pro-mini clones is what happens immediately after using ICSP to erase flash and install a bootloader (this leaves low flash filled with 0xFF). At this point I can always load one sketch to the board with the bootloader. The sketch works fine, but afterwards the board fails to upload another sketch through its bootloader. Curiously the Arduino IDE “serial monitor” connection always works. Only failure is the bootloader stops working. I've been using the same FTDI USB-to-serial interface for everything. Perhaps it’s “reset out” pin has failed? I have several other USB-to-serial devices which I will try next. Sooner or later I will identify the "weak link."

One interesting discovery from today is that some of my 8MHz pro-mini boards (all Chinese clones) function perfectly when I use their 8MHz internal oscillator, but they fail to connect to the Arduino IDE when using their 8MHz resonator. I plan to activate the oscillator-out pin to measure actual clock frequency with my frequency counter. I'll use my ICSP programmer to change the clock fuses. I suspect the Chinese clone makers use the very cheapest resonators they can get. Most of my “Uno size” boards have actual crystals. But small boards (nano, pro-mini) have tiny resonators which may not be as accurate in frequency as crystals. I do have several 16MHz nano clones which always work perfectly even though their 16MHz comes from a resonator. I also have several SparkFun RedBoards (same form factor as UNO) with 16MHz resonators. They are totally reliable at all times, but then they aren't made out of the world's cheapest parts. Conclusion: Resonators aren't always "worse than crystals." 

[coromonadalix]

i had a sparkfun pro mini with a different bootloader they say,  you push the button and you have around 6 seconds to do something ?? 

witch i never got it to work,  put back an standard boot loader ...
and found out  about  some mega 328B vs 328P    they dont work the same, got refunded

[westfw]

What I find strange about these pro-mini clones is that if I use ICSP to erase flash and then install a bootloader, this leaves low flash is all empty (0xFF). At this point I can always load one sketch to the board through the bootloader.

There are two main reasons that this happens:

• No auto-reset circuit (or it's broken.)  A erased device with just the bootloader runs the bootloader and jumps to the "application", which is a string of near-nop 0xFFFF instructions.  Eventually (about 32k * 125ns), the FFFFs run out and the program counter loops around to the bootloader again.  So the bootloader runs over and over, ready to accept an upload.
• Fuses set incorrectly. If you install the bootloader manually (instead of using the "burn bootloader" Arduino tool), and don't set the fuses so that the chip knows it should start at the bootloader address in high memory, the chip with start running at 0x0, where there will be near-nop FFFFs that execute until the PC reaches the bootloader.  You get the same "bootloader runs over and over again" behavior, upside down.

In both cases, once you load a sketch, it's sitting there in what used to be a path of nops, and so it runs instead of eventually hitting the bootloader...

I don't recall whether the "pro mini" design(s) include the auto-reset feature.  I think the original pre-dated it, and the new "real" versions DO have it.  Clones ?   Who knows!

i had a sparkfun pro mini with a different bootloader they say,  you push the button and you have around 6 seconds to do something ??

That was the original atmegaboot behavior, back before they invented the auto-reset circuit.
One of the historical details I left out is that ATmegaBoot had the long timeout since it was designed to work with the manual reset, whereas Optiboot has an ~1s timeout, since it expects to operate with the auto-reset circuit.

[Peabody]

All the Pro Minis I've used have that auto reset circuit.  It has DTR tied to a series 0.1uF cap going to the reset pin of the processor, which also has a pullup resistor - 10K I believe.  That resets the processor, but only for a little while.  I would think the mostly likely cause of that not working is a bad DTR connection.

[elecdonia]

What I find strange about these pro-mini clones is that if I use ICSP to erase flash and then install a bootloader, this leaves low flash is all empty (0xFF). At this point I can always load one sketch to the board through the bootloader.

There are two main reasons that this happens:

• No auto-reset circuit (or it's broken.)  A erased device with just the bootloader runs the bootloader and jumps to the "application", which is a string of near-nop 0xFFFF instructions.  Eventually (about 32k * 125ns), the FFFFs run out and the program counter loops around to the bootloader again.  So the bootloader runs over and over, ready to accept an upload.
• Fuses set incorrectly. If you install the bootloader manually (instead of using the "burn bootloader" Arduino tool), and don't set the fuses so that the chip knows it should start at the bootloader address in high memory, the chip with start running at 0x0, where there will be near-nop FFFFs that execute until the PC reaches the bootloader.  You get the same "bootloader runs over and over again" behavior, upside down.

In both cases, once you load a sketch, it's sitting there in what used to be a path of nops, and so it runs instead of eventually hitting the bootloader...

OK. I will check both items: Auto reset circuit and fuse settings.

I am using the “burn bootloader” button in Arduino IDE to install the MiniCore bootloaders onto my pro-mini boards

I’m curious about bootloader baud rates: For boards operating at 8MHz the two “closest to ideal” baud rates appear to be 38.4k and 57.6k. When reading through the boards.txt file for MiniCore with ATmega328p, I discovered that it specifies 38.4k for “8MHz internal oscillator” but 57.6k for “8MHz crystal.”  I have some pro-mini boards where the bootloader is fully functional when using the 8MHz internal oscillator but fails with 8MHz crystal oscillator. Should 38.4k be used for both cases?

[elecdonia]

All the Pro Minis I've used have that auto reset circuit.  It has DTR tied to a series 0.1uF cap going to the reset pin of the processor, which also has a pullup resistor - 10K I believe.  That resets the processor, but only for a little while.  I would think the mostly likely cause of that not working is a bad DTR connection.

I suspect there is a potential issue with auto-reset when powering the target board with 5V.
The logic levels coming from most USB —> serial devices are 3V3.
However most USB-serial devices supply 5V power to the target board.

Here’s the issue: Their logic-high DTR output signal is still only 3V3.

If the MCU on the target board is receiving 5V power and the 10K pullup on the target board is also tied to 5V, then the reset pulse reaching the mega328P reset pin won’t drop all the way to 0V. It will drop only to about 1V7. This is too high to be considered an “officially valid” logic 0 level. The result could be that the MCU on the target board sometimes fails to reset.

This fault could be diagnosed by rewiring the USB-serial device so that the 5V power it provides connects to the “raw V” power input pin of the target board. Most target boards (pro-mini for example) have an onboard 3V3 regulator IC. Therefore running the 5V from the USB-serial device through the 3V3 regulator will ensure that the reset pulse drops all the way to 0V. All logic levels will be 3V3 in this case, and the MCU itself will also be operating at 3V3. This is OK for pro-mini boards operating at 8MHz.

I’ll test this.

[Peabody]

The FTDI USB to UART module that I use has a jumper to select 5V or 3.3V.  And that selection applies to the power going to the target device as well as Tx and DTR.  They're all 5V or all 3.3V.  I don't think the OP's Adafruit FTDI friend is as easily switchable, but there are solder blob selections on the bottom to accomplish the same thing.

But the levels issue wouldn't explain why flashing works once, but not again.

On my "3.3V" Pro Minis, I almost always select 5V on the module if the FTDI will be powering the Pro Mini during flashing.  The 328P works just fine at 5V, and flashing seems to go better at 5V (although there really should be no difference).

[elecdonia]

Problem solved: My USB-to-serial converters were not resetting my pro-mini boards.

This “failure-to-reset” is caused by insufficient voltage swing from the USB-serial converter DTR output pin: Its logic-high output voltage is <3.6V. It isn’t possible to raise this with a pull-up resistor because it is “driven” at both its high and low output voltage.

When the target device (pro-mini) is operating at 5V then the voltage reaching the MCU /reset pin fails to drop low enough to actually reset the MCU. I measure about 1.4V minimum at the lowest portion of the /reset pulse. However this needs to be <1V, preferably <500mV.

I will check my other USB-serial cables and breakout boards, but I don’t recall having any which actually generate full 5V logic-high levels at their outputs. All AVR devices can accommodate logic-high levels of 3.3V when powered at 5V. However, they do require the “logic-low” level to be <1V regardless of whether the power rail is 5V or 3.3V.

A quick fix for my pro-mini boards powered at 5V was to connect a 22k resistor from the /reset pin of the pro-mini board to ground. This reduces the logic-high voltage on the /reset pin from 5V to 3.5V. Therefore the existing series capacitor from DTR to /reset is able to generate a negative-going pulse which takes /reset all the way down to 0V.

This mod is not needed when the MCU on the pro-mini board is actually powered at 3.3V. However, the connectors on my USB-serial adaptors apply 5V directly to the MCU on my pro-mini boards. To use the internal 3.3V regulator on the pro-mini requires moving the 5V power source provided by the USB-serial device to the “V-ext” pin of the pro-mini. Doing this will change the power supply voltage for the MCU to 3.3V.

[elecdonia]

Is Optiboot the only popular Arduino IDE bootloader which “double-blinks” the onboard LED when it starts up after a reset?

[elecdonia]

The FTDI USB to UART module that I use has a jumper to select 5V or 3.3V.  And that selection applies to the power going to the target device as well as Tx and DTR.  They're all 5V or all 3.3V.

Could you please do us a favor and post the model# and photos of this USB-serial converter with switchable output voltages?
I want to get one.

[Peabody]

The FTDI USB to UART module that I use has a jumper to select 5V or 3.3V.  And that selection applies to the power going to the target device as well as Tx and DTR.  They're all 5V or all 3.3V.

Could you please do us a favor and post the model# and photos of this USB-serial converter with switchable output voltages?
I want to get one.

Sure.  Here's the one I use:

https://www.ebay.com/itm/295528212187

The yellow jumper switches everything between 3.3V and 5V.

But reading the Adafruit description of your FTDI "friend", it appears to have jumpers on the bottom that set the supply voltage and the I/O voltage.  You should set both the same voltage.  I would pick 5V.

Alternatively, you could not connect the Vcc line from the FTDI, and power the Pro Mini separately from a 3.3V supply.  Then the 3.3V DTR should work.

So the bootloader wasn't the problem at all.

[westfw]

Some of the Nano (and perhaps pro mini) clones/designs ended up with rather low-valued pull-up resistors on RESET (1k, rather than the 10k on an Uno.)  That might help explain your problem.

Is Optiboot the only popular Arduino IDE bootloader which “double-blinks” the onboard LED when it starts up after a reset?

I think they all blink the on-board LED.  If there is one.  Optiboot does a triple-blink, actually.  Number of blinks is a compile-time option.  There are LOTS of options:

Code: [Select]


optiboot>make help


 Option AVR_FREQ=<n>          - Clock rate of AVR CPU
 Option CUSTOM_VERSION=nn     - set a customer version number
 Option BAUD_RATE=nnnn        - set the bit rate for communications
 Option LED=B3                - set LED pin to particular port/bit
 Option LED_START_FLASHES=n   - set number of LED flashes when bootloader starts
 Option LED_DATA_FLASH=1      - flash the LED each time data is received.
 Option LED_START_ON=1        - Turn the LED on at bootload start
 Option BIGBOOT=1             - enable extra features up to 1kbytes
 Option SUPPORT_EEPROM=1      - Include code to read/write EEPROM
 Option SOFT_UART=1           - use a software (bit-banged) UART
 Option SOFTTX=B5             - pin for software UART xmit
 Option SOFTRX=B6             - pin for software UART receive
 Option SINGLESPEED=1         - do not use U2X mode on UART
 Option RS485=B0              - Pin for optional rs485 tx enable
 Option NO_APP_SPM=1          - disallow application call of do_spm
 Option OSCCAL_VALUE=nnn      - set set OSCCAL_VALUE in bootloader
 Option BOOT_ON_POR           - Run bootloader on power-on
 Option APP_ON_EXTR           - Run App on External Reset
 Option UART=n                - use UARTn for communications
 Option TIMEOUT=n             - set WDT to 1, 2, 4, or 8 seconds


[Peabody]

Problem solved: My USB-to-serial converters were not resetting my pro-mini boards.

This “failure-to-reset” is caused by insufficient voltage swing from the USB-serial converter DTR output pin: Its logic-high output voltage is <3.6V. It isn’t possible to raise this with a pull-up resistor because it is “driven” at both its high and low output voltage.

When the target device (pro-mini) is operating at 5V then the voltage reaching the MCU /reset pin fails to drop low enough to actually reset the MCU. I measure about 1.4V minimum at the lowest portion of the /reset pulse. However this needs to be <1V, preferably <500mV.

It's the series capacitor that gives this result.  When idle, the DTR side is at 3.6V, and the reset side is at 5V.  When DTR goes low, both sides of the cap instantaneously drop by 3.6V - that's the voltage drop on the DTR side.  So the reset side also drops by 3.6V, bringing the reset pin down to 1.4V, which isn't low enough to trigger the needed reset.   Both sides need to be at the same voltage, either 3.3V or 5V, so when DTR goes to ground, so does reset.  If the USB-to-UART adapter is providing 5V to Vcc, but only 3.3V on DTR, you could power the Arduino from some other 3.3V source.  But ideally the adapter should provide power and I/O at the same voltage.

[elecdonia]

Some of the Nano (and perhaps pro mini) clones/designs ended up with rather low-valued pull-up resistors on RESET (1k, rather than the 10k on an Uno.)  That might help explain your problem.

I’ll check that. I have plenty of boards ranging from brand new to 5 years old. So far I’ve seen only 10k pullup resisters on \reset.

I think they all blink the on-board LED.

This clue helped me identify my “target board fails to reset” issue. I saw no blinks at all, except after power-up or hitting reset button. However, the LED should blink each time Arduino IDE opens the USB interface port, for example when Arduino IDE starts it’s “upload sketch to target board” process. LED also blinks when Arduino IDE “serial monitor” starts up.

Optiboot does a triple-blink, actually.  Number of blinks is a compile-time option.  There are LOTS of options:

Yep, plenty of items can be customized. I’m using MCUDude MiniCore (in my opinion quite well documented and easy for me to understand). Now that I’ve beaten my hardware into submission I’ll be moving forward with re-learning how all of this works. I did a bunch of projects with “embedded Arduino” structure 4 years ago but my skills got a bit rusty. I’m rapidly getting back on track.

[elecdonia]

Problem solved:My USB-to-serial converters were not resetting my pro-mini boards.

It's the series capacitor that gives this result.  While idle DTR =3.6V and \reset =5V.  Then when DTR goes low, the series capacitor forces both both DTR and \reset to drop by 3.6V.  Therefore \reset drops to 1.4V, but this isn’t always low enough to trigger the required MCU reset. If both sides operate at same voltage (either 3.3V or 5V,) then everything works properly. Ideally the adapter should provide power and I/O at the same voltage.

For now all of my pro-mini boards operating at 5V are happy with the 27k resistor added between \reset and ground. Additionally I’ve ordered several USB-TTL adaptors which have 3.3/5V slide switches. I’m hoping that both the Vcc supplied to the target board and the logic levels match up for each position of the selector switch.

[elecdonia]

Could you please post model# and photos of USB-serial converter with switchable output voltages?

Sure.Here's the one I use:
https://www.ebay.com/itm/295528212187
The yellow jumper switches everything between 3.3V and 5V.

Thanks! I am ordering adaptors which look like that. And also another style which has a slide switch for selecting 3.3/5V.

Your “FTDI friend” has jumpers underneath to set supply and I/O voltages.  You should set both the same voltage.  I would pick 5V.

I’ll double check this. I haven’t yet altered its factory-default configuration which is 5V supply and 3.3V I/O. I don’t think it’s I/O voltage is adjustable, but I could be wrong about that. I’ll re-read the adafruit docs and look up the data sheet for the FTDI chip.

So the bootloader wasn't the problem at all.

Correct! This was strictly a hardware issue.

[Peabody]

Your “FTDI friend” has jumpers underneath to set supply and I/O voltages.  You should set both the same voltage.  I would pick 5V.

I’ll double check this. I haven’t yet altered its factory-default configuration which is 5V supply and 3.3V I/O. I don’t think it’s I/O voltage is adjustable, but I could be wrong about that. I’ll re-read the adafruit docs and look up the data sheet for the FTDI chip.

Yep.  See attached pic of the bottom side of the "friend".  Separate options for power and I/O.  Also RTS and DTR (I think either works).

[elecdonia]

Yep.  See attached pic of the bottom side of the "friend".  Separate options for power and I/O.  Also RTS and DTR (I think either works).

We are in sync! 

About an hour ago I took a very close look at my “FTDI friend” USB-TTL adaptor… and discovered that it does indeed have configuration pads on its PC board for selecting either 3.3V or 5V for “I/O logic level.” So I cut the tiny foil jumpering across the “3.3V” pads and put a blob of solder across the “5V” pads. Then I confirmed it is generating 5V logic signals. Next I tested my clone pro-mini boards with it: Now they are all “auto-resetting” properly without needing the extra 22k resistor from \reset to ground.

Previously I had used this same “FTDI friend” adaptor several times without major issues. But this time around it certainly didn’t play well with my new pro-mini boards. Evidently the other pro-mini boards I had 4 years ago worked OK with the out-of-spec \reset signal. Come to think of it I do have a vague recollection that “something” was occasionally flaky about it. But back then I was able to get it to work well enough that I didn’t do any troubleshooting.

FYI, the factory defaults on my FTDI friend were:
   Power voltage to target: 5V
   Logic levels: 3.3V
   RTS connected to \reset. (I’ve never had problems with RTS for \reset so I left this unchanged.)

For all of my current projects the 5V logic levels are totally OK. And now I know how to change it back to 3.3V if I ever need to upload to a target board which cannot handle 5V logic levels.

[Nominal Animal]

This is a common discussion re. Linux distributions ("there are too many Linux distributions") that I have adapted to this subject.
elecdonia, don't be offended, because Q does not refer to you!  This is just a stereotypical adaptation of an analogous subject I've had way too many times.

I only post this because it so well illustrates the problems in posing the kind of question you did, in the subject; and how important it is to ask questions well/precisely.

Q: Are there too many different bootloaders in the Arduino world?

A: No.

Q: But I got some Chinese ones that have really bad bootloaders!

A: That has nothing to do with how many different bootloaders there are.
    You should have asked, "Are some of the Arduino-compatible bootloaders utter crap?", if you wanted a Yes for an answer.

Q: But the world would be so much easier, if there were fewer bootloaders!

A: Each bootloader (except for the crappy ones and bad clones) works well for somebody, so what you are really asking is for others to take a hit so that your own life would be easier.
    It would be a different thing, if you asked for the crappy ones to be burninated with fire; that I would agree with for sure.

Q: No, that's not what I mean.  I mean, it would be better for everyone if there were fewer bootloaders.

A: No.  Each one was written for a purpose, and they work well for that purpose.  Each of them has happy users who do not want to switch.  You think things would be better for everyone, because they would be better for you, so you simply assume they would be better for everyone else too.  After all, it is easier to ask everyone else to change, than change yourself.

    Do you really have the experience to speak for everybody using Arduino?

Q: You're stupid and mean, go away.

A: Aye.

In particular, I myself only use Arduino-compatible microcontrollers with native USB interfaces.  I never use FTDI chips or any other serial-to-USB bridge chips, because I don't need them.  This means that my own bootloader needs are different than those who use microcontrollers without native USB.
I particularly like bootloaders that are exposed using a HID interface (rather than a USB serial interface as is more common), because the latter has all kinds of driver issues (especially on Windows), whereas the former never requires any drivers at all.  The downside with HID interface is the limited bandwidth, so uploading very large firmwares can take a few seconds.
There are some that prefer MTP or even USB Mass Storage interface (so that to upload a new firmware, one just copies the new firmware file to the disk drive the MCU exposes), but I like the HID interface for its simplicity.

[westfw]

Ob xkcd:

[Nominal Animal]

Ob xkcd:

Unvisible for me.  Assuming it is the one I guess it is, there are standards that need to be burninated with fire, and yet I don't think there are too many standards in the world.

[elecdonia]

To shed light on this “too many bootloaders?” question, the AVR device family is large. There are nearly 100 different devices in it. Not every device requires a different bootloader, but there certainly is a huge diversity of features, clock speeds, etc. which correlate to requiring numerous different (device-specific) “fuse” settings.

The “boards.txt” file largely automates the byzantine and confusing complexity of getting all of these items configured properly.

One thing which stands out in every forum discussing AVR devices is all the questions about programming, bootloaders, and proper fuse settings which are posed by new users. As a seasoned professional I’m still at a loss sometimes when I don’t seem to be able to get anything to work right.

Now that my programming hardware is finally working correctly I’ll be testing MiniCore with all the different AVR parts listed in its “boards.txt” file. Having used AVR devices myself since about 2002 I’m pretty sure I have at least one of every part # listed. This includes the really old ones like m8 and m88.

With the mega328 alone there are 3 distinct varieties: mega328, mega328P, and mega328PB. Each possesses considerably different features and internal peripherals.

This is why “boards.txt” has so many entries in it.

[elecdonia]

In particular, I myself only use Arduino-compatible microcontrollers with native USB interfaces.  I never use FTDI chips or any other serial-to-USB bridge chips, because I don't need them.  This means that my own bootloader needs are different than those who use microcontrollers without native USB.
I particularly like bootloaders that are exposed using a HID interface (rather than a USB serial interface as is more common), because the latter has all kinds of driver issues (especially on Windows), whereas the former never requires any drivers at all.

+100 on this.

I’ll take a close look at my bin of Arduino style boards. I probably have at least one board which is “HID.”

[westfw]

With the mega328 alone there are 3 distinct varieties: mega328, mega328P, and mega328PB. Each possesses considerably different features and internal peripherals.

Atmega328 and ATmega328P are essentially identical.  The only programming difference that anyone has found is that the P version permits the brown-out detection to be disabled by software (for lower sleep-mode power consumption.) (and a rather inexplicably different device signature.)  Atmel was ... not terribly logical with their naming standards (the PB should surely have been called something new.)
Microchip's new (?) AVRxxxDynnn looks more promising, actually.

Until miniCore came along, "recommended practice" for users who accidentally bought the non-P 328 chips for their Arduino projects was to burn the default ATmeag328p Optiboot. Since optiboot hardwires the device signature, thereafter the chip would identify itself (when using the bootloader) as a 328P, keeping Arduino happy without having to have explicit support for a different chip.

[westfw]

BTW, there's a new serial protocol aimed specifically at bootloading (the stk500 protocols were all intended to talk to hardware programmers), designed by Stefan Rueger (the author of avrdude.) This enables a bootloader even smaller than Optiboot (it no longer has to keep creating "fake" responses to some commands), or allows even more features to fit in 512 bytes.

I've thought something like this should exist for a long time, but it's one of those things where the people writing the host-side software (avrdude, in this case) had to buy into the idea first.

https://github.com/stefanrueger/urboot

[elecdonia]

The “P” in mega328P might be there because of the Atmel marketing department. The initial “P” stands for “pico power.” Even though earlier ancestors in the AVR family also had impressive “low-power” capabilities, Atmel really began marketing “ultra-low-power” with the 328P.

Then the 328PB came along. It is significantly different, beefed up with additional internal hardware, such as a second USART port. Some folks are unhappy that the 328PB no longer contains the “full swing crystal oscillator” option. They prefer the “full swing crystal oscillator” for applications in electrically noisy environments.

[elecdonia]

BTW, there's a new serial protocol aimed specifically at bootloading:
https://github.com/stefanrueger/urboot

Thanks! I took a quick look at GitHub. I like the concept and I will try it soon.
     Does it require adding a “programmer” entry (named urclock) to the Arduino IDE?

[westfw]

Does it require adding a “programmer” entry (named urclock) to the Arduino IDE?

The "programmer" field are used only for "upload using programmer" or "burn bootloader."  I suppose that that might be one way of trying out a new bootloader protocol (via the "upload using programmer.")  But normally I think you'd use new boardname.upload.* parameters in the boards.txt file.

[elecdonia]

Does it require adding a “programmer” entry (named urclock) to the Arduino IDE?

The "programmer" field are used only for "upload using programmer" or "burn bootloader."

I understand. The "programmer" for burning "urboot" into AVR chips will continue to be my "Arduino-as-ISP" device. I've used this method for years to upgrade bootloaders on Arduino-style boards and to program raw AVR devices. I've also used a ***real*** STK500 board, but the 2 of them I own are getting long-in-the-tooth (when did I buy those? 1998? 2001? Gosh, I even have an STK200. I have no idea when or how I ended up with that one!).

I recently picked up a nifty $4 USD Chinese "OPEN-SMART" shield. I parked it on top of a (clone) Arduino UNO, which runs the (slightly modified) "Arduino as ISP" sketch provided by the folks who created the OPEN-SMART board. The OPEN-SMART board has a buzzer and this modified sketch makes it beep at the end of a successful programming event.  I also added a 10uF capacitor from the UNO's RST pin to ground in order to protect the host UNO from auto-resetting. This prevents accidental uploads into the host UNO underneath the OPEN-SMART shield.

A cool feature of OPEN SMART is its ZIF socket for programming 28-pin DIP package AVR chips. I have plenty of 28-pin mega328P chips which I'm using on "Transistor Tester" boards. The "Transistor Tester" firmware doesn't use a bootloader, so I program those devices directly with AVRDUDE. I'm also setting up several other mega328P chips with MiniCore/Optiboot for other projects where the MCU is on my own board and I will be using the Arduino IDE for development/debugging. I should mention that I began writing code for AVR chips before the Arduino project existed. That was  with Atmel Studio and...  (groan ) ..writing code in assembly language. The target device was often an ATtiny13. It's hard to believe I did that 20 years ago...

At this time I'm still in the process of  setting up several Arduino-style boards with MiniCore/Optiboot and also putting it on some "bare" mega328P chips. At a later date I'll experiment with "urboot." 

[elecdonia]

Then your project will not have an Arduino bootloader and you will have to re-do all your Arduino work.

This is completely false.  The Arduino bootloaders are all completely separate and non-interacting with the user applications, whether they are "Arduino sketches" or programs written in some other development environment.  You can write Arduino sketches without using the bootloader (saves 0.5 to 8k of memory) (there's even an "upload using programmer" command), or you can use the Arduino bootloaders with non-Arduino applications.

    AVR chip with bootloader:

1) Good:   If the target board has a serial port then it can easily receive new firmware straight from the Arduino IDE or from a PC running AVRDUDE. Many of my applications already have a serial port for external communication. Therefore adding bootloader capability is "zero overhead" on the hardware side 
2) Bad:     Each time the target board powers up or resets there is a delay (~1 sec) before the application starts up. The bootloader always starts first, but then times out and runs the application after determining that it isn't connected to AVRDUDE
3) Could be an issue?  The bootloader reduces the amount of flash memory available to the application by 512 bytes

     AVR chip without bootloader:

1) Good: Application on target board starts up immediately after power-up or reset
2) Also good: All of the flash is available to the application
3) Also good: Arduino IDE can still be used for development/debugging via the "upload sketch with programmer" button in the Arduino IDE
4) Bad:   Firmware updates require a 6-pin ICSP header on the target board along with a cable connected to a programming device. This may be acceptable for applications which never (or rarely) require firmware updates.

[westfw]

2) Bad:     Each time the target board powers up or resets there is a delay (~1 sec) before the application starts up.

One of the modifications made to the bootloader very early in the development timeframe was the "Adafruit fast start" mod.  This detects the RESET cause, and only runs the bootloader for "external RESET signal", but NOT for power-on reset.  So there shouldn't be any start-up delay except when you actually use the reset button or Arduino auto-reset feature (any connection/change of parameters on the serial port.  Sigh.)

OTOH, I've seen AVRs be bit confused about their reset cause when powered on, depending on maybe PWR rise time, exactly what is connected to the RESET pin, and similar.  So if you're dependent on the fast startup, eliminating the bootloader is a good course of action.

[elecdonia]

2) Bad:     Each time the target board powers up or resets there is a delay (~1 sec) before the application starts up.

One of the modifications made to the bootloader very early in the development timeframe was the "Adafruit fast start" mod.  This detects the RESET cause, and only runs the bootloader for "external RESET signal", but NOT for power-on reset.  So there shouldn't be any start-up delay except when you actually use the reset button or Arduino auto-reset feature (any connection/change of parameters on the serial port.  Sigh.) OTOH, I've seen AVRs be bit confused about their reset cause when powered on, depending on maybe PWR rise time, exactly what is connected to the RESET pin, and similar.  So if you're dependent on the fast startup, eliminating the bootloader is a good course of action.

I have observed faster start-ups of my application code at power-up. Now I'll have to actually measure that...

That said, because a majority of my applications have a serial port connected to something else (such as a PC), I still must confront the issue of "what happens after the serial port hardware spits out an auto-reset pulse?"

But... (I'm a hardware guy) How about putting a simple spst switch somewhere on the target board which enables/disables auto-reset signal from reaching the MCU? Before uploading firmware the switch must be set the "bootloader enabled" position.

I'm already using this (in a way) on my "Arduino UNO as ISP" device. The 10uF cap I attached from the UNO reset pin to ground prevents the serial port auto-reset pulse from being detected by the MCU on the UNO board. I disconnect the 10uF cap if/when I need to upload a modified "Arduino as ISP" sketch to the UNO. Actually the capacitor can be as small as 1uF. It only needs to be 10x larger than the 100nF auto-reset capacitor to prevent the negative-going auto-reset pulse from getting detected as \reset by the MCU on the UNO board.   

[Doctorandus_P]

Re: Are there too many different bootloaders in the Arduino world?

Yes, there are far to many. Even a single one is one too many.
I never bothered using any of them, I just plug in a programmer and it always works. Regardless of modes, no silly states to enter boot loader mode, no waiting, no hangups. You just command the programmer to reset the uC and reprogram it and it does it. Always.

Bootloaders do have some limited use, for example for firmware updates in the field where a programmer is not always available, or when a mars rover on another planet has to receive a bug fix, but I quite despise the things for general development on your own desk.

[westfw]

How about putting a simple spst switch somewhere on the target board which enables/disables auto-reset signal from reaching the MCU?

Sure.  The oldest Arduinos didn't have the auto-reset feature at all, and users had to manually hit the reset button before they did an upload.  That was when the timeout was closer to 10s, though.  If you want to operate that way, you should probably rebuild the bootloader for a longer-than-1s timeout.


The "megaTinyCore" (tiny-0/1/2) bootloader added a feature that runs the other way - ONLY run the bootloader at poweron.  That's because the limited pin count would otherwise require you to give up a GPIO pin for the RESET function.

I just plug in a programmer and it always works.

Always?  Never tried to ISP program a chip that was in DEBUGWIRE mode?  Never had conflicting hardware on the ISP pins?  Never found out that the new chip you were planning on using needs HVSP or TPI or PDI that your programmer doesn't support?  Never mis-programmed your  fuses and now you need HVPP or an external clock to recover?

[Siwastaja]

Besides, bootloaders are mystified for no reason. If one is capable of writing a non-trivial (more than led blinker) firmware, they surely are capable of writing their own bootloader. The reason to do is exactly the same why we write our own software and firmware at all - to get exactly the functionality we need.

This is also why so many exist, and why some are so crappy - they are easy throwaway projects. If you feel like you need a bootloader and can't easily find something suitable, maybe just write your own.

[elecdonia]

The oldest Arduinos didn't have the auto-reset feature at all, and users had to manually hit the reset button before they did an upload.  That was when the timeout was closer to 10s, though.  If you want to operate that way, you should probably rebuild the bootloader for a longer-than-1s timeout.

Yes, I'm familiar with adjusting the length of the bootloader timeout. That said, I want my finished projects to start up as fast as possible after reset or power-up. I think I will place a 2-pin header on my boards where "enable bootloader" requires shorting these pins with a jumper. I don't expect end-users to upload new firmware very often, but I do wish to make this possible. 

The "megaTinyCore" (tiny-0/1/2) bootloader added a feature that runs the other way - ONLY run the bootloader at poweron.  That's because the limited pin count would otherwise require you to give up a GPIO pin for the RESET function.

This is good to know. I haven't recently used any Tiny AVR but I fully agree that conserving every possible GPIO pin is a priority. In the past I mainly programmed Tiny devices with ICSP. I don't foresee many Tiny AVR projects where I would wish to have a bootloader on them. One of my designs with ATtiny13 is still in mass-production by my former employer with 12-year old firmware which still functions perfectly. It does require every available GPIO pin, so reset was always disabled. It does not contain a bootloader.

On a related topic I've been bashing my "OPEN-SMART" (clone) ISP-programmer shield intensively. I did some mods to the shield which I will fully document after more testing.

My first mod was to prevent the UNO board (underneath the OPEN-SMART shield) from processing reset commands received from its USB serial port. This was done by placing a 10uF capacitor from UNO board reset to ground. This isn't strictly necessary because the standard "Arduino-as-ISP" driver sketch operates at 19.2k baud vs. the 115k baud UNO board bootloader. But when I was "playing around" with serial port speeds (running everything at 115k) I accidently uploaded a sketch intended for the target AVR into the UNO board. Because I dedicated this particular UNO board to permanent "Arduino-as-ISP" duty I decided to disable its bootloader via hardware.

My second mod relates to using the 6-pin header on the OPEN-SMART shield to connect a USB-TTL adaptor such as "FTDI-friend." This permits uploading sketches into a target AVR installed in the ZIF socket (naturally this works only after installing the bootloader into the target AVR device). It's not likely to get used by most people. But the OPEN-SMART folks built their shield with this feature so I decided to try using it. One important part was missing: The 10k pullup resistor from the target AVR reset pin to +5V. The OPEN-SMART shield comes with the standard 100nF capacitor from DTR to reset. But without the 10k pullup resistor it barely works. With the 10k resistor it works great.

Mod number 3 is adding an LED and series resistor to the "LED-pin" (aka D13) of the target AVR in the ZIF socket. Other small Arduino boards (pro-mini) have this LED. I like having it because it "double-blinks" after reset/power-up, confirming the bootloader started up. It also permits running the standard Arduino "blink" sketch.       

[elecdonia]

With my OPEN-SMART AVR programming shield fully functioning I’m checking out all the 28-pin DIP AVR chips in my hoard of MCU devices.  I have ATmega 328P, mega8, mega88, mega48, and maybe some other ones. With jumper wires running to a 40-pin socket on a breadboard I’m also testing 40-PIN DIP parts like the mega644 and mega1281.

     People might ask “Why are you tinkering with all these old DIP-package parts?”

The answer is that I’m primarily a hardware guy. I’m very comfortable working with “through-hole” construction, especially for one-off hand-built projects, having made things that way since the 1970’s. Also I have plenty of these older AVR parts on hand because I’ve been using them since the year 2001 or so.

My routine is to put Optiboot on these bare AVR chips.
I’m setting their fuses for 8MHz internal clock oscillator. For me this always seems to work fine with a 38.4k serial port rate, which is fast enough for the projects I’m developing at the moment.
I also adjust fuses for “EEPROM data preserved” and “application can read (only) from boot area.”
(I edited a few lines in the appropriate boards.txt files to automate this for the AVR part numbers I’m using.)

After installing optiboot then I access the target devices through the serial port via the old-style Arduino IDE (v1.8.9 I think), and for “board” I’m using the appropriate core from MCUdude.

Next I run this “FuseBytes” sketch to double-check that all the fuses are exactly the way I want them to be:
   https://github.com/WestfW/fusebytes
(Note who the the author is: Thanks!)

[westfw]

Next I run this “FuseBytes” sketch to double-check that all the fuses are exactly the way I want

I don't think "FuseBytes" handles all the different chips you are using.  But it's been a long time since I looked at it.

[elecdonia]

Next I run this “FuseBytes” sketch to double-check that all the fuses are exactly the way I want

I don't think "FuseBytes" handles all the different chips you are using.  But it's been a long time since I looked at it.

I’m adding them as I go. While doing this I’m gaining an understanding of the structure of the fusebytes sketch and the internal structure of the AVR device itself. There aren’t a lot of other “example” Arduino sketches out there which show how to read from “special” AVR data storage locations such as the signature, fuses, and lock settings.

Also most of my projects use text-based serial communication, preferably in human-readable formats. So I’m always looking for apps like fusebytes to study and adapt the concepts to the code I’m writing.

Yet another reason I’m doing this is to refresh my understanding of the AVR device fuse parameters themselves and how/when to use different settings. Getting them right can challenge even an experienced hardware/software engineer. I can see why so many newbies hit a brick wall, especially when trying to get bare factory-fresh AVR devices set up and working with the bootloader for the first time.

[westfw]

Quote

how to read from “special” AVR data storage locations

You might be entertained by looking at the undocumented fuse memory locations as well.  Rumor has it that they might contain additional info similar to the "unique identifier" fields that are documented in some of the later devices (XMega, 328pb)...
https://www.avrfreaks.net/s/topic/a5C3l000000UTRvEAO/t126997

PS:

I’m adding them as I go.

excellent!  I always hope when I write those little "examples", that people will be able to use them as examples and expand upon them as needed.  Sadly, that doesn't happen that often in the Arduino world; too many users are ... well, USERS...

Consider submitting a pull request, diffs, or your updated version...

[elecdonia]

Question:
I'm testing an ATmega88. It doesn't support reading its device signature from application flash. This is because of a hardware difference: The mega88 doesn't have a "SIGRD" bit in the in its SPMCSR register.

Therefore apps like FuseBytes are incapable of reading the mega88 signature.

However, when I connect AVRDUDE to a mega88 equipped with optiboot through a serial-TTL converter, AVRDUDE is able to obtain the correct device signature. Is this black magic    or clever coding? 

I read somewhere that optiboot "hard codes" the device signature rather than actually reading it from the target device.

I may have confirmed this: I looked at binary dumps of optiboot 7.0 hex files for mega88, mega168, mega328, and their -p and -pb cousins, I discovered different values at offsets 0x15E and 0x162. It appears that the low-order 4 bits of each location are used to encode single hex digits of appropriate signature data. (This seems efficient: no wasted space at all. Just the bare minimum amount of data)

This makes me curious about several things:
     Why was it necessary to embed the device signature into optiboot?
     Is the device signature hard-coded into all optiboot binaries, or do some of them actually read the signature from the target AVR?
     How does optiboot deliver this signature information in proper STK500 format to AVRDUDE?
     I looked at boot.h and optiboot_flash.c but I don't understand how this works yet.

I must say I'm impressed that optiboot works with such a large family of different AVR devices, old and new. The effort put forth to get all of these devices working with optiboot must have been considerable. Three cheers! 

[elecdonia]

I discovered some ATmega48 devices in my IC chip archives. Mfg date is 2005.

I was disappointed that MiniCore says: "no bootloader" for the mega48. Then when I read the Atmel datasheet I realized the mega48 doesn't have a dedicated boot area or a fuse bit to vector a reset to the boot section. Perhaps bootloaders don't exist for such small devices? Why would they be needed anyway?

Otherwise, MiniCore does a nice job of supporting the ATmega48 in the Arduino IDE. One just needs to remember to use "upload sketch through programmer."
I installed and ran the plain old "blink" sketch, although at first it ran waaaaaayyy   tooooooo slowwwwwww.
That's because I didn't realize the Arduino IDE "burn bootloader" procedure must be used to configure the ATmega48 fuses.
   After all, why should one perform the "burn bootloader" procedure when a bootloader for this device doesn't even exist?

After running "burn bootloader" with proper clock frequency parameters everything works great. The LED blinks once per second at 16, 8, or 1MHz. The original "very slow" blinking was because all AVR devices come from the factory configured for 1MHz internal clock.

Now I'm looking for interesting sketches which will fit into 4K of flash...

[westfw]

I'm testing an ATmega88. It doesn't support reading its device signature from application flash. This is because of a hardware difference: The mega88 doesn't have a "SIGRD" bit in the in its SPMCSR register.

Wow.  Is in an actual ATmega88, rather than an ATmega88A, ATmega88P, or ATmega88PA?What happens if you compile with one of those other processor types specified, or simply define SIGRD as 5?

     Why was it necessary to embed the device signature into optiboot?

I believe the original reasoning was that it saves space.  Load a value into a register and send it, vs load a code into SPMCSR, load an address into X, do the SPM instruction, and send it.
With the 328 vs 328P fiasco, it became useful for the bootloader to "lie" to avrdude/ArduinoIDE.

     Is the device signature hard-coded into all optiboot binaries, or do some of them actually read the signature from the target AVR?

It's hard-coded into all of them.  Maybe not optiboot-X.

     How does optiboot deliver this signature information in proper STK500 format to AVRDUDE?

It detects when avrdude does a "signature read" command , and sends the bytes.  There isn't much to "stk500v1"

Code: [Select]

/* Get device signature bytes  */
    else if (ch == STK_READ_SIGN) {
      // READ SIGN - return what Avrdude wants to hear
      verifySpace();
      putch(SIGNATURE_0);
      putch(SIGNATURE_1);
      putch(SIGNATURE_2);
    }
This assembles to "LDI r24, 0xNN" followed by "RCALL putch"; probably the reason that you see nybbles rather than full byte values in the hex dump is that the AVR instruction set encoding for LDI is a bit weird:

The effort put forth to get all of these devices working with optiboot must have been considerable.

Well, it's been a lot of years, and a lot of people helped.  Sometimes I feel like my main function as "optiboot maintainer" has been to hold back new features, rather than add them.  (after all, Arduino itself is doing fine with optiboot source that supports far fewer parts.)

[elecdonia]

Wow.  Is it an actual ATmega88?

Yes it is. I have a big stash of AVR devices with mfg. dates as far back as 2001. The "V" suffix on the chip's label indicates this is the "low-voltage" version of the ATmega88.

What happens if you compile with one of those other processor types specified, or simply define SIGRD as 5?

Defining SIGRD in the FuseBytes sketch allows the sketch to compile and load. However, the data returned by boot_signature_byte_get(x) isn't the signature data. I'll attempt to identify where the returned data actually comes from. Also I intend to search the sources for the AVR core and system libraries to learn where these obscure system function names like "boot_signature_byte_get(x)" are defined.

It detects when avrdude does a "signature read" command , and sends the bytes.  There isn't much to "stk500v1"

Code: [Select]

/* Get device signature bytes  */
    else if (ch == STK_READ_SIGN) {
      // READ SIGN - return what Avrdude wants to hear
      verifySpace();
      putch(SIGNATURE_0);
      putch(SIGNATURE_1);
      putch(SIGNATURE_2);
    }
This assembles to "LDI r24, 0xNN" followed by "RCALL putch"; probably the reason that you see nibbles rather than full byte values in the hex dump is that the AVR instruction set encoding for LDI is a bit weird.

So where are the specific argument values for "SIGNATURE_x" defined?
For the ATmega88 these values are 0x1E 0x93 0x0A.
I'll try searching the src, make, boot.h files, etc. for symbols containing "SIGNATURE"

[elecdonia]

This assembles compiles to "LDI r24, 0xNN" followed by "RCALL putch"; probably the reason that you see nibbles rather than full byte values in the hex dump is that the AVR instruction set encoding for LDI is a bit weird:

The second byte of the mega88 signature is 0x93.    LDI r24, 0x93 assembles into the following 16 bits of raw machine code: 0xE983

That is odd!

The LDI instruction copies an 8-bit constant from flash into a register. This part is simple.
I wonder why they separated the argument (an 8-bit constant) into two nibbles with the 4 bits for the destination register located in the middle?
Perhaps this allows the LDI instruction to execute in fewer clock cycles?
Internal MCU hardware logic design is a specialty of which I know very little.

But then there is this person who scratch-built a functional CPU where the logical functions are performed by relays:
(Note that memory and IO are constructed with logic chips. Only the actual "processor" section is made from relays)

[elecdonia]

The second byte of the mega88 signature is 0x93.
LDI r24, 0x93 assembles into the following 16 bits of raw machine code: 0xE983

One related point:

In flash memory AVR device 16-bit opcodes are arranged in “little endian” fashion.
Therefore a “byte by byte” sequential flash memory dump displays the 0xE983 op code as:

0x83E9

[fastbike]

My end products will likely contain “bare metal” AVR devices, but I’m not starting out that way.

Then your project will not have an Arduino bootloader and you will have to re-do all your Arduino work. If you want to go bare metal, start bare metal. This will save you lots of time and effort.

That's not the reality of using Arduino. I successfully use it to target ARM0 devices without a bootloader.

[elecdonia]

Next I run this “FuseBytes” sketch to double-check that all the fuses are exactly the way I want

I don't think "FuseBytes" handles all the different chips you are using.

This is correct. I'm adding all the AVR parts I have on hand and will additionally add other popular AVR chips.

I'm learning a great deal from reviewing the Atmel/Microchip datasheets. Some AVR parts have 16 different clock options:

External or internal clock source
RC oscillator (usually internal to the MCU chip, but some AVR devices support placing the R and C on the PC board)
A configuration expressly for using tiny 32kHz cylindrical watch crystals
Ceramic resonator or quartz crystal
"Full-swing" or "Low-power" oscillator modes for quartz crystal or ceramic resonator
Several different frequency ranges for the “Low-power” oscillator mode: 0.4-0.9MHz, 1-3MHz, 3-8MHz, 8-16MHz. The “Low-power” oscillator mode consumes even less power when a lower frequency range is selected. I intend to compare 3-8MHz to 8-16MHz while using an 8MHz crystal or resonator.

The official docs are rather complex (to say the least).

Several options are recommended only when using a ceramic resonator.
 
The reason for this is that actual quartz crystals stabilize very slowly after power-up. Their "Q" is so high that it requires 16,000 up to 32,000 clock cycles after power-up before the clock signal builds up to the proper amplitude and becomes fully stable.

Ceramic resonators have lower "Q" and achieve the proper amplitude and stability about 10 times faster than quartz crystals. This makes ceramic resonators preferable for applications which must start up very quickly after power-up.

RC oscillators are the fastest of all in terms of "start-up" times.

The fuse settings settings seen in Arduino "boards.txt" files generally use the slowest start-up settings.
 

[westfw]

Several AVR parts have as many as 16 different clock options

I count 4 bits of "oscillator type", 2 bits of "Start up time", plus the ClkDiv8 fuse, the prescaler register, and the OSCCAL register for adjusting the internal oscillator.  (8MHz is "nominal", but you could adjust it to something more appropriate for your actual application if you want. (8MHz isn't particularly great for standard baud rates, for instance.)

[/size]actual [/size]quartz crystals[/size] stabilize very slowly

Sometimes I wonder how important that "stabilization" is.  Presumably any oscillation is fine up until you need something that is actually speed critical, and you could do your own stabilization timing in software.  OTOH, it seems to be pretty rare to require startup less than the ~70ms of the default Arduino settings.  Might be important for extreme low-power applications, since it applies to wakeup from sleep modes as well, and 65ms waiting for the crystal to be "stable" seems like quite a waste.


The newer AVRs (mega0, "xtiny", AVR-D*) let you switch clock configurations from software...

[elecdonia]

I count 4 bits of "oscillator type", 2 bits of "Start up time"

"Oscillator type" (4 bits) and "startup time" (2 bits) both influence how much time the AVR device requires to begin functioning after applying power.
Additionally "oscillator type" specifies the amplitude of oscillation for ceramic resonators and quartz crystals. The amount of power consumed by the clock oscillator itself is important for extreme "pico-power" applications. Therefore adjustable clock oscillator amplitude is a useful feature.

• "Oscillator type" specifies how many clock cycles must occur between "power-up" and "normal operation." This also applies after exiting the "power save" state. Typical values are 258, 1k, or 16k clock cycles. Example: 16k clock cycles with 8MHz clock is 2msec.
• Data in the 2 bits of "startup time" specifies the additional delay which occurs after any form of "reset," with typical values of "14 clock cycles +  0, 4.1, or 65msec."

8MHz is "nominal", but you could adjust it to something more appropriate for your actual application if you want. (8MHz isn't particularly great for standard baud rates, for instance.)

A majority of mass-produced Arduino-compatible boards with AVR MCU operate at 16 MHz. The actual "frequency determining device" is either a ceramic resonator or a quartz crystal.

I frequently use the "8MHz calibrated internal RC oscillator" in my projects. 8MHz provides a perfect 38.4k baud rate. It isn't terrible at 57.6k either. Unfortunately it is very much "out-of-spec" at 115.2k baud. I use 38.4k baud for my 8MHz projects. So far I've always obtained error-free 38.4k baud serial communication without readjusting the factory-default oscillator calibration.

Sometimes I wonder how important that "stabilization" is.  Presumably any oscillation is fine up until you need something that is actually speed critical, and you could do your own stabilization timing in software.  OTOH, it seems to be pretty rare to require startup less than the ~70ms of the default Arduino settings.  Might be important for extreme low-power applications, since it applies to wakeup from sleep modes as well, and 65ms waiting for the crystal to be "stable" seems like quite a waste.

The newer AVRs (mega0, "xtiny", AVR-D*) let you switch clock configurations from software...

Good points! It's likely that Atmel was considering extreme temperatures and power supply instability when formulating their recommended start-up times.

[westfw]

I frequently use the "8MHz calibrated internal RC oscillator" in my projects. 8MHz provides a perfect 38.4k baud rate. It isn't terrible at 57.6k either. Unfortunately it is very much "out-of-spec" at 115.2k baud.

Sure, but 7.5MHz or 9.1MHz would hit more of the standard rates.
I think TI's MSP430 made big inroads on average current consumption by tuning an internal clock from a crystal (DFLL?) and being able to start up REALLY QUICK from power-down modes.  "Wakeup in 6us..."

[elecdonia]

I think TI's MSP430 made big inroads on average current consumption by tuning an internal clock from a crystal (DFLL?) and being able to start up REALLY QUICK from power-down modes.  "Wakeup in 6us...

I worked on a project containing the MSP430 for my former employer ~10 years ago. The IDE we used was costly (IIRC it was "IAR embedded workbench"), but I didn't have to pay for it myself. In contrast the associated TI device programming hardware for the MSP430 wasn't terribly costly. 

I fully agree that MSP430 excels for extremely low-power applications.

[elecdonia]

You might be entertained by looking at the undocumented fuse memory locations as well.  Rumor has it that they might contain additional info similar to the "unique identifier" fields that are documented in some of the later devices (XMega, 328pb)...
     https://www.avrfreaks.net/s/topic/a5C3l000000UTRvEAO/t126997

That's fascinating. I've been reading another discussion of undocumented locations in the AVR signature area.

This appeared in a discussion about (clone) Arduino pro-mini boards which were found to have sleep currents many times higher (150uA) than what was expected (~1uA):

     https://www.eevblog.com/forum/microcontrollers/arduino-pro-mini-two-copies-have-different-sleep-currents/msg3233760/#msg3233760

[elecdonia]

Next I run this “FuseBytes” sketch to double-check that all the fuses are exactly the way I want

I don't think "FuseBytes" handles all the different chips you are using.  But it's been a long time since I looked at it.

After working with this FuseBytes sketch and testing it with a whole bunch of different AVR devices (ATmega328P, ATmega644, ATmega1284, ATmega2560) I've learned a great deal about how to use the compiler directives such as    #if defined( ... ),    #else if defined( ... ), and    #endif   to get the sketch to compile appropriately for specific AVR types. There's nothing better than studying "well designed" code! Just my opinion...

I even managed to create a "small" version of FuseBytes which runs on mega48, mega8, and mega88. There probably isn't much demand for such small devices these days, but because I have tubes full of them I went ahead and tested/modified FuseBytes so that it could be used with them.

My AVR device collection dates back to several projects I did between 2000 and 2010. These mostly started with PIC devices but I soon grew tired of writing PIC code in assembler and frequently getting caught by the strange way some of the PIC devices "segmented" their program memory with hardware "bank select" register bits.           
I soon grew fond of the AVR architecture which fit my needs perfectly.       For years I wrote my AVR code in assembler too (until the Arduino project happened).

[elecdonia]

I now have an answer this topic's title question:

Optiboot is the best choice among all popular bootloaders for Arduino on Atmel AVR devices

It doesn't surprise me that most of the AVR-based Arduino boards come with optiboot bootloaders already installed.

[elecdonia]

After working with this FuseBytes sketch and testing it with a whole bunch of different AVR devices (ATmega328P, ATmega644, ATmega1284, ATmega2560) I've learned a great deal about how to use the compiler directives such as    #if defined( ... ),    #else if defined( ... ), and    #endif  to get the sketch to compile appropriately for specific AVR types. I even managed to create a "small" version of FuseBytes which runs on mega48, mega8, and mega88.

So I’ve continued developing and expanding FuseBytes.

Latest addition is a menu providing an in-depth full page view for each AVR fuse (low, high, extended, and lock). I developed a function which displays all of the possible options for configuring each fuse. This started as an informal way for me to test my edits of the original sketch, confirming that the output was correct for each and every fuse bit. Then I delved into using compiler directives to simulate the fuses of a different AVR device than the device actually running the sketch. I expanded the “bootloader details” to provide a complete hex dump of the bootloader. This is user controlled - it can display from one line (16 words, 32 bytes) up to the entire bootloader. The "code" section and attached .txt file shows the output as displayed in the Arduino serial monitor.

I’m gradually creating a flexible but simple menu system which may grow into a full command line interpreter. I need this for the projects I’m developing. I haven’t yet found any ready-to-use menu or CLI sketches which do what I want them to do.

Code: [Select]

Board ID:  328-P1 Ver: 230329-01 Compiled for ATmega328P

Signature:  1E 95 0F ATmega328P

Fuses:  E2 D6 FD   (L, H, E)      Lock:  EF      OscCal:  88

Low:  11100010 (0xE2)
      ||||++++_______ 8MHz calibrated internal RC oscillator
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

High: 11010110 (0xD6)
      |||||||+_______ Reset starts bootloader
      |||||++________ Bootloader size: 512 bytes
      ||||+__________ EEPROM saved during programming
      |||+___________ Watchdog timer programmable
      ||+____________ ISP programming enabled
      |+_____________ DebugWire disabled
      +______________ Reset pin enabled

Extended: 11111101 (0xFD)
          |||||+++_______ BOD: 2.7V

Lock: 11101111 (0xEF)
      ||||||++_______ ISP programming: R/W flash & EEPROM
      ||||++_________ Bootloader: R/W app flash
      ||++___________ App: Read only from boot flash

Bootloader detail:
  Optiboot ver:  8.0
  Size:          512 bytes (256 words)
  Start address: 0x7E00
Bootloader code displayed as AVR opcodes (little endian):
C001 C0B7 2411 B784 E890 9390 0061 9210 0061 2388 F061 2F98 709A 3092 F041 FF81
C002 EF97 BF94 2E28 E080 D0C6 C0E9 E085 9380 0081 E082 9380 00C0 E188 9380 00C1


_______________________________________________________________________________

        Show current fuse configuration:
f - Summary
d - Details

Show all available options for:
l - low fuse
h - high fuse
e - extended fuse
k - lock fuse

i - Show board ID
w - Write board ID
s - Show AVR MCU signature

b - Analyze bootloader
x - Toggle built-in LED
r - Show all info
? - Show this menu


_______________________________________________________________________________

Show all low fuse options
                        Clock options:
Low:  11100000 (0xE0)
      ||||++++_______ External clock source
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11100001 (0xE1)
      ||||++++_______ Reserved
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11100010 (0xE2)
      ||||++++_______ 8MHz calibrated internal RC oscillator
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11100011 (0xE3)
      ||||++++_______ 128kHz internal RC oscillator
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11100100 (0xE4)
      ||||++++_______ 32kHz LF watch crystal (fast start)
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11100101 (0xE5)
      ||||++++_______ 32kHz LF watch crystal (slow start)
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11100110 (0xE6)
      ||||++++_______ Full-swing ceramic resonator (fast start)
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11100111 (0xE7)
      ||||++++_______ Full-swing crystal or resonator (slow start)
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11101000 (0xE8)
      ||||++++_______ 0.4-0.9MHz LP ceramic resonator (fast start)
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11101001 (0xE9)
      ||||++++_______ 0.4-0.9MHz LP ceramic resonator (slow start)
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11101010 (0xEA)
      ||||++++_______ 1-3MHz LP ceramic resonator (fast start)
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11101011 (0xEB)
      ||||++++_______ 1-3MHz LP crystal or resonator (slow start)
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11101100 (0xEC)
      ||||++++_______ 3-8MHz LP ceramic resonator (fast start)
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11101101 (0xED)
      ||||++++_______ 3-8MHz LP crystal or resonator (slow start)
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11101110 (0xEE)
      ||||++++_______ 8-16MHz LP ceramic resonator (fast start)
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11101111 (0xEF)
      ||||++++_______ 8-16MHz LP crystal or resonator (slow start)
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

                        Startup delay:
Low:  11000010 (0xC2)
      ||||++++_______ 8MHz calibrated internal RC oscillator
      ||++___________ Startup delay: 0b00
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11010010 (0xD2)
      ||||++++_______ 8MHz calibrated internal RC oscillator
      ||++___________ Startup delay: 0b01
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11100010 (0xE2)
      ||||++++_______ 8MHz calibrated internal RC oscillator
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  11110010 (0xF2)
      ||||++++_______ 8MHz calibrated internal RC oscillator
      ||++___________ Startup delay: 0b11
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

                        Clock output:
Low:  11100010 (0xE2)
      ||||++++_______ 8MHz calibrated internal RC oscillator
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  10100010 (0xA2)
      ||||++++_______ 8MHz calibrated internal RC oscillator
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin enabled
      +______________ Clock frequency divider: 1/1

                        Clock frequency divider:
Low:  11100010 (0xE2)
      ||||++++_______ 8MHz calibrated internal RC oscillator
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/1

Low:  01100010 (0x62)
      ||||++++_______ 8MHz calibrated internal RC oscillator
      ||++___________ Startup delay: 0b10
      |+_____________ Clock output pin disabled
      +______________ Clock frequency divider: 1/8


_______________________________________________________________________________

Show all high fuse options:
                        Reset vector:
High: 11010111 (0xD7)
      |||||||+_______ Reset starts application
      |||||++________ Bootloader size: 512 bytes
      ||||+__________ EEPROM saved during programming
      |||+___________ Watchdog timer programmable
      ||+____________ ISP programming enabled
      |+_____________ DebugWire disabled
      +______________ Reset pin enabled

High: 11010110 (0xD6)
      |||||||+_______ Reset starts bootloader
      |||||++________ Bootloader size: 512 bytes
      ||||+__________ EEPROM saved during programming
      |||+___________ Watchdog timer programmable
      ||+____________ ISP programming enabled
      |+_____________ DebugWire disabled
      +______________ Reset pin enabled

                        Bootloader size:
High: 11010110 (0xD6)
      |||||||+_______ Reset starts bootloader
      |||||++________ Bootloader size: 512 bytes
      ||||+__________ EEPROM saved during programming
      |||+___________ Watchdog timer programmable
      ||+____________ ISP programming enabled
      |+_____________ DebugWire disabled
      +______________ Reset pin enabled

High: 11010100 (0xD4)
      |||||||+_______ Reset starts bootloader
      |||||++________ Bootloader size: 1k bytes
      ||||+__________ EEPROM saved during programming
      |||+___________ Watchdog timer programmable
      ||+____________ ISP programming enabled
      |+_____________ DebugWire disabled
      +______________ Reset pin enabled

High: 11010010 (0xD2)
      |||||||+_______ Reset starts bootloader
      |||||++________ Bootloader size: 2k bytes
      ||||+__________ EEPROM saved during programming
      |||+___________ Watchdog timer programmable
      ||+____________ ISP programming enabled
      |+_____________ DebugWire disabled
      +______________ Reset pin enabled

High: 11010000 (0xD0)
      |||||||+_______ Reset starts bootloader
      |||||++________ Bootloader size: 4k bytes
      ||||+__________ EEPROM saved during programming
      |||+___________ Watchdog timer programmable
      ||+____________ ISP programming enabled
      |+_____________ DebugWire disabled
      +______________ Reset pin enabled

                        EEPROM retention:
High: 11011110 (0xDE)
      |||||||+_______ Reset starts bootloader
      |||||++________ Bootloader size: 512 bytes
      ||||+__________ EEPROM erased during programming
      |||+___________ Watchdog timer programmable
      ||+____________ ISP programming enabled
      |+_____________ DebugWire disabled
      +______________ Reset pin enabled

High: 11010110 (0xD6)
      |||||||+_______ Reset starts bootloader
      |||||++________ Bootloader size: 512 bytes
      ||||+__________ EEPROM saved during programming
      |||+___________ Watchdog timer programmable
      ||+____________ ISP programming enabled
      |+_____________ DebugWire disabled
      +______________ Reset pin enabled

                        Watchdog timer:
High: 11010110 (0xD6)
      |||||||+_______ Reset starts bootloader
      |||||++________ Bootloader size: 512 bytes
      ||||+__________ EEPROM saved during programming
      |||+___________ Watchdog timer programmable
      ||+____________ ISP programming enabled
      |+_____________ DebugWire disabled
      +______________ Reset pin enabled

High: 11000110 (0xC6)
      |||||||+_______ Reset starts bootloader
      |||||++________ Bootloader size: 512 bytes
      ||||+__________ EEPROM saved during programming
      |||+___________ Watchdog timer always on
      ||+____________ ISP programming enabled
      |+_____________ DebugWire disabled
      +______________ Reset pin enabled

                        ISP programming:
High: 11110110 (0xF6)
      |||||||+_______ Reset starts bootloader
      |||||++________ Bootloader size: 512 bytes
      ||||+__________ EEPROM saved during programming
      |||+___________ Watchdog timer programmable
      ||+____________ ISP programming disabled
      |+_____________ DebugWire disabled
      +______________ Reset pin enabled

High: 11010110 (0xD6)
      |||||||+_______ Reset starts bootloader
      |||||++________ Bootloader size: 512 bytes
      ||||+__________ EEPROM saved during programming
      |||+___________ Watchdog timer programmable
      ||+____________ ISP programming enabled
      |+_____________ DebugWire disabled
      +______________ Reset pin enabled

                        DebugWire:
High: 11010110 (0xD6)
      |||||||+_______ Reset starts bootloader
      |||||++________ Bootloader size: 512 bytes
      ||||+__________ EEPROM saved during programming
      |||+___________ Watchdog timer programmable
      ||+____________ ISP programming enabled
      |+_____________ DebugWire disabled
      +______________ Reset pin enabled

High: 10010110 (0x96)
      |||||||+_______ Reset starts bootloader
      |||||++________ Bootloader size: 512 bytes
      ||||+__________ EEPROM saved during programming
      |||+___________ Watchdog timer programmable
      ||+____________ ISP programming enabled
      |+_____________ DebugWire enabled
      +______________ Reset pin enabled

                        Reset pin:
High: 11010110 (0xD6)
      |||||||+_______ Reset starts bootloader
      |||||++________ Bootloader size: 512 bytes
      ||||+__________ EEPROM saved during programming
      |||+___________ Watchdog timer programmable
      ||+____________ ISP programming enabled
      |+_____________ DebugWire disabled
      +______________ Reset pin enabled

High: 01010110 (0x56)
      |||||||+_______ Reset starts bootloader
      |||||++________ Bootloader size: 512 bytes
      ||||+__________ EEPROM saved during programming
      |||+___________ Watchdog timer programmable
      ||+____________ ISP programming enabled
      |+_____________ DebugWire disabled
      +______________ Reset pin disabled


_______________________________________________________________________________


   Show all extended fuse options:
                             BOD configuration:
Extended: 11111111 (0xFF)
          |||||+++_______ BOD: disabled

Extended: 11111110 (0xFE)
          |||||+++_______ BOD: 1.8V

Extended: 11111101 (0xFD)
          |||||+++_______ BOD: 2.7V

Extended: 11111100 (0xFC)
          |||||+++_______ BOD: 4.3V

Extended: 11111011 (0xFB)
          |||||+++_______ BOD: Invalid data= 3

Extended: 11111010 (0xFA)
          |||||+++_______ BOD: Invalid data= 2

Extended: 11111001 (0xF9)
          |||||+++_______ BOD: Invalid data= 1

Extended: 11111000 (0xF8)
          |||||+++_______ BOD: Invalid data= 0


_______________________________________________________________________________

Bootloader detail:
  Optiboot ver:  8.0
  Size:          512 bytes (256 words)
  Start address: 0x7E00
Bootloader code displayed as AVR opcodes (little endian):
C001 C0B7 2411 B784 E890 9390 0061 9210 0061 2388 F061 2F98 709A 3092 F041 FF81
C002 EF97 BF94 2E28 E080 D0C6 C0E9 E085 9380 0081 E082 9380 00C0 E188 9380 00C1
E189 9380 00C4 E086 9380 00C2 E08E D0B4 9A25 E084 E128 EF3E E091 9330 0085 9320
0084 BB96 9BB0 CFFE 9A1D 95A8 9140 00C0 FD47 C002 5081 F789 D093 3481 F479 D090
2F18 D0A0 3812 F411 E080 C004 E088 3811 F009 E083 D07E E180 D07C CFEE 3482 F419
E184 D098 CFF8 3485 F411 E085 CFFA 3585 F441 D076 2FC8 D074 2FD8 0FCC 1FDD D082
CFEA 3586 F419 E084 D085 CFDE 3684 F591 D067 D066 2EF8 D064 2ED8 E000 E011 0158
EF8F 1AA8 0AB8 D05C 01F8 8380 0185 10FA CFF6 D068 E4F5 12DF C001 CFFF E050 E040
E063 01CE D036 018E E0E0 E0F1 016F E082 0EC8 1CD1 8140 8151 E061 01C8 D02A 5F0E
4F1F 01F6 10FC CFF2 E050 E040 E065 01CE D020 CFB1 3784 F471 D033 D032 2EF8 D030
D041 018E 01F8 9185 018F D023 94FA 10F1 CFF9 CFA1 3785 F439 D035 E18E D01A E985
D018 E08F CF97 3581 F009 CFA9 E088 D024 CFA6 01FC 010A BF67 95E8 2411 B607 FC00
CFFD 7066 F029 2B45 F419 E181 BF87 95E8 9508 9190 00C0 FF95 CFFC 9380 00C6 9508
9180 00C0 FF87 CFFC 9180 00C0 FD84 C001 95A8 9180 00C6 9508 E6E0 E0F0 E198 8390
8380 9508 DFED 3280 F019 E088 DFF5 CFFF E184 CFDF 93CF 2FC8 DFE3 50C1 F7E9 91CF
CFF1 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0800


[elecdonia]

A more accurate answer to my question about the large number of different Arduino bootloaders requires explaining how the Arduino environment determines which bootloader to burn onto a board or bare AVR MCU chip.

First of all, because the bootloader communicates over a serial port, this necessitates having several different pre-compiled .hex bootloader files to match the desired AVR MCU clock frequency and baud rate. Choosing the correct .hex  bootloader file to burn onto the board or AVR MCU is handled automatically by the Arduino IDE (nearly all of the time). This configuration data is stored in Arduino "boards.txt" files. Note that "files" is plural because each "board" which can be selected by the user has its own specific "boards.txt" file.

Bootloader configuration parameters in "boards.txt: include:

• Exact name of AVR MCU part (example: ATmega328P)
• Clock frequency of AVR MCU (often 16MHz)
• Baud rate for bootloader (often 115.2k, occasionally 19.2k, 38,4k, or 57.6k)
• Which AVR UART will be used for bootloader (larger AVR devices have several)
• Exact details for how to set the "fuses" on the  AVR MCU chip
• Whether or not a bootloader is to be burned onto the AVR device

All of this is necessary because the bootloader must be aware of the AVR MCU clock frequency and of the desired serial port baud rate. These parameters (and others) must be "hard-coded" into the bootloader itself. "Boards" such as "minicore" which support several different AVR devices contain literally 100's of pre-compiled .hex bootloaders in order to support numerous different hardware, clock frequency, and baud rates. Fortunately the Arduino IDE user is spared most of the effort required to configure these details properly.

Popular Arduino boards (UNO, nano, and similar) come with bootloaders already installed. Even the Chinese clone boards often contain a "functional" bootloader pre-installed. It gets more interesting for those of us who wish to use bare AVR MCU chips or non-AVR MCU devices within the Arduino IDE. Fortunately the excellent "minicore," "mightycore," and "megacore" packages available on Github handle these details quite well. But due to the large number of choices which they support, one must pay attention to the user guide and examples provided.

Important: The Arduino IDE "burn bootloader" command does considerably more than just putting a bootloader onto the board. It also takes care of properly programming the "fuses" inside the AVR MCU. The "bootloader doesn't work" issue is often caused by incorrect fuse settings. Or by failure to select the correct choices within the Arduino IDE "boards" menu system.

For example, the "minicore" package enables the user to select among a large number of different AVR clock frequencies. But in order for this to work, one must "burn bootloader" after changing the AVR clock frequency within the Arduino IDE. This is required even for the case of using AVR MCU chips without a bootloader. I know this may not seem logical. After all, why  "burn bootloader" when one isn't using a bootloader?

The answer is this:  The Arduino IDE "burn bootloader" command properly sets the "fuses" inside the AVR MCU.

One alternative is to learn how to use AVRDUDE from either a command line or through the superb AVRDUDESS  GUI. But this requires detailed knowledge of AVR MCU hardware.

I'll provide specific examples and walk-throughs soon. I have successfully installed bootloaders onto many different AVR MCU devices. 
 
   

[westfw]

May I quote that last message on the arduino forums, pretty much in its entirety? (It’s a really excelllent summary!)
If so, how would you like to be attributed?

[M0HZH]

Ob xkcd:

(Attachment Link)

I came here to post this exact picture, but I knew in my heart it's been already posted.

[elecdonia]

May I quote that last message on the arduino forums, pretty much in its entirety? (It’s a really excelllent summary!)
If so, how would you like to be attributed?

Thanks! For now I’m low-key and don’t need any more attribution than a link to to this eevblog topic.

I find it amusing that I started this topic because I had a bunch of Arduino boards where more than 1 or 2 were really flaky in the bootloader department. So I suspected problems with the bootloader firmware. I discovered several different varieties of bootloaders on my boards, most but not all being some version of optiboot. But in reality my problem was with 3V and 5V logic failing to communicate with each other. Yep: A hardware problem. Nothing wrong with the bootloaders or the Arduino IDE, AVRDUDE, or anything else.

I still have plenty more Arduino boards and bare AVR MCU chips to analyze with FuseBytes. It’s a lot like “Situation: Now there are 15 competing standards” but in hardware. The complete AVR device family tree is like a giant live oak. I’ll never have time to check them all — just the ones I physically have on hand, which is more than I want to count right now.

Later, since I have a GitHub account (and if I learn how to navigate the licensing stuff and the developer features) then I’ll put some of my embedded code there. I’m also willing to privately share my functional code. Just send me a PM if interested.

[tooki]

Then your project will not have an Arduino bootloader and you will have to re-do all your Arduino work.

This is completely false.  The Arduino bootloaders are all completely separate and non-interacting with the user applications, whether they are "Arduino sketches" or programs written in some other development environment.  You can write Arduino sketches without using the bootloader (saves 0.5 to 8k of memory) (there's even an "upload using programmer" command), or you can use the Arduino bootloaders with non-Arduino applications.

The worst that is likely to happen is that for newer chips (ARM in particular), you may have to rebuild the application with a new segment start address for the vectors.  There are no run-time dependencies on the bootloader, and the bootloaders do their best to put the chip in a "just reset" state before starting the application.

I’ll add, because I have stated this elsewhere on the forum a few times and each time it comes as a surprise to some people:
“Arduino” really means three distinct big things:
1. Arduino-designed and branded MCU dev boards
2. The Arduino software framework, which provide easy-to-use wrappers for common functions and a few basic system functions like the millis() timer.
3. The Arduino IDE

These things are completely divisible, and you can use them in more or less any combination. (The only thing you can’t do, as far as I know, is use the Arduino IDE without using the Arduino framework, or with another programming language. Not that I see any reason you’d want to since the IDE is the least compelling part of the whole package!) You can use Arduino boards with other IDEs and languages. You can use third party boards within the Arduino IDE. You can use third party boards and another IDE, but use the Arduino framework (very common, for example programming the ESP32 with the Arduino framework with the PlatformIO IDE).

So you really can cherry-pick what you want out of the Arduino ecosystem. I’ll also add that while the Arduino framework provides wrappers for many functions, you don’t have to use them. For example, the digitalWrite() function is notoriously slow, but you are perfectly free to install an alternative library with faster IO, or write directly to the port registers. This means you can start programming with Arduino functions, and then progressively move away from them, since it’s basically C++ otherwise. It’s not an all-or-nothing situation like moving to a completely different platform.

[westfw]

The only thing you can’t do, as far as I know, is use the Arduino IDE  using the Arduino framework

Ah, but you can.  Simply leave your "sketch" .ino file completely empty, and create a new tab with .S, .c, or .cpp file that defines main(), and it will override and omit pretty much all of the Arduino code.

I don't know why anyone would want to do that, since it's pretty universally agreed that the Arduino IDE editor is one of its weaker points, and you'd have a problem if you wanted to change compiler directives.  But it is possible.  (oh, and the resulting file will still upload using the bootloader, too.   So I guess if you wanted one-button upload of AVR assembly language using the gnu assembler,  the IDE might be useful; certainly as useful as the classes I've taken where you're given a template for some other IDE and a bare minimum of info as to how you'd modify that, or create something from scratch...

[elecdonia]

...it's pretty universally agreed that the Arduino IDE editor is one of its weaker points.

Somehow I’ve managed to write a lot of code with the Arduino IDE editor but that doesn’t mean that I enjoy using it. I’m ready to change to something better. Perhaps Platformio? Notepad++?

[westfw]

The Arduino IDE's "use external editor" works pretty well, for such a simple compromise.  If you already have a favorite code editor.  When I have to do "serious work", I edit my Arduino sketches with EMACS.