A temperature logger is a classic example where in-field firmware updates should be an option. I don't particularly plan to add functionality, but users should be able to use the (UART) data cable instead of a development environment and in-system programming to receive bug fixes and optimizations.

I started reading about bootloaders and very quickly got a headache. The ATmega328PB datasheet has a bootloader chapter, and Atmel has released an AES-encrypted bootloader example specifically for this device. I didn't care about encryption, since this is an open-source project, but I thought I'd learn something... more headaches.

After watching some youtube videos that mostly didn't explain the basic context, I luckily came upon a pdf put together by the AVR Freaks community a while back (found here at the bottom of the first entry) and finally got it.

These are the three points I wish I had read first to make sense of all the other details:

1. A bootloader is a regular firmware program and it's best developed as a stand-alone application. It should be small enough to fit in the bootloader section
2. You need to set your programming environment to enable the bootloader section and put this application in that section. You can also use fuses to protect it.
3. An mcu with a bootloader technically has two firmwares. It first runs the bootloader (hence the name)[Edit: depending on the fuse, the AVR starts at main program or at the bootloader, but if you set the fuse and there's no bootloader it will go to the main program, which is nicely forgiving]. Then your main application will run. If you want to, you can program your bootloader to be able to receive a firmware file and write it to the main application flash memory. The main application should be able to reset back to the bootloader to enable a firmware update, unless your device has a reset button.

I think I've got these basics right. The next step, overwriting the flash, seems easier to grasp.