AVR bootloaders

[mcuee]

There are quite some issues related to AVR109 (some of them are related to xmega AVRs).

The official Microchip AVR109 AN and FW source codes can be downloaded here.
https://www.microchip.com/en-us/application-notes/an1644

However, it seems to be troublesome to get it work properly, at least based on my experiences. I am still struggling to get it to work with ATmega2560 (Note: xboot seems to work fine). I even have issues with ATmega8A and ATmega16A which are supposed to be work out of the box. I only managed to get it to work with ATmega32A and ATmega328P.

From @MCUdude
#454 (comment)

I'm also quite surprised that the "proper" AVR109/910 source code is hard to find. Microchip has hidden it quite well, and there are multiple versions/forks floating around. We should collect the pieces and host them somewhere so we have a known good reference we can use when we troubleshoot AVR109/910/911 issues.

[mcuee]

The following is my understanding so far on AVR109.

AVR109 -- bootlader
https://www.microchip.com/en-us/application-notes/an1644 (you can download the AN and FW source codes here)

AVR910 -- simple pogrammer (mostly outdated other than to program ebn files)
http://ww1.microchip.com/downloads/en/appnotes/atmel-0943-in-system-programming_applicationnote_avr910.pdf

AVR911 -- The AVR Open-source Programmer (AVROSP) application for AVR109 and AVR910
https://www.microchip.com/en-us/application-notes/an2568 (you can download AN and PC application here)

ATxmega and AVR109 AN:
http://ww1.microchip.com/downloads/en/Appnotes/Atmel-8242-XMEGA-Boot-Loader-Quick-Start-Guide_ApplicationNote_AVR1605.pdf

xboot -- extension to AVR109, mostly for xmega AVRs but apparently also for mega AVRs.
https://github.com/alexforencich/xboot

[MCUdude]

Good! So ix xboot is AVR109 compatible and is superior in terms of device support, support, and build process, I don't see the reason why anyone would still use the original 109 code. I'm not sure if xboot is smaller in size than AVR109 when compiled though...

[MCUdude]

But this is great research @mcuee, I'm glad we have you on the team! I, personally feel like I know AVR109 a little better. And now that we've narrowed down several issues, all there's left is a quick hardware test, and that's on me. I suspect there's nothing wrong with Avrdude's 109/911 implementation, and the original reporters just didn't use xboot, as we would probably recommend using instead.

[mcuee]

I think both AVR109 and xboot can be customized for different size. But I have not tried to see the minimum size of AVR109 (remove the optional features) and xboot.

[mcuee]

@MCUdude
Just found out that Codevision AVR109 example does support ATmega2560. But I do not have CVAVR myself. Maybe it can be ported to gcc.
http://www.hpinfotech.ro/cvavr-examples.html
https://www.hpinfotech.ro/avr109.zip

[MCUdude]

I believe I have CodeVision with a valid license on my work computer. I'll give it a try someday. Thanks for providing the source files!

[mcuee]

There are many AVR bootloaders, but only a few are relatively popular.

1. STK500v1 compatible, optiboot is probably the most famous -- avrdude recommends to use -c urclock to deal with them and not the old -c arduino.
   https://github.com/Optiboot/optiboot

For classic AVRs, the recommendation from avrdude project is to change optiboot to urboot.

Optiboot_x for new UPDI AVRs: megaAVR-0 and tinyAVR 0/1/2
https://github.com/MCUdude/MegaCoreX/tree/master/megaavr/bootloaders/optiboot
https://github.com/SpenceKonde/megaTinyCore/tree/master/megaavr/bootloaders/optiboot_x

Optiboot_dx for new UPDI AVR DA/DB/DD
https://github.com/SpenceKonde/DxCore/tree/master/megaavr/bootloaders/optiboot_dx

Then there are others as well.
Eg: https://github.com/arduino/ArduinoCore-avr/tree/master/bootloaders/atmega
Eg: https://github.com/nerdralph/picoboot (stk500v1 version)

2. urboot -- recommended bootloader by avrdude project, currently only supports classic AVR chips. -c urclock is the option to use.

3. AVR109 compatible -- eg: plain AVR109, xboot, Caterina (USB CDC-ACM, based on LUFA)

For classic AVR chips, the recommendation is to use urboot to replace AVR109.

xboot is recommended if you are using ATxmega.

Caterina is still good if you use USB AVRs.

4. STK500v2 compatible, like wiring (-c wiring).
   The recommendation is to use urboot to replace wiring bootloader.

5. USB DFU bootloader (flip1/flip2) for USB AVRs

Interesting one: https://makecode.com/blog/uf2-for-arduino-uno

