- this doesn't currently change anything, but gets us ready to start
experimenting with using the small amount of instruction tightly memory
on STM32F7
- the .ramfuncs section works with NuttX CONFIG_ARCH_RAMFUNCS
- update to NuttX with stm32f4 and stm32f7 SPI DMA internal buffers
- remove explicit DMA buffer allocations from new IMU drivers
- restore original BOARD_DMA_ALLOC_POOL_SIZE
- decrease SPI DMA thresholds based on fmu-v2/v3/v4/v5 bench testing
px4_fmuv5:Needed PROGMEM
fmu-v5: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
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).
A board only needs to define:
#define RC_SERIAL_PORT "/dev/ttyS4"
Then it can optionally define one or more of the following:
#define RC_SERIAL_SWAP_RXTX
#define RC_SERIAL_SINGLEWIRE
#define RC_INVERT_INPUT(_invert_true) px4_arch_gpiowrite(GPIO_SBUS_INV, _invert_true)
* Support for armv7-m_dcache control via parameter
The FORCE_F7_DCACHE parameter can be set to
0 - (default) if Eratta exits turn dcache off else leave it on
1 - Force it off
2 - Force it on
At boot the system will disable the d-cache if the silicon
has the 1259864 Data corruption in a sequence of Write-Through
stores and loads eratta.
Post nsh script execution the FORCE_F7_DCACHE paramater
will be used to set the d-cache to the state indicated
above.
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.
- see 1259864 Data corruption in a sequence of Write-Through stores and loads
- if we can be certain this sequence won't occur in PX4 then the d-cache will be re-enabled
Daniel Agar
Beat Küng
David Sidrane
David Sidrane