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...

[eutectique]

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"

For anyone interested in the effects of CRA coming into force in September 2026, here is the webinar recording:

[peter-h]

I started a thread here on the EU security thing. I don't think many people have time to watch a 1hr video
https://www.eevblog.com/forum/microcontrollers/eu-cyber-regulation-and-secure-firmware-updates-mandatory/

Re boot loaders, lots of ways to do it and with a lot of history.

One of the oldest formats is intex hex. You have a line of about 5 bytes, in ascii-hex, 2 bytes per binary byte, and each line starts with the load address. So you receive this line into RAM, check the checksum on it, and program it into FLASH. It usually relies on FLASH being much faster to program than the data is arriving, which is usuall ok.

The boot loaders in STM arm32 chips just receive data and program each byte into flash. Not sure there is any addressing. The loader code runs in a different address space to the flash being programmed; this is obviously important since you cannot normally execute from the same flash bank (there are exceptions to this and e.g. the 32F4 can, in certain ways). I wrote a RAM-resident loader to do it properly - see threads on eevblog on loaders, relocatable code, etc.

[MIS42N]

I started a thread here on the EU security thing. I don't think many people have time to watch a 1hr video
https://www.eevblog.com/forum/microcontrollers/eu-cyber-regulation-and-secure-firmware-updates-mandatory/

You are right. TL:DR (well not Read but Watch - I felt sleepy after a minute). So I looked up EU CRA and there's a Wikipedia article. It seems open source is exempt so I am in the clear. I'm happy for people to hack anything I make public.

Re boot loaders, lots of ways to do it and with a lot of history.

Every computer has to have a boot loader. Historically it was in a ROM, the CPU would fetch its first instruction from a fixed address and proceed from there. The instructions may initiate a primitive user interface allowing the user to select a device from which to load a program. Many recent microprocessors have a programming state (for example raise a pin to a specific voltage) which activates something in the processor which allows it to be programmed. So the examples in this thread are really secondary loaders, originally loaded into the processor by the hardware loader. In the PC world the primary loader is the BIOS. For early machines it usually loads IIRC 128 bytes from a selected device, for a disk or USB drive this was from sector 0. The second 128 bytes had a partition table. The 128 bytes was a secondary loader that started loading another loader from the disk (sectors 1-?) which was a tertiary loader that was responsible for loading the operating system. I'm not up to date on the latest PC load system.

 
One of the oldest formats is intex hex. You have a line of about 5 bytes, in ascii-hex, 2 bytes per binary byte, and each line starts with the load address. So you receive this line into RAM, check the checksum on it, and program it into FLASH. It usually relies on FLASH being much faster to program than the data is arriving, which is usuall ok.

Intel hex is a little more complex than that. The loader I wrote for the PIC reads Intel format, as that is the output of the tool chain. A record starts with : followed by a byte count and ends with a checksum. The data in between can be a few different things. There can be padding bits between a checksum and the next : to allow time for programming to take place. I didn't need that because XMODEM implementation programs the flash before sending an ACK.

[peter-h]

Yes of course. Typo: I meant 50 bytes. Probably 64 mostly. But the key point is that each intel hex line is standalone and gets programmed at the stated address. There can be gaps...

I wrote intel hex loaders in the old days.

[brucehoult]

each intel hex line is standalone and gets programmed at the stated address.

They're not standalone. There is a current base address to which the address in each line needs to be added. Original HEX was 16 bit addresses, then they extended it for segmented 20 bit, and later 32 bit. There is no standard 64 bit extension.

I wrote intel hex loaders in the old days.

I wrote a simple and overly-permissive one a couple of years ago.

https://github.com/brucehoult/trv/blob/main/trv.c#L55