|
8 | 8 | //! This crates takes care of: |
9 | 9 | //! |
10 | 10 | //! - The memory layout of the program. In particular, it populates the vector table so the device |
11 | | -//! can boot correctly, and properly dispatch exceptions and interrupts. |
| 11 | +//! can boot correctly, and properly dispatch exceptions and interrupts. |
12 | 12 | //! |
13 | 13 | //! - Initializing `static` variables before the program entry point. |
14 | 14 | //! |
|
221 | 221 | //! One will always find the following (unmangled) symbols in `cortex-m-rt` applications: |
222 | 222 | //! |
223 | 223 | //! - `Reset`. This is the reset handler. The microcontroller will execute this function upon |
224 | | -//! booting. This function will call the user program entry point (cf. [`#[entry]`][attr-entry]) |
225 | | -//! using the `main` symbol so you will also find that symbol in your program. |
| 224 | +//! booting. This function will call the user program entry point (cf. [`#[entry]`][attr-entry]) |
| 225 | +//! using the `main` symbol so you will also find that symbol in your program. |
226 | 226 | //! |
227 | 227 | //! - `DefaultHandler`. This is the default handler. If not overridden using `#[exception] fn |
228 | 228 | //! DefaultHandler(..` this will be an infinite loop. |
229 | 229 | //! |
230 | 230 | //! - `HardFault` and `_HardFault`. These function handle the hard fault handling and what they |
231 | | -//! do depends on whether the hard fault is overridden and whether the trampoline is enabled (which it is by default). |
| 231 | +//! do depends on whether the hard fault is overridden and whether the trampoline is enabled (which it is by default). |
232 | 232 | //! - No override: Both are the same function. The function is an infinite loop defined in the cortex-m-rt crate. |
233 | 233 | //! - Trampoline enabled: `HardFault` is the real hard fault handler defined in assembly. This function is simply a |
234 | | -//! trampoline that jumps into the rust defined `_HardFault` function. This second function jumps to the user-defined |
235 | | -//! handler with the exception frame as parameter. This second jump is usually optimised away with inlining. |
| 234 | +//! trampoline that jumps into the rust defined `_HardFault` function. This second function jumps to the user-defined |
| 235 | +//! handler with the exception frame as parameter. This second jump is usually optimised away with inlining. |
236 | 236 | //! - Trampoline disabled: `HardFault` is the user defined function. This means the user function is called directly |
237 | | -//! from the vector table. `_HardFault` still exists, but is an empty function that is purely there for compiler |
238 | | -//! diagnostics. |
| 237 | +//! from the vector table. `_HardFault` still exists, but is an empty function that is purely there for compiler |
| 238 | +//! diagnostics. |
239 | 239 | //! |
240 | 240 | //! - `__STACK_START`. This is the first entry in the `.vector_table` section. This symbol contains |
241 | | -//! the initial value of the stack pointer; this is where the stack will be located -- the stack |
242 | | -//! grows downwards towards smaller addresses. |
| 241 | +//! the initial value of the stack pointer; this is where the stack will be located -- the stack |
| 242 | +//! grows downwards towards smaller addresses. |
243 | 243 | //! |
244 | 244 | //! - `__RESET_VECTOR`. This is the reset vector, a pointer to the `Reset` function. This vector |
245 | | -//! is located in the `.vector_table` section after `__STACK_START`. |
| 245 | +//! is located in the `.vector_table` section after `__STACK_START`. |
246 | 246 | //! |
247 | 247 | //! - `__EXCEPTIONS`. This is the core exceptions portion of the vector table; it's an array of 14 |
248 | | -//! exception vectors, which includes exceptions like `HardFault` and `SysTick`. This array is |
249 | | -//! located after `__RESET_VECTOR` in the `.vector_table` section. |
| 248 | +//! exception vectors, which includes exceptions like `HardFault` and `SysTick`. This array is |
| 249 | +//! located after `__RESET_VECTOR` in the `.vector_table` section. |
250 | 250 | //! |
251 | 251 | //! - `__INTERRUPTS`. This is the device specific interrupt portion of the vector table; its exact |
252 | | -//! size depends on the target device but if the `"device"` feature has not been enabled it will |
253 | | -//! have a size of 32 vectors (on ARMv6-M) or 240 vectors (on ARMv7-M). This array is located after |
254 | | -//! `__EXCEPTIONS` in the `.vector_table` section. |
| 252 | +//! size depends on the target device but if the `"device"` feature has not been enabled it will |
| 253 | +//! have a size of 32 vectors (on ARMv6-M) or 240 vectors (on ARMv7-M). This array is located after |
| 254 | +//! `__EXCEPTIONS` in the `.vector_table` section. |
255 | 255 | //! |
256 | 256 | //! - `__pre_init`. This is a function to be run before RAM is initialized. It defaults to an empty |
257 | | -//! function. As this runs before RAM is initialised, it is not sound to use a Rust function for |
258 | | -//! `pre_init`, and instead it should typically be written in assembly using `global_asm` or an |
259 | | -//! external assembly file. |
| 257 | +//! function. As this runs before RAM is initialised, it is not sound to use a Rust function for |
| 258 | +//! `pre_init`, and instead it should typically be written in assembly using `global_asm` or an |
| 259 | +//! external assembly file. |
260 | 260 | //! |
261 | 261 | //! If you override any exception handler you'll find it as an unmangled symbol, e.g. `SysTick` or |
262 | 262 | //! `SVCall`, in the output of `objdump`, |
|
0 commit comments