6. Micronucleus V-USB based bootloader, usually for classic Tiny AVRs

The following bootloaders are more for niche use cases -- they are supported by avrdude.

1. USBtinyISP based --> eg: Arduino Gemma
2. USBASP based -- eg: usbasploader
3. teensy: bootloader for USB Mega AVRs, mostly for teensy based boards
4. Arduino MegaCore bootloader: AN2634 based.
   https://github.com/arduino/ArduinoCore-megaavr/blob/master/bootloaders/boot.c

Then there are other bootloaders which may not be supported by avrdude yet.

1. Microchip AN2634 Bootloader for tinyAVR 0- and 1-series, and megaAVR 0-series (UART or I2C) (not supported by avrdude? or same as the Arduino MagaCore bootloader?)
   https://www.microchip.com/en-us/application-notes/an2634

2. Microchip AVR2054 bootloader (partially supported by avrdude with DFU?)
   https://ww1.microchip.com/downloads/en/Appnotes/Atmel-8390-WIRELESS-AVR2054-Serial-Bootloader-User-Guide_Application-Note.pdf

3. New from Microchip: 8-bit Microchip Device Firmware Update (MDFU) Client Library. NOT supported by avrdude project yet.
   https://onlinedocs.microchip.com/oxy/GUID-9CE46BA1-9CDF-4B9C-9C73-4793B27ED320-en-US-2/GUID-C7B15FCE-8C29-4B05-AACE-5A7D3EF63F72.html

AVR® MCUs
ATtiny 0, 1 and 2 Family of devices
AVR DA, DB, DD, EA, EB Family of devices

4. One-Way-Loader
   http://www.jtxp.org/tech/onewayloader_en.htm

5. Small bootloader for ATtiny13
   https://blog.sperka.pl/en/2019/09/uboot-avrtiny-bootloader-for-attiny13/

6. picoboot (either own prorotocl or stk500v1 compatible, stk500v1 version is supported by avrdude)
   https://github.com/nerdralph/picoboot

7. ubaboot v0.5 is a USB bootloader for atmega32u4 in 512 bytes.
   https://github.com/rrevans/ubaboot

[mcuee]

So far I have tested quite some bootloaders.

1. STK500v1 compatible: optiboot --- tested on quite some boards
2. AVR109 compatible -- tested AVR109 (various boards), xboot (ATmega2560) and Caterina (ATmega32U4)
3. STK500v2 compatible: wiring -- tested with Atmega2560
4. USB DFU bootloader (flip1/flip2) for USB AVRs -- tested only FLIP1 on ATmega16U2 and ATmega32U4.
5. Micronucleus bootloader -- tested on ATtiny45/85/88/167
6. USBtinyISP based: Arduino Gemma bootloader -- tested on ATtiny85
7. USBASP based: usbasploader -- tested on USBASP (ATmega8A version)
   Ref: https://github.com/jethomson/Project-Ouroboros
   https://jethomson.wordpress.com/2011/08/18/project-ouroboros-reflashing-a-betemcu-usbasp-programmer/

To be tested:
8) teensy: teensy 2.0 and 2.0++ board on order (Done)

[mcuee]

There are multiple usbasploader implementations in github.

1. https://www.obdev.at/products/vusb/usbasploader.html (original version from obdev.at)
2. https://github.com/baerwolf/USBaspLoader
3. https://github.com/slackmasterstan/USBaspLoader_lcsoft-usbasp (minor mod)
4. https://github.com/embedded-creations/USBaspLoader-tiny85 (mod for ATtiny85)
5. https://github.com/frank26080115/LufaUsbAspLoader (for USB AVRs, probably not so useful)
6. https://github.com/jethomson/Project-Ouroboros (for USBASP HW ATmega8/8A version)

Tools:
https://github.com/baerwolf/USBaspTool

[mcuee]

New one: 8-bit Microchip Device Firmware Update (MDFU) Client Library
https://onlinedocs.microchip.com/oxy/GUID-9CE46BA1-9CDF-4B9C-9C73-4793B27ED320-en-US-2/GUID-C7B15FCE-8C29-4B05-AACE-5A7D3EF63F72.html

AVR® MCUs
ATtiny 0, 1 and 2 Family of devices
AVR DA, DB, DD, EA, EB Family of devices

Host tool:
https://pypi.org/project/pymdfu/

FW image builder
https://pypi.org/project/pyfwimagebuilder/

[mcuee]

@stefanrueger, @MCUdude and @askn37

Since you have quite good expertise in AVR bootloaders, just wondering if you would like to look at the above new Microchip offered bootloader for modern UPDI AVR parts, and then see if we can support them in avrdude. Thanks.

