Startup Module

In embedded systems (like ARM Cortex-M), the Startup Module is the very first piece of code that runs when the processor powers up or resets. Before your main() function ever executes, the hardware is in a "raw" state; the startup module bridges the gap between hardware reset and the C environment.

It is typically written in assembly (.s or .asm), though modern compilers allow some parts to be in C.

1. The Vector Table

The most critical part of the startup module is the Vector Table. This is a list of addresses stored at the very beginning of memory.

• Initial Stack Pointer ($SP$): The first entry tells the CPU where the "top" of the stack is.

• Reset Handler: The second entry is the address of the code to run immediately after reset.

• Interrupt Vectors: The addresses of functions to handle hardware interrupts (like timers or UART).

2. The Reset Handler (The "Boot" Sequence)

When the CPU starts, it jumps to the Reset Handler. This section performs several "housekeeping" tasks that C programs take for granted:

A. Initializing Data Sections

Global variables need to be set up in RAM. Since RAM is volatile and loses data when powered off, the startup module must copy values from Flash (permanent storage) to RAM.

• .data section: Copies initialized global variables (e.g., int x = 5;) from Flash to RAM.

• .bss section: Finds the memory for uninitialized globals (e.g., int y;) and clears it to zero. (this is for globals only; these uninitialized variables will have an undefined value if they were declared inside a function)

B. Hardware Initialization

It may perform low-level hardware configuration that must happen immediately:

• Configuring the System Clock (PLL).

• Initializing external memory controllers (if the program is too big for internal RAM).

• Setting up the Watchdog Timer.

C. Setting the Stack Pointer

While the hardware often loads the initial $SP$ from the vector table, the startup code ensures the stack is properly aligned and ready for function calls.

3. Jumping to Main

Once the memory is prepared and the hardware is stable, the startup module performs the final handoff:

1. It calls Standard Library Initialization (like __libc_init_array in GCC) to handle C++ constructors.

2. It calls main().

3. The Safety Net: It usually includes an infinite loop after the call to main(). If main() ever returns (which it shouldn't in an embedded system), the CPU will hit this loop instead of executing random "garbage" memory.

Summary of Execution Flow

Think of the startup module as the construction crew that builds the house; main() is the resident who moves in only after the plumbing and electricity are turned on.

I totally get it. Assembly can feel like trying to build a Lego castle while wearing oven mitts—everything is manual and slightly clunky.

Let's strip away the technical jargon and use a simple "Office Desk" analogy to understand the Startup Module.

1. The Analogy: The First Day at a New Job

Imagine you are a top-tier engineer (this is main()). You show up to your new office, but the building was just finished an hour ago.

If you just walked in and tried to work, you’d fail because:

• There's no power.

• Your desk is empty (no pens, no computer).

• You don't even know where your desk is.

The Startup Module is the Janitorial & IT Crew that arrives 2 hours before you to set everything up.

2. The 3 Simple Steps of Startup

Before the CPU lets you run main(), the Startup Module does these three things:

Step A: The Map (The Vector Table)

The CPU is "blind" when it wakes up. It only knows one thing: "Look at address 0."

The Startup Module puts a "Map" at address 0 that says:

1. "Here is where the Stack (your scratchpad memory) starts."

2. "Here is the address of the Reset Handler (the 'Start' button)."

Step B: The Setup (Data & BSS)

In your C code, you might write int x = 5;.

• When the power is off, that 5 is stored in Flash (like a hard drive).

• But when the program runs, it needs to be in RAM so it can be changed.

The Startup Crew copies that 5 from Flash into RAM. They also take any variables that don't have a value (like int y;) and wipe their spot in RAM to Zero. Now, the "office" is stocked with the supplies you expected.

Step C: The Hand-off

Once the desk is ready and the lights are on, the Startup Module does a simple jump:

"Okay, everything is ready. Go to main()."

3. Why is it "A Lot"?

It feels like a lot because, in Assembly, nothing is automatic. * In Python or C on a PC, the Operating System (Windows/Linux) does all this for you behind the scenes.

• In Embedded Systems, you are the OS. You have to tell the "Janitorial Crew" exactly how to clean the office.

Does this help?

Think of it as:

1. Vector Table = The Map.

2. Reset Handler = The Janitor (Cleaning and moving boxes).

3. Main = You (The Engineer) finally sitting down to work.