FreeRTOS has a strict requirement that even interrupt-safe API calls (ie.
those ending in "FromISR") can only be called from ISRs that are at lesser
or equal priorities to configMAX_SYSCALL_INTERRUPT_PRIORITY. See the
"configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY"
section at:
http://www.freertos.org/a00110.html
The interrupt numbers used on the Cortex-M3 CPU has a somewhat backward
representation of the interrupt numbers so 255 = lowest priority and
0 = highest priority.
The calculation is further complicated by the STM32 implementation only using
the upper 4 bits of the priority value. Only 0x00, 0x10, 0x20, ..., 0xE0, 0xF0
represent useful interrupt priorities.
FreeRTOS requires that MAX_SYSCALL and KERNEL interrupt priorities are expressed
as raw unshifted 8-bit values to be programmed directly into the BASEPRI register.
The priority values passed to the NVIC initialization, however, are expected
to be 4-bit values and are shifted up by 4 within NVIC_Init() for you.
The end result is that we need this arrangement:
[highest priority]
NVIC_0 (Non-maskable-interrupt)
NVIC_1
NVIC_2
[Must NOT call FreeRTOS APIs above here]
configMAX_SYSCALL_INTERRUPT_PRIORITY (now at 48 = 0x30 = NVIC_3)
PIOS_IRQ_PRIO_HIGHEST (cur. NVIC_4)
PIOS_IRQ_PRIO_HIGH (cur. NVIC_5)
PIOS_IRQ_PRIO_MID (cur. NVIC_8)
PIOS_IRQ_PRIO_LOW (cur. NVIC_12)
configKERNEL_INTERRUPT_PRIORITY (240 = 0xF0 = NVIC_15)
[lowest priority]
The previous config had configMAX_SYSCALL_INTERRUPT_PRIORITY set at
191 (0xBF) which is effectively NVIC_11. This was allowing all of
the MID, HIGH and HIGHEST interrupt handlers to preempt the OS in
its critical sections. Since some of these ISRs were calling
FreeRTOS APIs, this would result in corrupting internal data structures
within the OS.
It should be ok to move the configKERNEL_INTERRUPT_PRIORITY to a higher
priority as long as it is less than configMAX_SYSCALL_INTERRUPT_PRIORITY.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@637 ebee16cc-31ac-478f-84a7-5cbb03baadba
This fixes the gdb stepi command to allow the M3 core to make
forward progress even when interrupts are pending. M3 Core interrupts
are masked/unmasked in pre and post command hooks.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@636 ebee16cc-31ac-478f-84a7-5cbb03baadba
Moved the generated python classes from the flight directory to the
ground directory since they are only used on the host, not the
embedded targets.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@628 ebee16cc-31ac-478f-84a7-5cbb03baadba
The uavobjectgenerator can now generate python classes for each
UAVObject definition. This is useful for writing simple test
applications in python that can exercise the UAVObject handling
code on the embedded boards.
This is a work in progress so the structure of the generated
classes is likely to change.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@623 ebee16cc-31ac-478f-84a7-5cbb03baadba
The gdb commands step, next and finish on the M3 core would
never make forward progress since there is almost always an
interrupt pending. This is a known problem on the M3, and is
fixed by adding pre and post command hooks which mask and unmask
all ISRs on the M3 core.
Step, next and finish now work as expected, but care should be
taken when using these commands across any part of the code that
actually _needs_ the interrupts in order to make forward progress.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@622 ebee16cc-31ac-478f-84a7-5cbb03baadba
Add the AHRS firmware to the "all" target since it is once again
compiling successfully.
Fix reinstall of QT SDK, Create placeholder for uavobjects.
Reinstall of the QT SDK prompted to remove the read-only license
file. Use rm -rf to avoid the prompt.
The uavobjects target now creates a directory in the build tree.
This will eventually hold the generated .c/.h/.cpp/.py files that
are generated from the UAVObjects xml files.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@621 ebee16cc-31ac-478f-84a7-5cbb03baadba
- manages QT and ARM toolchain installation on Linux
- manages OpenOCD build and installation on Linux
- downloaded install packages are placed in <top>/downloads
- defaults tool installs to be under <top>/tools directory
- builds both the GCS and the openpilot firmware
- build targets to regenerate the UAVObjects synthetic files
- builds are placed in <top>/builds
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@596 ebee16cc-31ac-478f-84a7-5cbb03baadba