As of now urclock does not support UPDI AVR parts.

[stefanrueger]

-c urclock should support optiboot_x/_dx bootloaders for UPDI parts, at least it did when -c urclock was added to avrdude.

I guess if there is a new bootloader it should have a protocol description somewhere that needs implementing. I would not aim to have this for v7.3

[mcuee]

Of course this will not be target for 7.3 release. Just want to bring awareness.

[askn37]

Essay: About AN2634.

A very primitive bootloader demo specific to tinyAVR and megaAVR. The source code is less than 200 lines and the code is less than 256 bytes. The ELF file contains a .text section that shows the entire code and a .fuse section that shows recommended values for FUSE settings.

By default, when the boot selection switch is LOW on Power-On-Reset, the device enters bootstrap mode and waits with the UART open at 115200bps 8N1. Received bytes are written sequentially from the beginning of the flash area, and self-resets when the entire flash area is full.

That's all that's been implemented. If it ends midway, please perform an external reset. There is no error detection. It is also not possible to read the flash area.

Can AVRDUDE support that? There's no doubt that it can, but it doesn't have a handshake protocol, so you can't control the state of the target. AVRDUDE can only write data as is.

[mcuee]

Probably not popular and Microchip has moved on to the following for modern AVR parts (UPDI parts).
https://onlinedocs.microchip.com/oxy/GUID-9CE46BA1-9CDF-4B9C-9C73-4793B27ED320-en-US-2/GUID-C7B15FCE-8C29-4B05-AACE-5A7D3EF63F72.html
Supported Devices and Families
PIC16/PIC18 MCUs
All Melody supported PIC16 and PIC18 MCUs
AVR® MCUs
ATtiny 0, 1 and 2 Family of devices
AVR DA, DB, DD, EA, EB Family of devices

[askn37]

agree. I don't think anyone is currently using this.

Interestingly, this variant of AN2634 still exists in "ArduinoCore-megaavr". It was probably used very early on. And by adding megaavr support to the Arduino IDE, this code and binary is secretly stored on everyone's PC.

https://github.com/arduino/ArduinoCore-megaavr/blob/master/bootloaders/boot.c

[flyandancexo]

AVR109:
I have created FDxboot 1.51 and 1.51x based on AVR109; With at maximum upload speed of 31kb/s on MCU with 256-bytes and 18kb/s on MCU with 128-bytes per page; AVR109 is very simple bootloader. There shouldn't be any problem with it. You can easily use the <avr/boot.h>header to create a working bootloader with it.
Here is a FDxboot 1.34 testing video on an Atmega16.
https://www.youtube.com/watch?v=hqverV1aoek

Here is Juno FDxboot 1.51 operates at 2Mbps on an atmega8 with upload speed of 7.3kB/s; 6722/0.91=7386
https://www.youtube.com/watch?v=3Yae3hhMZ0A

===================================================
AVR910

FDxICSP is based on AVR910. It's outdated, maybe, but salvageable, definitely.
Here is an upload demo: https://www.youtube.com/watch?v=HmQwEG8Dqw4

And there is a PCB photo of the actual programmer that I have just created. It actually is self-programmable using FDxBoot 1.5 bootloader. The programmer works fine, and I am confident to get it to upload at around 25-30kB/s on my atmega128, and make it universally support all MCU that supports SPI interface as means of flash programming. I don't own a MCU with 256kb, and both of these protocol is limited to sending a 16-bit word address, and that means 128kb is the maximum supported size. Other than that, both AVR109 and AVR910 work fine.

===================================================
AVR911
It's a software end, and I have tested it, and it works, but what it can do, AVRdude can also do, so it's pointless to bother with it. It's useless in short.

[mcuee]

Some benchmark results of urboot and @flyandancexo's optimized AVR109 bootloader (no source codes available yet).

• Flash Read and Write Speed Benchmark #1022 (reply in thread)

Note: please set FT232RL adapter latency timer to 1ms (Windows and Linux) before carrying out the benchmark test.

ATmega328P, avrdude 7.3 release msvc64 binary

urboot 1M baud rate (CH340)
write 32,000 B/2.98 s = 10,738 B/sec
read 32,000 B/0.76 s = 42,105 B/sec

urboot 1M baud rate (Uno ATmega16U2)
write 31,488 B/2.59 s = 12,158 B/sec
read 31,488 B/0.44 s = 71,564 B/sec

urboot 2M baud rate (Uno ATmega16U2)
write 31,488 B/2.43 s = 12,958 B/sec
read 31,488 B/0.26 s = 121,107 B/sec

