| Brian Silverman | 44311d6 | 2013-12-06 22:03:29 -0800 | [diff] [blame] | 1 | This file describes the processor startup process. |
| 2 | |
| 3 | The basic idea is that the bootloader and main code each have their own |
| 4 | exception handler tables and code. The bootloader's code lives at the bottom |
| 5 | of flash and the main code is in the rest of it. They both use the same startup |
| 6 | code (STM32F2XX_startup.S, which deals with copying .data etc into RAM and |
| 7 | zeroing RAM for .bss etc. This same file also defines the layout of the |
| 8 | exception table (full of weak symbols). Although they both use the same startup |
| 9 | code, it gets put into different places by the different linker scripts. The |
| 10 | main code's exception table is in .data so it gets copied into RAM before being |
| 11 | used to avoid waiting for flash reads to handle interrupts, but the bootloader's |
| 12 | just gets put in flash because it has to be there (at address 0) and it doesn't |
| 13 | care about interrupt performance. |
| 14 | |
| 15 | The bootloader code has its exception table starting at address 0, which is |
| 16 | where the processor goes to start. The processor sets the stack pointer to the |
| 17 | 1st entry in the table and then jumps to the 2nd (the reset handler). Our |
| 18 | bootloader then checks if it should pass through to the main code. If it does |
| 19 | that, it then uses the same kind of interface to the main code's startup file. |
| 20 | The main code's exception table lives in RAM, so the bootloader just uses the |
| 21 | stack pointer and reset handler values that it knows because they're always the |
| 22 | same (stack pointer to the top of RAM and reset handler at the beginning of |
| 23 | the main code's flash). |