|
67 | 67 | //! `_stack_end` which is automatically placed after the end of statically allocated RAM. |
68 | 68 | //! |
69 | 69 | //! **NOTE:** If you change `_stack_start`, make sure to also set `_stack_end` correctly to match |
70 | | -//! new stack area if you are using it, e.g for MSPLIM. The `_stack_end` is not used internally by |
71 | | -//! `cortex-m-rt` and is only for application use. |
| 70 | +//! new stack area if you are using it, e.g for MSPLIM. |
| 71 | +//! |
| 72 | +//! The `_stack_end` is checked by linker script to be less than or equal to `_stack_start` and is |
| 73 | +//! used as a bound in `paint-stack` feature. |
72 | 74 | //! |
73 | 75 | //! For Cortex-M, the `_stack_start` must always be aligned to 8 bytes, which is enforced by |
74 | 76 | //! the linker script. If you override it, ensure that whatever value you set is a multiple |
|
193 | 195 | //! |
194 | 196 | //! ## `paint-stack` |
195 | 197 | //! |
196 | | -//! Everywhere between `__sheap` and `_stack_start` is painted with the fixed value |
| 198 | +//! Everywhere between `_stack_end` and `_stack_start` is painted with the fixed value |
197 | 199 | //! `STACK_PAINT_VALUE`, which is `0xCCCC_CCCC`. |
198 | 200 | //! You can then inspect memory during debugging to determine how much of the stack has been used - |
199 | 201 | //! where the stack has been used the 'paint' will have been 'scrubbed off' and the memory will |
@@ -573,9 +575,9 @@ cfg_global_asm! { |
573 | 575 | 1:", |
574 | 576 |
|
575 | 577 | // If enabled, paint stack/heap RAM with 0xcccccccc. |
576 | | - // `__sheap` and `_stack_start` come from the linker script. |
| 578 | + // `_stack_end` and `_stack_start` come from the linker script. |
577 | 579 | #[cfg(feature = "paint-stack")] |
578 | | - "ldr r0, =__sheap |
| 580 | + "ldr r0, =_stack_end |
579 | 581 | ldr r1, =_stack_start |
580 | 582 | ldr r2, =0xcccccccc // This must match STACK_PAINT_VALUE |
581 | 583 | 0: |
|
0 commit comments