urboot 2M baud rate (Nano FT232RL)
write 31,488 B/2.46 s = 12,800 B/sec
read 31,488 B/0.36 s = 87,467 B/sec

FDxboot optimized avr109 at 1M baud rate (1.61beta) (CH340)
write 31,488 B/1.36 s = 23,153 B/sec
read 31,488 B/0.81 s = 38,874 B/sec

FDxboot optimized avr109 at 2M baud rate (1.62beta stable) (CH340)
write 31,488 B/1.23 s = 25,600 B/sec
read 31,488 B/0.72 s = 43,733 B/sec

FDxboot optimized avr109 at 2M baud rate (1.62beta fast) (Uno ATmega16U2)
write 31,488 B/1.08 s = 29,156 B/sec
read 31,488 B/0.35 s = 89,966 B/sec

FDxboot optimized avr109 at 2M baud rate (1.62beta fast) (Nano FT232RL)
write 31,488 B/1.09 s = 28,888 B/sec
read 31,488 B/0.71 s = 44,349 B/sec

STK500v1 (from urboot) at 1M baud rate (CH340)
write 31,488 B/3.26 s = 9,659 B/sec
read 31,488 B/1.16 s = 27,145 B/sec

@flyandancexo's results are a bit better for the CH340, probably different CH340x adapter and different computer.

FDxboot 1.62@2Mbps with CH340G:
Atmega88:
7162/0.46=15569
7162/0.26=27546

Atmega16:
15352/0.56=27414
15352/0.31=49522

Atmega128A:
(129998+50)/2.88=45155
(129998+50)/2.54=51200

[askn37]

New Project

euboot : EDBG USB bootloader for AVR-DU series : https://github.com/askn37/euboot

• USB bootloader for AVR-DU series.
• Developed due to the unavailability of DFU bootloaders.
• Uses standard USB-HID/CMSIS-DAP/EDBG protocols and is recognized as a jtag3updi device by AVRDUDE>=8.0.
• Fast memory read/write speeds, close to the limits of USB-HID Full-Speed.
• Footprint is less than 2.5KiB. Probably the smallest ATMELICE compatible subset.

CMSIS-DAP/EDBG protocol : AVR64DU32 (M1 macos Sequoia USB 2.0 Full-Speed)
Write 65,536 B/7.02 s = 9,336 B/sec
Read 65,536 B/3.08 s = 21,279 B/sec

$ test8 -a-Pusb:04d8:0b12 jtag3updi avr64du32

Processing -U ALL:r:bak-jtag3updi-avr64du32.hex:I
Reading multiple memories ...
 - eeprom          | ################################################## | 100% 1.03 s 
 - flash           | ################################################## | 100% 3.14 s 
 - fuses           | ################################################## | 100% 0.06 s 
 - fuse0/wdtcfg    | ################################################## | 100% 0.00 s 
 - fuse1/bodcfg    | ################################################## | 100% 0.00 s 
 - fuse2/osccfg    | ################################################## | 100% 0.00 s 
 - fuse5/syscfg0   | ################################################## | 100% 0.00 s 
 - fuse6/syscfg1   | ################################################## | 100% 0.00 s 
 - fuse7/codesize  | ################################################## | 100% 0.00 s 
 - fuse8/bootsize  | ################################################## | 100% 0.00 s 
 - fusea/pdicfg    | ################################################## | 100% 0.01 s 
 - lock            | ################################################## | 100% 0.02 s 
 - prodsig/sigrow  | ################################################## | 100% 0.01 s 
 - signature       | ################################################## | 100% 0.00 s 
 - tempsense       | ################################################## | 100% 0.02 s 
 - sernum          | ################################################## | 100% 0.06 s 
 - bootrow         | ################################################## | 100% 0.01 s 
 - userrow/usersig | ################################################## | 100% 0.06 s 
 - sib             | ################################################## | 100% 0.00 s 
Writing 66772 bytes to output file bak-jtag3updi-avr64du32.hex

Processing -T fact reset
performing chip erase; discarded pending writes to flash, EEPROM and bootrow
Caching | ################################################## | 100% 1.07 s 
Caching | ################################################## | 100% 0.01 s 
Caching | ################################################## | 100% 0.01 s 
Caching | ################################################## | 100% 0.07 s 
after the next reset the part will have F_CPU = 4.000 MHz

