ARM Cortex M Boot Process

The ARM Cortex M is a family of 32-bit RISC ARM processor cores used in various microcontroller units (MCUs) and system-on-a-chip (SoC) designs. The Cortex M boot process refers to the startup sequence that occurs when power is first applied to a Cortex M based MCU or SoC.

On a high level, the key steps in the Cortex M boot process are:

1. Reset Sequence
2. Bootloader Execution
3. Application Initialization and Execution

Let’s look at each of these stages in more detail:

1. Reset Sequence

When power is first applied to a Cortex M based device, the processor begins executing code from a fixed reset vector address, without any requirement for bootstrading. This fixed address is 0x00000004 for Cortex M3 and 0x0000000C for Cortex M4/M7.

Code execution begins in Arm state, with interrupts disabled. The reset handler code is responsible for initializing critical system components and then branching to the main application. This typically involves:

• Setting up the stack pointer
• Initializing static and global variables
• Enabling FPU (for Cortex M4/M7)
• Configuring clock sources
• Enabling interrupts

ARM provides reference implementations of the reset handler code and startup files for various toolchains. These perform the minimum initialization required to transition from the reset state before branching to the main application.

2. Bootloader Execution

After the reset sequence, most Cortex M devices will execute a bootloader prior to launching the main application. The key responsibilities of the bootloader are:

• Initializing main system clocks, PLLs and peripherals
• Testing and initializing external RAM
• Copying application code and data sections to RAM from flash
• Performing security checks and authentications
• Passing execution to the application

Some common bootloader architectures used with Cortex M devices include:

• ROM bootloader – Bootloader code residing in masked ROM or one-time programmable flash
• RAM bootloader – Primary bootloader copied to RAM by ROM bootloader
• Multi-stage bootloader – Combination of ROM, RAM and external bootloaders

Example open-source Cortex M bootloaders include Arm Mbed, ChibiOS, Amazon FreeRTOS, Zephyr RTOS. Commercial bootloaders like SEGGER Bootloader can also be used.

3. Application Initialization and Execution

After the bootloading sequence is complete, execution passes to the main application entry point, usually denoted as main() or app_main(). The key tasks here are:

• Initialize remaining peripherals used by the application
• Enable interrupts needed by the application
• Initialize application specific variables, buffers, queues, mutexes, etc
• Transition to the main application task/thread

From this point, the application takes over and runs continuously based on its functionality. This may be a simple program loop, a superloop RTOS architecture, or a more complex multithreaded application.

A few common practices when initializing the application include:

• Having separate init functions for different modules or libraries
• Using auto-generated code from MCU vendors to setup clocks/peripherals
• Initializing various data structures before their first use

In a RTOS environment, one or more initial application tasks are also created before the scheduler is started.

Cortex M Boot Process Summary

In summary, the typical ARM Cortex M boot process consists of:

1. Executing reset handler code from a fixed vector address
2. Running bootloader code to setup clocks, memory and peripherals
3. Launching the main application entry point
4. Application initializing itself and starting main tasks/threads

This provides a smooth sequence to go from power-on reset to launching the intended application functionality, by separating boot critical initialization from application specific setup.

Understanding the different phases of the Cortex M boot process allows developers to correctly structure their code and identify issues during debugging. The flexibility of the Cortex M reset and boot architecture allows developers to customize the process based on their specific needs.

Cortex M Boot Process Customization

While the high-level boot flow remains similar across implementations, developers have a lot of flexibility in customizing the process for their application:

• The reset handler can be tailored to perform additional initialization if needed by the application.
• Different types of bootloaders can be configured based on performance, size and hardware requirements.
• Multiple application images can be stored and selected between using features like firmware update.
• RTOS aware applications initialize kernel objects before starting multitasking.
• Boards often feature boot configuration pins/fuses to control the default boot flow.

This customization capability allows manufacturers to optimize the boot flow for their specific Cortex M device and use case.

Factors Impacting Boot Time

Some key factors impacting boot time on Cortex M devices include:

• System clock speed – Faster clocks reduce absolute boot time.
• Bootloader complexity – More complex bootloaders take longer to execute.
• Application size – Time taken to copy larger applications to RAM increases.
• Optimization level – Compiler optimizations like link-time optimizations (LTO) can help.
• Wait states – Flash/RAM wait states add latency when accessing memory.
• JTAG debugging – Presence of JTAG probe increases reset sequence time.

Boot time is generally in the tens to hundreds of milliseconds range for most commercial Cortex M devices. Exact timings can be obtained using oscilloscope measurements or debug timestamp counters.

Optimizing the Boot Process

Some ways to optimize the boot process for faster time-to-market include:

• Minimizing unnecessary application initialization code
• Having reset handler initialize only the minimum required peripherals
• Using a image pre-population or XIP bootloader to avoid RAM copy delay
• Optimizing linker scripts and compiler settings for smaller code size
• Tuning clock configurations and wait states for maximum speed
• Leveraging hardware acceleration like ART Accelerator or PUF

Faster boot times improve the user experience and enable quicker transition to productive application execution.

Conclusion

In summary, the ARM Cortex M boot process provides a well-defined and flexible startup sequence allowing MCUs to transition from reset to application execution. Understanding the different phases like reset handler, bootloader, and application initialization helps developers optimize and customize the boot flow for their specific needs. Factors like system clocks, bootloader type and application size impact the overall boot time which can range from tens to hundreds of milliseconds. With the right techniques, developers can optimize the Cortex M boot process to achieve quick and reliable startup tailored to their application requirements.