The first three topics on Bootloaders and DFU will cover general bootloader and DFU concepts.

To begin this step-by-step look at how a bootloader works, starting from non-volatile memory.

As a starting note, remember that while related, the Bootloader and Device Firmware Updates (DFU) are different.

Non-volatile memory

Memory that is not erased when a chip is power cycled is called non-volatile memory. This memory is ordered into 32-bit registers on nRF chips. We will illustrate this as such:

All Nordic Semiconductor chips are 32-bits(8 hex digits).

In previous courses here, we have programmed applications to chips. If the Development Kit running one of these samples is disconnected and reconnected to power, the application will start running again, because the application hex file is stored in non-volatile memory.

When an nRF chip powers on, it will start executing code from address 0x00000000 (Technically, it’s the Reset vector, which on Arm Cortem-M is 0x00000004, as 0x00000000 is reserved for the SP initial value. For simplicity, we will say its address 0x00000000). Because of this, applications without a bootloader are stored from address 0x00000000 and onward. Typically, the application does not fill up all of the non-volatile memory, so there is some space left.

Bootloader

A basic bootloader can be explained by the name: A bootloader starts at Boot and Loads your application. The bootloader is just a second application hex file running on the chip. When the bootloader is done running, it will point the CPU to continue running from the start of the Application.