mirror of
https://bitbucket.org/librepilot/librepilot.git
synced 2024-11-29 07:24:13 +01:00
41da33c920
The MSP (IRQ stack) was trampling across the data segment. This was especially disastrous in the USB interrupts since they allocate and fill buffers on the stack. The root of this trampling was that no RAM was being reserved for the MSP and a hard-coded value of (0x20000400) was used as the initial MSP base address. This resulted in the first 1K bytes of the .data segment overlapping with the IRQ stack. As can be expected, all sorts of badness resulted when interrupts were firing and trampling over variables. This change reserves the first _isr_stack_size bytes at the beginning of RAM for the MSP. If an ISR call chain runs off of the end of the MSP, a Hard Fault will be generated as the (now invalid) sp is accessed. There are two stack pointers in the Cortex-M3 CPU. These are MSP (Main Stack Pointer) and PSP (Process Stack Pointer). Which stack is in use at any given time is determined by the following table: Mode CONTROL[ASPSEL] Stack ---- --------------- ----- Thread 0 MSP Thread 1 PSP Handler x MSP Out of reset, the CPU is in Thread mode using the MSP. The initial value of the MSP is automatically loaded from address 0 (lowest word in boot region -- typically FLASH) immediately prior to jumping to the reset vector. When running at interrupt level, the Cortex-M3 always uses the MSP and the ASPSEL bit is forced to zero. FreeRTOS allocates a separate stack for each task upon task creation. These task stacks are allocated from the heap. FreeRTOS sets the active stack to the PSP whenever running in a task context (both in privileged mode and user mode). git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@652 ebee16cc-31ac-478f-84a7-5cbb03baadba |
||
|---|---|---|
| .. | ||
| Common | ||
| inc | ||
| STM32F10x | ||
| pios.h | ||