- increase stack sizes to run cleanly under stackcheck
- this is likely overkill for most boards, but using stackcheck to set our minimum ensures we have a very safe margin on regular builds and it's something we can currently afford
- remove holybro_durandal-v1_stackcheck from test rack (there's only one unit)
Change PID to 0x4b:
Holybro obtained their own PID and VID but APM did not follow
the PX4 convention of makeing the board_id (0x8b) match the PID)
Incorporated the Upstream Bootloader state sequencing checking change.
Change the usb cout to send all chars in 1 write.
Durandal:Fix PLL settings
durandal-v1:Move I2C123, I2C4 to HSI.
Not liking using HSI but, F7 has, and in reality there is no
requerment for accuracy.
durandal-v1:board config set 400kHz on card probe
durandal-v1:Board SDMMC Clock Not greater then 25 mHz
durandal-v1:Fix PLL3 configuration typo and value
CI build config for holybro_durandal-v1
durandal-v1:Kconfig - add knob to ensure ARCH_MATH_H is kept
Upstream changes added ARCH_HAVE_MATH_H to protect from archs
without math.h from causing isses for users setting
CONFIG_ARCH_MATH_H and getting errors. PX4 provides a math.h
and we need CONFIG_ARCH_MATH_H set. So this Selects
ARCH_HAVE_MATH_H perserving CONFIG_ARCH_MATH_H a defconfig
Track master LED removal
durandal-v1: bmi055 -> bmi088
bmi088 is what the board uses
durandal-v1:add PX4IO support
durandal-v1 rc.board_sensors: start baro
durandal-v1: remove segway module
durandal:Run at 480 Mhz
durandal-v1: build thermal control module
durandal-v1: enable IMU thermal control by default
durandal-v1:Track upstream adc start moved to rc.board_sensors
durandal-v1:Track upstream mavlink start moved to rc.board_mavlink
On more complicated setups it's still possible to exceed 32 tasks. For example fmu-v5 with mavlink on every telem (+ USB), external spi usage (pmw3901), gimbal (vmount), multiple i2c sensors, and camera feedback is 35 tasks (with top running). This is a fairly extreme case, so I'm only going to increase CONFIG_MAX_TASKS on newer F7 boards.
But only on the first 4 FMU outputs, as the next ones conflict with px4io
serial dma (UART8_RX)
RX DMA is disabled on the GPS port as well (conflicts with TIM1).
The cause of the stack detection fault is because of the
level of nesting in the start up script. We need to
determine the worst case configuration and set the
bar there.
This fault occurred some 42 calls deep due to script
calling script (repeat).
The HW stack check requires as a margin of 204 bytes. That is
ISR HW stacking of CPU(8) FPU(18) registers and SW stacking of
CPU(11) and FPU(16) registers. Total CPU(19) registers is
68 bytes and the total FPU(34) registers is 136 bytes. On
a system with a separate ISR stack This only needs to be 104
so there is 100 bytes of headroom. But as coded the detection
will give a false positive detection and fault. This does not
mean that the stack will be corrupted.
Adjustments to that stack can have no effect due to rounding.
A stack size of 2608 and 2616 can yield the exact same size stack.
So even when the failure is due to a 4 byte overflow, it can take
greater than a 16 bytes increase to fix it. Because the final
stack size is calculated with an 8 byte alignment after a 4 byte
decrease. So 2624 becomes 2620 at runtime and will boot
with SYS_AUTOSTART=4001.
This insures the common exception handler will not be
re-entered. The handler does not support nested interrupts
and the interrupt stack pointer and context will be overwritten
resulting in hard to debug hardfaults.
If all the priorities are equal the NVIC prevents the
preemption. The startup code defaults all the priorities
to the same value 128.
This change safeguards in 2 ways 1) By disabling
CONFIG_ ARCH_IRQPRIO: up_prioritize_irq cannot be called.
This will insure that all HW interrupts are at the same
priority.
2) By disabling CONFIG_ARCH_HIPRI_INTERRUP, the common
exception will disable any interrupts during interrupt
processing.
This is needed for companions with high baudrate and high data rate.
Tested with 1500000 Baudrate and mavlink TX rate of ~120KB/s: no drops.
I did not test the exact limit, something like 2500 might be enough. But
we (still) have enough free RAM on FMU-v5.
Daniel Agar
CUAV_gitfishup
David Sidrane
Beat Küng
David Sidrane
Lorenz Meier