Hello everyone,

I am trying to understand how Bootloader and application program work on the system which is running without operating system ( bare metal system).

My understanding, Bootloader is program that update application program without a programmer. and an application program performs specific tasks like reading and displaying sensor data.. etc

could anyone elaborate the general process

 

On a barebones embedded MCU system, you load the application firmware and run.
You don’t need a bootloader or a programmer.
The MCU maker has to provide a means of getting the code into code memory unless it is a bus system where the code is in external ROM.

 

On a barebones embedded MCU system, you load the application firmware and run.
You don’t need a bootloader or a programmer.
The MCU maker has to provide a means of getting the code into code memory unless it is a bus system where the code is in external ROM.

I'm trying to understand systems that incorporate both a bootloader and an application program without an operating system.

Could you share your thoughts on how these systems operate?

 

OS has nothing to do with it.
MCUs come with one of four or more programming mechanisms.
The ones that come to mind are:
1) UART
2) SPI
3) JTAG
4) SWD

 

The ones that come to mind are:
1) UART

Let's assuming, This can be implemented via it's internal UART, we need to store Bootloader program in MCU's memory and also application program will also store in MCU's memory. How the system will work?

 

Normally with microcontrollers a "bootloader" is actually a bit of program separate from the main program that is used to rewrite the program memory instead of connecting a programmer. It is not like a traditional bootloader on a PC that actually loads a program from disk into RAM to run. A micro's application program is already accesslble at powerup without having to load anything.

As far as a "bootloader" that reprograms the micro there are lots of ways to go about it.

Personally I have a template I use with PICs that have enough program memory that contains a small rewrite application that checks the status of a pin at powerup and either stays in a small reprogramming loop or jumps to the main application. It takes a little tweaking of linker scripts to make it work right, but the reprogramming loop usually lives in the 0 - 7ffh memory space and the normal program starts at 800h and can go to the upper limit of program space.

It starts of by checking the status of a pin at powerup and if the pin is low it stays in the reprogramming loop which is used to rewrite the memory at 800h and up. If the pin is high at powerup it just jumps to 800h and starts executing the main program.

There are some micros that can actually run a program from RAM as opposed to FLASH memory that you could write a traditional bootloader to load a program into RAM and run it there, but you will always start with your application in flash.

 

MCUs (and CPUs) are designed to start executing program that starts at some "initial" memory location. This could be 0x0000 or whatever is a convenient. When compiler produces compiled application file, this file is then transferred to MCU and first instruction need to be at whatever the start address is.

if you want to use boot loader (just another application), then code that starts at that address is .... the bootloader itself. But since bootloader is only used initially, the footprint need to be small to leave most of memory for real application.
so bootloader is the first piece of code that gets executed and therefore it gets a chance to decide what will happen first (and next).

for example if during boot some input is set to specific state that bootloader checks, it can run routine that allows receiving and writing of the new application program (which of course is going to start at some other address). if the transfer is complete.... or request to replace program did not happen in specified amount of time (1 sec or whatever you find suitable), bootloader simply times stops waiting and lets instruction pointer run the application code (bootloader is finished here).

 

Read up about it on Wikipedia and then as specific questions about things you are still confused about.

https://en.wikipedia.org/wiki/Bootloader

 

Let's assuming, This can be implemented via it's internal UART, we need to store Bootloader program in MCU's memory and also application program will also store in MCU's memory. How the system will work?

No.
You don't implement the code saving mechanism yourself. The manufacturer of the MCU has done it for you.

I have put (1) UART as a first example. Not many MCUs make use of the UART to load firmware.
The one that comes to mind is Freescale Semiconductor (Motorola) (now NXP) MC68HC811 that loads the firmware via UART.

Next on my list is (2) SPI. Atmel (now Microchip) AVR MCUs use the SPI to load firmware.

(4) SWD. ST Microelectronics STM32 ARM MCUs use SWD or JTAG.

Read the datasheet of the MCU to find out how to load firmware.

 

Let's assuming, This can be implemented via it's internal UART, we need to store Bootloader program in MCU's memory and also application program will also store in MCU's memory. How the system will work?

What is an application program?
An application program is a program written by a user to perform a given function. Hence a bootloader is an application program.
Ignore application program. This is covered by everything else we will discuss here.

The question ought to be "How does one create, code, and install the first program into an embedded MCU code memory?"

