Startup sequence and reset vector in Embedded C - Deep Dive

Overview - Startup sequence and reset vector

What is it?

The startup sequence is the set of steps a microcontroller or processor follows when it is powered on or reset. The reset vector is a special memory address where the processor begins executing code after a reset. Together, they prepare the system by initializing hardware and software before running the main program.

Why it matters

Without a proper startup sequence and reset vector, the processor wouldn't know where to begin executing instructions, leading to unpredictable behavior or system failure. This concept ensures the device boots correctly every time, making embedded systems reliable and stable.

Where it fits

Learners should first understand basic processor architecture and memory concepts. After this topic, they can explore interrupt handling, bootloaders, and low-level hardware initialization.

Mental Model

Core Idea

The reset vector is the processor's starting point after reset, triggering the startup sequence that sets up the system before running the main program.

Think of it like...

It's like turning on a car: the reset vector is the ignition key position that starts the engine, and the startup sequence is the engine warming up and systems checking before you can drive.

┌───────────────┐
│ Power On / Reset │
└───────┬───────┘
        │
        ▼
┌───────────────┐
│ Reset Vector  │  <-- Fixed memory address
└───────┬───────┘
        │
        ▼
┌───────────────┐
│ Startup Code  │  <-- Initialize hardware, stack, clocks
└───────┬───────┘
        │
        ▼
┌───────────────┐
│ Main Program  │  <-- Application runs
└───────────────┘

Build-Up - 7 Steps

1

Foundation

What is a Reset Vector?

Concept: Introduce the reset vector as a fixed memory address where the processor starts after reset.

When a microcontroller powers on or resets, it needs a known place to begin executing instructions. This place is called the reset vector. It is a specific address in memory hardwired into the processor. The processor fetches the instruction from this address first.

Result

The processor always starts executing code from the reset vector after reset.

Understanding the reset vector is key to knowing how the processor knows where to start running code.

2

Foundation

Purpose of the Startup Sequence

Concept: Explain why the startup sequence is needed before the main program runs.

The startup sequence prepares the system by setting up hardware components like clocks, memory, and stack pointers. It also initializes variables and configures peripherals. This ensures the main program runs in a stable and predictable environment.

Result

The system is ready and stable before the main program starts.

Knowing the startup sequence prevents confusion about why the main program can't run immediately after reset.

3

Intermediate

Typical Steps in Startup Code

Concept: Detail common tasks performed during the startup sequence.

Startup code usually does these steps: 1. Disable interrupts to avoid unexpected behavior. 2. Initialize the stack pointer. 3. Copy initialized data from ROM to RAM. 4. Zero out uninitialized data (BSS section). 5. Configure system clocks. 6. Enable interrupts. 7. Call the main() function.

Result

The system memory and hardware are properly configured for the application.

Recognizing these steps helps understand how embedded systems prepare their environment before running user code.

4

Intermediate

Reset Vector Location and Linker Role

Concept: Explain how the reset vector address is set and how the linker places startup code there.

The reset vector is at a fixed address defined by the processor architecture. The linker script tells the compiler where to place the startup code so it matches this address. This ensures the processor fetches the correct instructions after reset.

Result

Startup code is correctly located at the reset vector address in memory.

Understanding the linker's role clarifies how code placement affects startup behavior.

5

Intermediate

Reset Sources and Their Effects

🤔Before reading on: Do you think all resets start the startup sequence the same way? Commit to your answer.

Concept: Introduce different reset sources and how they trigger the startup sequence.

Resets can come from power-on, external reset pins, watchdog timers, or software commands. Regardless of source, the processor jumps to the reset vector and runs the startup sequence. However, some systems may handle certain resets differently in software.

Result

The startup sequence runs after any reset source, ensuring consistent initialization.

Knowing reset sources helps design robust systems that handle unexpected resets gracefully.

6

Advanced

Customizing Startup Code for Optimization

🤔Before reading on: Do you think startup code must always initialize everything, or can it be optimized? Commit to your answer.

Concept: Explain how startup code can be tailored for faster boot or specific hardware needs.

Developers can customize startup code to skip unnecessary initializations or add hardware-specific setups. For example, if certain memory sections don't need clearing, skipping saves time. Also, some systems initialize clocks differently for power saving or speed.

Result

Startup time can be reduced and hardware configured precisely for application needs.

Understanding customization options enables efficient and tailored embedded system designs.

7

Expert

Reset Vector and Startup in Complex Systems

🤔Before reading on: In multi-core or secure systems, do you think all cores share the same reset vector? Commit to your answer.

Concept: Explore how reset vectors and startup sequences work in multi-core or security-focused processors.

In multi-core processors, each core may have its own reset vector and startup sequence. Secure systems may have protected reset vectors or bootloaders that verify code integrity before running startup code. This adds complexity to the startup process to ensure security and correct multi-core operation.

Result

