How does UART bootloader program flash application data into Flash/ROM memory

[cv007]

I bet many users would be more willing to install your custom application, than to use some modem-era software they have never heard about

That custom application can just as easily deal with the mcu that is using an xmodem bootloader, so one can have both- custom application for those that need/want it and can also use xmodem transfer (and any other needed interaction) via a terminal app like tera term for any others that can handle that.

I have a bootloader in the online compiler, for a modern avr (xmodem-crc)-
https://godbolt.org/z/YMWczGTrx

I have written various bootloaders starting with early pic's, and the above was simply so I could use sx on a linux pc and also tera term on a Windows pc. I previously wrote avr bootloaders that could take in a hex file, where I could drag/drop the hex file on tera term but that required adding a line delay as there is no flow control when doing something like that. With the above xmodem-crc bootloader I do convert to binary in the build so I do not need translation in the mcu.

Normally I have little need for bootloaders anymore, but for a current project I have a single wire coming out of a box for uart debug info and if I need to reprogram I would rather not open the box to get at the programming pins (although in this avr there is a single updi programming pin which I can tie to the one-wire uart pin and make it work, just not willing to tie the updi pin to the uart pin even though the probability of inadvertently entering programming is pretty slim). With this setup I can remain in tera term while watching debug info and do any reprogramming if needed.

I also have a bootloader for the newer avr where the bootloader has a simple protocol and very little brains (basically read n bytes from addr, or write n bytes to addr). The pc software does all the work, including writing to the appropriate nvm registers to do the flash write. So you basically have read/write access to the ram/peripherals from the pc. Its simple on the mcu side, but you just moved the work to the pc side and probably end up with more work in the end.

[abyrvalg]

Another kind of bootloader (not for true Harvard CPUs like PIC/AVR/8051): just two commands - “write to RAM” and “jump to RAM”. The real job is performed by the external code loaded to RAM. This allows to define the actual functionality later. I.e. you can decide to do things like reformatting some settings area to a newer structure together with app update, or read something out for fault analysis, or perform some kind of init/test/calibration, or any combination of these things by loading a specific “RAM loader”, performing the function, rebooting/returning back to bootloader, loading another one.

[NorthGuy]

I also have a bootloader for the newer avr where the bootloader has a simple protocol and very little brains (basically read n bytes from addr, or write n bytes to addr). The pc software does all the work, including writing to the appropriate nvm registers to do the flash write. So you basically have read/write access to the ram/peripherals from the pc. Its simple on the mcu side, but you just moved the work to the pc side and probably end up with more work in the end.

This is what SWD can do on ARM32 directly, along with nearly anything else, Doesn't require any bootloader at all.

[eutectique]

Do you have a specific standard / field in mind where this is a requirement?

The EU Cyber Resillience Act which has a broad scope (including industrial IoT). From December 2027 it is part of CE compliance.

You might be interested in a webinar hosted by Memfault named "Shipping Firmware Under the CRA: Nicolas Schieli on the Questions Everyone’s Asking, and the Ones They Should Be"

https://memfault.com/resources/coredump-024-shipping-firmware-under-the-cra-nicolas-schieli/

It starts in 25 minutes, sorry for the late link, I just happen to come across new comments in this topic.

[cv007]

This is what SWD can do on ARM32 directly, along with nearly anything else, Doesn't require any bootloader at all.

The newer avr has updi which is similar with a single wire using uart half-duplex protocol. Certainly no need for a bootloader if you can make use of native programming.

[westfw]

Certainly no need for a bootloader if you can make use of native programming.

UPDI, and some other built-in programming capabilities, tend to be on pins that are NOT the same as a product might use to communicate under normal circumstances (eg USB or UART.)  So you frequently see (for example) UDPI-capable AVRs with an added UART bootloader, or STM32F103 boards ("Blue Pill") with a USB bootloader...