My answers are already covered in post #2, #4, #9.

 

I do this just about every day. I order MCU chips from the supplier. They arrive. I write a program using whatever IDE is appropriate for that MCU. I hit the download button and the code is written to the MCU's code memory. Done!

 

Let us take a different approach.
You have started your own MCU manufacturing company. You have designed and created an MCU that you have called KIT8 MCU.

KIT8 MCU has 256 bytes of RAM and 1024 bytes flash memory.
What are you going to write in the User's Manual to instruct the user on how to save program code in the flash memory?

 

Hello everyone,

I am trying to understand how Bootloader and application program work on the system which is running without operating system ( bare metal system).

My understanding, Bootloader is program that update application program without a programmer. and an application program performs specific tasks like reading and displaying sensor data.. etc

could anyone elaborate the general process

Aside from the CPU/MPU-specific issues and capabilities (which cannot be ignored), there is the question of what it is you are trying to accomplish. In many cases, if running on bare metal, there is no bootloader or any need for one -- you have exactly one program and that program is in some kind of ROM that is executed immediately after power up or reset.

Where you might have something akin to a bootloader is if you want to be able to load different programs upon reset, in which case you might have a small program that runs on reset and asks the user (or whoever controls the selection) which program to run and then goes out to storage and loads it into execution memory (maybe RAM, maybe Flash). That small program could be considered a bootloader.

 

You don't implement the code saving mechanism yourself. The manufacturer of the MCU has done it for you.

In my case due to connecting PICKits wrong and destroying four of them I found it necessary to find a way to have the PIC reprogram itself. I actually have a bit more complex bootloader that I use that is all software driven and I can enter it and reset it with a simple command by I2C.

OTA updates on ESP8266 are nice. While it's not the same as writing your own bootloader it is essentially the same process.

Speaking of PICKits they also have their own bootloader to update the unit with the latest routines.

There is some real world cases where using a bootloader makes sense

 

I am sorry that taking to much time but I've noticed that bootloaders serve different purposes depending on whether they operate in a context where the system runs bare metal or with an operating system.

For instance, in PSoC microcontrollers, a bootloader is used to load application programs onto the device, operating in a bare metal environment.

Contrastingly, on a PC with Windows, the bootloader plays a crucial role in loading the startup code when the system powers on.

I am particularly interested in understanding scenarios where the bootloader program and bare metal code run concurrently on a system.

 

A bootloader writes a new application program into memory, and then allows it to run, after which the bootloader has no role. It wouldn't be a case of both pieces of software running "concurrently", even if both are in the memory at the same time.

 

I believe there are notable differences between traditional bootloaders like those used in PCs and microcontroller-based bootloaders.

PC bootloaders typically aren't utilized for firmware updates, whereas microcontroller bootloaders allow the uploading of new firmware onto the microcontroller directly from a host device, eliminating the need for a dedicated programmer device.

 

The term "bootloader" can mean different things to different people in different applications.
I will use the term "firmware loader" or "FW Loader" in my drawings below.

Every MCU has to have a built-in native FW Loader in order to load its program memory unless it is a bus-based system that uses external memory.

I have shown three scenarios below. There could be other ways of programming the Target MCU that I have not shown.



1. The FW Loader is internal to the MCU and supplied by the chip manufacturer straight from the factory. A host PC can use this directly to upload the binary code. This is how a fresh Atmel AVR ATmega328 is programmed

2. The user can first upload a program first using method #1. This new firmware called the "bootloader" has more functionality than the native FW Loader. Also, it would generally use the built-in UART for uploading. This is the mechanism used on the Arduino platform. In other words, a fresh Atmel ATmega328 needs this bootloader in order to use the Arduino platform.

3. Most, if not all MCU manufacturers provide support hardware for program development of their products. This is usually known as "Evaluation Kit", "Development Kit", "Discovery Kit", "Programmer", etc. The Programmer has its own MCU which has to be programmed liked any other MCU. This is done at the factory. It's bootloader firmware has the capability of reprogramming. In other words, the software provider can upgrade the onboard firmware via an internet browser connection.

There, I have given you three common ways of programming a target MCU.

 

In an MCU, the bootloader may have a different purpose. the normal and basic purpose is for firmware upgrades or reprogramming, without the need for a dedicated programmer or debugger. Another use case is software-based encryption. we can use the bootloader to decrypt during the startup.