Startup sequences adapt to system complexity, ensuring secure and coordinated booting.

Knowing these complexities prepares developers for advanced embedded system challenges.

Under the Hood

When reset occurs, the processor hardware sets the program counter to the reset vector address. This triggers fetching the first instruction from that location. The startup code runs, configuring CPU registers, memory sections, and peripherals. The stack pointer is set to a known location to manage function calls and interrupts. After initialization, control passes to main().

Why designed this way?

Processors use a fixed reset vector to simplify hardware design and ensure a known start point. The startup sequence is separated from main() to handle low-level setup transparently. This design allows application code to focus on functionality without worrying about hardware initialization details.

┌───────────────┐
│ Hardware Reset│
└───────┬───────┘
        │
        ▼
┌───────────────┐
│ PC ← Reset Vector Address │
└───────┬───────┘
        │
        ▼
┌───────────────┐
│ Startup Code  │
│ - Init SP     │
│ - Copy Data   │
│ - Clear BSS   │
│ - Setup Clocks│
└───────┬───────┘
        │
        ▼
┌───────────────┐
│ main()        │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does the reset vector contain the full startup code? Commit to yes or no.

Common Belief: The reset vector holds the entire startup code instructions.

Reality: The reset vector usually contains a jump instruction to the startup code located elsewhere in memory.

Why it matters: Misunderstanding this can cause incorrect linker scripts or startup code placement, leading to boot failures.

Quick: After reset, does the processor immediately run main()? Commit to yes or no.

Common Belief: The processor runs main() immediately after reset.

Reality: The processor runs the startup sequence first to initialize hardware and memory before calling main().

Why it matters: Skipping startup initialization can cause unpredictable program behavior or crashes.

Quick: Do all resets behave identically in embedded systems? Commit to yes or no.

Common Belief: All resets trigger the same startup sequence without variation.

Reality: Some resets, like watchdog resets, may require special handling or cause different startup behavior.

Why it matters: Ignoring reset source differences can lead to missed error recovery or system instability.

Quick: In multi-core systems, do all cores share one reset vector? Commit to yes or no.

Common Belief: All cores in multi-core processors share the same reset vector address.

Reality: Each core often has its own reset vector and startup sequence to allow independent booting.

Why it matters: Assuming a single reset vector can cause incorrect startup code design in multi-core systems.

Expert Zone

1

Some processors support relocating the reset vector to RAM for faster boot or patching without reflashing ROM.

2

Startup code often disables watchdog timers early to prevent unintended resets during initialization.

3

In secure boot systems, the reset vector may point to a bootloader that verifies firmware integrity before running startup code.

When NOT to use

Relying solely on the default startup sequence is not suitable for systems requiring fast boot times or custom hardware initialization. In such cases, custom minimal startup code or bootloaders should be used.

Production Patterns

In production, startup code is often hand-optimized in assembly for speed and size. Bootloaders precede startup code to handle firmware updates and security checks. Multi-core systems use coordinated startup sequences with inter-core signaling.

Connections

Interrupt Vector Table

Builds-on

Understanding the reset vector helps grasp how processors use vector tables to handle interrupts and exceptions similarly.

Bootloader Design

Precedes and extends

The startup sequence often follows the bootloader, so knowing startup helps understand how bootloaders prepare systems for application code.

Operating System Kernel Initialization

Similar pattern in software

The startup sequence in embedded systems parallels OS kernel initialization, where hardware and memory are set up before user programs run.

Common Pitfalls

#1 Forgetting to initialize the stack pointer in startup code.

Wrong approach:

void Reset_Handler() {
main();
}

Correct approach:

void Reset_Handler() {
__set_MSP(stack_top_address); // Initialize stack pointer
main();
}

Root cause:

Assuming the processor sets the stack pointer automatically leads to crashes when functions use the stack.

#2 Placing startup code at the wrong memory address.

Wrong approach:

Linker script places startup code at 0x2000 instead of reset vector address 0x0000.

Correct approach:

Linker script places startup code at 0x0000, matching the reset vector address.

Root cause:

Not aligning code placement with processor reset vector causes the CPU to fetch invalid instructions.

#3 Not disabling interrupts during startup initialization.

Wrong approach:

void Reset_Handler() {
// interrupts enabled
initialize_hardware();
main();
}

Correct approach:

void Reset_Handler() {
__disable_irq();
initialize_hardware();
__enable_irq();
main();
}

Root cause:

Interrupts firing before system is ready can cause unpredictable behavior or crashes.

Key Takeaways

The reset vector is a fixed memory address where the processor starts executing after reset.

The startup sequence prepares hardware and memory so the main program can run reliably.

Startup code typically initializes the stack pointer, copies data, clears memory, and sets up clocks.

Linker scripts must place startup code at the reset vector address to ensure correct booting.

Advanced systems may customize startup sequences for speed, security, or multi-core coordination.