Startup sequence and reset vector in Embedded C - Step-by-Step Execution

Concept Flow - Startup sequence and reset vector

Power ON / Reset

↓

CPU Fetches Reset Vector

↓

Jump to Startup Code

↓

Initialize Data & BSS Sections

↓

Call main() Function

↓

Program Runs Normally

When the device powers on or resets, the CPU fetches the reset vector address, jumps to startup code that sets up memory, then calls main() to start the program.

Execution Sample

Embedded C

void Reset_Handler() {
  // Initialize data and bss
  main();
}

int main() {
  // User code
  while(1) {}
}

This code shows the reset handler initializing memory then calling main, which runs the main program loop.

Execution Table

Step	Action	Address/Value	Description
1	Power ON or Reset	N/A	Device powers on or reset signal triggers
2	Fetch Reset Vector	0x00000000	CPU reads reset vector address from fixed location
3	Jump to Reset_Handler	0x00000000	CPU jumps to startup code address
4	Initialize .data section	Copy from Flash to RAM	Variables with initial values are copied
5	Zero .bss section	Set to 0	Uninitialized variables are cleared
6	Call main()	0x00000100	Start main program function
7	Execute main loop	N/A	Program runs user code in infinite loop
8	End	N/A	Program runs indefinitely until reset or power off

💡 Program runs indefinitely in main loop; no exit from startup sequence

Variable Tracker

Variable	Start	After Step 4	After Step 5	After Step 6	Final
.data section	In Flash	Copied to RAM	Unchanged	Unchanged	In RAM with initial values
.bss section	Undefined	Undefined	Zeroed	Unchanged	Zero in RAM
Program Counter (PC)	Reset Vector Address	Reset_Handler Address	Reset_Handler Address	main() Address	main() Address

Key Moments - 3 Insights

Why does the CPU jump to the reset vector address after power on?

Because the reset vector holds the address of the startup code, so the CPU knows where to begin executing after reset (see execution_table step 2 and 3).

What happens to variables in the .bss section during startup?

They are set to zero to ensure no garbage values (see execution_table step 5 and variable_tracker .bss section).

Why does main() never return in embedded programs?

Because embedded programs usually run continuously, main() contains an infinite loop to keep the program running (see execution_table step 7).

Visual Quiz - 3 Questions

Look at the execution_table, what is the CPU doing at step 4?

A Initializing the .data section by copying from Flash to RAM

B Jumping to main() function

C Zeroing the .bss section

D Fetching the reset vector

💡 Hint

Check the 'Action' and 'Description' columns at step 4 in execution_table

According to variable_tracker, what is the state of the .bss section after step 5?

A Copied to RAM with initial values

B Undefined

C Zeroed in RAM

D Contains garbage values

💡 Hint

Look at the .bss section row under 'After Step 5' in variable_tracker

If the reset vector address changed, which step in execution_table would be directly affected?

A Step 7: Execute main loop

B Step 2: Fetch Reset Vector

C Step 5: Zero .bss section

D Step 4: Initialize .data section

💡 Hint

The reset vector address is fetched at step 2 according to execution_table

Concept Snapshot

Startup sequence in embedded C:
- On reset, CPU fetches reset vector address
- CPU jumps to startup code (Reset_Handler)
- Startup code initializes .data and .bss sections
- Then calls main() function
- main() runs user code, usually infinite loop
- Reset vector is fixed address pointing to startup code

Full Transcript

When an embedded device powers on or resets, the CPU starts by fetching the reset vector address from a fixed memory location. This address points to the startup code, often called Reset_Handler. The CPU jumps to this startup code, which initializes the memory sections: it copies initialized variables (.data) from Flash to RAM and clears uninitialized variables (.bss) by setting them to zero. After memory setup, the startup code calls the main() function, where the user's program runs, usually inside an infinite loop to keep the device running. This sequence ensures the program starts correctly every time the device resets or powers on.