Beyond Main: Deconstructing the Cortex-M Startup Sequence from The Very First Cycle

For most embedded engineers, the application begins at main(). Everything before that is treated as "vendor magic": a black box of assembly and obscure C macros that we are afraid to touch.

In this session, we will open this black box and trace the exact lifecycle of Cortex-M microcontrollers from the very first clock cycle.

We will dissect the anatomy of a boot sequence, moving beyond the simple "copy .data / zero .bss" path to explore the darker corners of system initialization. How the VTOR works, the specific roles of MSP vs. PSP stack pointers, TrustZone setup before the first jump, and the "IDE Lock-in" - how vendor-specific startup files create hidden dependencies that make migrating from one IDE or toolchain to another a nightmare of broken builds.

Whether you are writing a bare-metal bootloader, debugging a complex crashing RTOS application or porting your project from one IDE to another, understanding life before main is the key to reliable and secure firmware.

What this presentation is about and why it matters

What actually has to happen before your firmware reaches main, and why do startup bugs so often hide in that space? Alexey Karelin opens the black box of Cortex-M startup with a guided walkthrough grounded in reset behavior, vector tables, linker sections, startup code, and handoff paths such as bootloaders, RTOSes, and TrustZone. The focus is on how the pieces fit together across toolchains and memory maps, using concrete embedded details rather than abstract theory. This is a strong fit for engineers who have used startup files before, but want to understand the sequence well enough to debug, port, or customize it with more confidence.

Who will benefit the most from this presentation

• Embedded software engineers who edit startup files, linker scripts, or memory maps and want a clearer mental model.
• Firmware developers debugging hard faults, boot issues, or “why did my code never reach main?” problems.
• Engineers porting Cortex-M code across GCC, Keil, or IAR and running into startup differences.
• Developers working with bootloaders, RTOS integration, or secure and non-secure memory separation.
• Experienced MCU programmers who know the basics, but want to understand the early boot path in more depth.

What you need to know

Useful background for getting the most from this session:

• Basic familiarity with Cortex-M microcontrollers and bare-metal firmware structure.
• Comfort reading C startup code and simple assembly snippets.
• Some exposure to linker scripts or memory sections such as .text, .data, and .bss.
• Awareness of how a bootloader or RTOS changes application startup, even if the details are fuzzy.

Glossary (terms used in this talk)

• TrustZone: ARM technology that provides hardware-based isolation between secure and non-secure execution environments.
• Vector table: An array of pointers to exception and interrupt handlers. On Cortex-M systems, it typically begins with the initial stack pointer and reset handler, followed by core exceptions and device-specific interrupts.
• Reset handler: The function executed immediately after reset, typically responsible for early initialization before application code runs.
• BSS (Block Started by Symbol): A section used for zero-initialized variables. Its contents are not stored as initialized data and are typically cleared by startup code.
• SystemInit: A vendor-specific early initialization function that typically runs before C runtime setup. It is commonly used for clock setup, memory timing, FPU enablement, and silicon errata workarounds.
• No-init section: A RAM section that is intentionally left uninitialized during startup. It is useful for preserving state across software resets or storing crash data.
• Fini array: A section that holds destructor callbacks for static objects. It is commonly used in C++ runtime cleanup paths.
• Non-secure callable (NSC): A small controlled entry region that allows code in the non-secure world to call into secure code. It is part of TrustZone-based separation and access control.

Toolbox (mentioned in this talk)

• GCC: A widely used compiler toolchain for C and C++ and other languages. In embedded development, it is commonly used to build firmware for many microcontrollers.
• Keil: An embedded development toolchain and IDE family used for building and debugging microcontroller firmware. It is commonly associated with ARM-based development workflows.
• FreeRTOS: A widely used real-time operating system for embedded systems. It is commonly integrated as a library that the application initializes and then starts scheduling tasks.
• Zephyr RTOS: A scalable real-time operating system for connected and resource-constrained devices. It often owns much of the system startup flow, including hardware initialization and thread setup.
• Renesas Cortex-M85 microcontroller: A Cortex-M85-based device platform used to illustrate extended memory regions such as ITCM, DTCM, data flash, and external SRAM. It represents a concrete example of a more complex startup and linker configuration.
• IAR linker configuration file (ICF): A linker configuration format used by IAR Embedded Workbench to define memory placement and startup-related symbols. It expresses the same mapping problem as other embedded linker systems, but with its own syntax.

Final thoughts

Practical and detail-oriented, this talk gives you a cleaner mental model of what early boot code is doing and where startup assumptions tend to break. The value is less about memorizing syntax and more about learning how to reason about reset flow, memory placement, and handoff between boot stages. It will help firmware engineers, porting teams, and anyone who has had to debug a system that fails long before main. It makes the invisible part of boot feel navigable.

This overview is AI-generated from the session transcript. Spot an issue? Let us know.