|
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