Processing -U ALL:w:bak-jtag3updi-avr64du32.hex:I
Reading 66740 bytes for multiple memories from input file bak-jtag3updi-avr64du32.hex
Writing 256 bytes to eeprom
Writing | ################################################## | 100% 4.14 s 
Reading | ################################################## | 100% 1.02 s 
256 bytes of eeprom verified
Writing 65536 bytes to flash
Writing | ################################################## | 100% 7.02 s 
Reading | ################################################## | 100% 3.08 s 
65536 bytes of flash verified
Writing 16 bytes to fuses, 16 bytes written, 16 verified
Writing 1 byte (0x00) to fuse0/wdtcfg, 1 byte written, 1 verified
Writing 1 byte (0x00) to fuse1/bodcfg, 1 byte written, 1 verified
Writing 1 byte (0x00) to fuse2/osccfg, 1 byte written, 1 verified
Writing 1 byte (0xD1) to fuse5/syscfg0, 1 byte written, 1 verified
Writing 1 byte (0x08) to fuse6/syscfg1, 1 byte written, 1 verified
Writing 1 byte (0x00) to fuse7/codesize, 1 byte written, 1 verified
Writing 1 byte (0x05) to fuse8/bootsize, 1 byte written, 1 verified
Writing 2 bytes (0x03 00) to fusea/pdicfg, 2 bytes written, 2 verified
Writing 4 bytes (0x5C C5 C5 5C) to lock, 4 bytes written, 4 verified
Writing 256 bytes to bootrow
Writing | ################################################## | 100% 0.03 s 
Reading | ################################################## | 100% 0.01 s 
256 bytes of bootrow verified
Writing 512 bytes to userrow/usersig
Writing | ################################################## | 100% 0.06 s 
Reading | ################################################## | 100% 0.06 s 
512 bytes of userrow/usersig verified

Processing -U ALL:v:bak-jtag3updi-avr64du32.hex:I
Verifying 66740 bytes of multiple memories against input file bak-jtag3updi-avr64du32.hex
Reading | ################################################## | 100% 1.03 s 
256 bytes of eeprom verified
Reading | ################################################## | 100% 3.07 s 
65536 bytes of flash verified
16 bytes of fuses verified
1 byte of fuse0/wdtcfg verified
1 byte of fuse1/bodcfg verified
1 byte of fuse2/osccfg verified
1 byte of fuse5/syscfg0 verified
1 byte of fuse6/syscfg1 verified
1 byte of fuse7/codesize verified
1 byte of fuse8/bootsize verified
2 bytes of fusea/pdicfg verified
4 bytes of lock verified
Reading | ################################################## | 100% 0.01 s 
128 bytes of prodsig/sigrow verified
3 bytes of signature verified
4 bytes of tempsense verified
16 bytes of sernum verified
Reading | ################################################## | 100% 0.01 s 
256 bytes of bootrow verified
Reading | ################################################## | 100% 0.06 s 
512 bytes of userrow/usersig verified
32 bytes of sib verified

Avrdude done.  Thank you.

[MCUdude]

Amazing work! I'm definitely giving this a try!

BTW are there any legal issues when it comes to using Atmels VID/PIDs like this? Let's say I want to design a commercial product around the AVR-DU, and want to use your bootloader? Can I "just do that"?

[askn37]

@MCUdude

Amazing work! I'm definitely giving this a try!

BTW are there any legal issues when it comes to using Atmels VID/PIDs like this? Let's say I want to design a commercial product around the AVR-DU, and want to use your bootloader? Can I "just do that"?

The currently used VID:PID is 0x04D8, 0x0B12. This is derived from microchip-pic-avr-examples and is used for USB-HID purposes. For example, this:
https://github.com/microchip-pic-avr-examples/avr64du32-keypad-mplab-mcc/blob/22785ed868e9b46902f33df4951bdf9408955e9c/avr64du32-keypad-mplab-mcc.X/mcc_generated_files/usb/usb_descriptors.c#L83-L84

This is just my opinion, but I believe that VID:PIDs released for demo and testing purposes to general users can be used at the user's own risk, except for those explicitly reserved and prohibited uses.

Similarly, 0x0B15 is reserved for USB-CDC demonstration for AVR-DU purposes.

If you deviate from such intended use, you will need to contact Microchip and have them issue you with a unique PID. I recall there was a contact point for corporations for this purpose. If you applied as a corporation, I believe you could get a PID issued free of charge for up to 10,000 devices. I don't think that would be possible for a personal community, though.

[mcuee]

FYI. I got one valid VID/PID from Microchip long time ago (back in 2011) for the libusbK benchmark USB demo device: 04d8:fa2e.
https://github.com/mcuee/libusbk/blob/master/BmFW/MCP/USB_Device_Benchmark/Firmware/usb_config.h

[mcuee]

Microchip link:
https://www.microchip.com/usblicensing/#/