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
