blob: eac1b352d1aa605cb6857e85b9b159ce45dbd2f7 [file] [log] [blame]
This file describes the processor startup process.
The basic idea is that the bootloader and main code each have their own
exception handler tables and code. The bootloader's code lives at the bottom
of flash and the main code is in the rest of it. They both use the same startup
code (STM32F2XX_startup.S, which deals with copying .data etc into RAM and
zeroing RAM for .bss etc. This same file also defines the layout of the
exception table (full of weak symbols). Although they both use the same startup
code, it gets put into different places by the different linker scripts. The
main code's exception table is in .data so it gets copied into RAM before being
used to avoid waiting for flash reads to handle interrupts, but the bootloader's
just gets put in flash because it has to be there (at address 0) and it doesn't
care about interrupt performance.
The bootloader code has its exception table starting at address 0, which is
where the processor goes to start. The processor sets the stack pointer to the
1st entry in the table and then jumps to the 2nd (the reset handler). Our
bootloader then checks if it should pass through to the main code. If it does
that, it then uses the same kind of interface to the main code's startup file.
The main code's exception table lives in RAM, so the bootloader just uses the
stack pointer and reset handler values that it knows because they're always the
same (stack pointer to the top of RAM and reset handler at the beginning of
the main code's flash).