ARM Cortex-M Processor Reset Sequence Explained | Boot & Startup Process

Introduction to ARM Cortex-M Reset Sequence:

Understanding the reset sequence of ARM Cortex-M microcontrollers is crucial for embedded system developers. This blog post explains what happens internally when a reset occurs—either through power-on, a manual reset button, or during a debug session.

🤔 A common interview question is:
“What happens when you reset an ARM Cortex-M processor?”

In this article, you will find a clear and structured answer to the above question.

Before diving into the Cortex-M7 boot sequence, it’s important to understand why a reset is necessary in microcontrollers. A reset ensures the system starts from a known, predictable state. It also enables developers to debug their applications right from the beginning of execution.

For example, when connecting a debugger (such as ST-Link, JTAG, or an E1/E2 emulator), the processor is reset to halt the CPU before the application begins. This guarantees a clean debugging session from the very first instruction.

Why Reset is Important in ARM Cortex-M Microcontrollers:

Ensures the device starts in a known, stable state
Useful during firmware debugging
Required during power cycling or software faults
Triggers the startup code execution

Key Factors Influencing Cortex-M Boot Sequence:

Several factors determine how the ARM Cortex-M processor behaves during the boot process:

Whether an operating system is used
Availability and configuration of TCMs (Tightly Coupled Memory)
How the vector table is set up during reset
Clock and memory initialization sequences

In addition to the hardware setup, the CMSIS (Cortex Microcontroller Software Interface Standard) also plays a major role. It provides a standardized startup structure that simplifies development across different toolchains and vendors.

CMSIS defines two critical startup files that help structure the boot sequence and facilitate easier migration and portability.

startup_<DeviceName>.s

system_<DeviceName>.c

<DeviceName> is replaced with the name of the device, for example:

startup_stm32f401xc.s

system_stm32f4xx.c

Cortex-M Startup Files and the Reset Handler:

Most Cortex-M silicon vendors provide two essential startup files that help developers get up and running quickly on their target devices:

Assembly Startup File (.s or .asm):
This file typically contains the vector table, along with the definitions for the stack and heap, and the Reset_Handler—the entry point after a reset.
System Initialization File (usually system_.c):
This is a device-specific C file that initializes system clocks, external oscillators (like XTAL), and configures PLL and other core-level peripherals.

What Happens Inside Reset_Handler?

The Reset_Handler is executed immediately after a reset and usually calls two critical functions:

1. SystemInit():
This function configures the system and clock settings, such as external oscillator frequency, PLL multipliers/dividers, and flash latency settings.

2. __main (or __iar_program_start depending on the toolchain):
This is a compiler/runtime-provided function (not the user’s main()) responsible for:

Initializing the C runtime environment
Setting up global/static variables
Calling C++ constructors (if applicable)
Eventually transferring control to the user-defined main() function

If you want to learn STM32 from scratch, you should follow this course “Mastering Microcontroller with Embedded Driver Development”. The course contains video lectures of 18.5-hours length covering all topics like, Microcontroller & Peripheral Driver Development for STM32 GPIO, I2C, SPI, USART using Embedded C.

Enroll In Course

ARM Cortex-M Reset Sequence Explained (Step-by-Step):

Let’s walk through a simplified example that demonstrates the reset sequence of an ARM Cortex-M7 processor, from power-on reset to reaching the main() function.

Assumptions:
ROM is mapped at address 0x00000000
RAM is mapped at address 0x20000000
A single binary image (firmware) is stored in ROM

⚠️ Note: This example is intended for basic understanding. For detailed information, refer to the official Arm Developer Portal.

Step-by-Step Reset Sequence:

I am explaining the following steps based on the given assumption. These steps are intended solely for basic understanding.

1. Reset Triggered:

After a reset (power-on, software, or external), the Cortex-M processor begins execution at address 0x00000000, in Thread mode using the Main Stack Pointer (MSP) by default. Depending on the configuration, thread mode can operate in privileged or unprivileged mode.

2. Stack Pointer Initialization:

The processor reads the initial stack pointer value from address 0x00000000 and loads it into the SP (Stack Pointer) register. It’s the developer’s responsibility to place a valid stack address at 0x00000000.

3. Program Counter Initialization:

Next, the processor reads the reset vector from address 0x00000004, which contains the address of the Reset_Handler. This value is loaded into the Program Counter (PC).

4. Jump to Reset_Handler:

The processor begins executing the Reset_Handler function, which looks like this in assembly.

; Reset handler
Reset_Handler    PROC
                 EXPORT  Reset_Handler             [WEAK]
        IMPORT  SystemInit
        IMPORT  __main

                 LDR     R0, =SystemInit
                 BLX     R0
                 LDR     R0, =__main
                 BX      R0
                 ENDP

5. Call to SystemInit():

The Reset_Handler first calls the SystemInit() function, which typically performs:

Clock configuration (e.g., PLL, XTAL, HSE/HSI setup)
FPU (Floating Point Unit) settings (if available)
Vector table base address setup (via VTOR)
Memory system initialization

6. Jump to __main:

After SystemInit(), the control is transferred to __main, a function provided by the toolchain’s runtime. This is not the same as your application’s main() function.

__main is responsible for:

Initializing the C runtime environment
Copying initialized data from ROM to RAM,
Zero-initializing the .bss section,.
Invoking C++ global constructors (if any).
Finally calling the user-defined main() function

7. Call the main function (your application code).