Without reverting this a constant boot loop occurs.
Prior to merging, why this occurs on some F7 boards and not this one should be looked at.
With LazyFPU enabled, v1.12.0 beta1 will not boot but without it removed it works fine.
This fixes RSSI for the Control Zero F7 but I have noticed that while this works perfectly for SBUS receivers, for PPM receivers it does not decrease the RSSI visual value in QGC when removing the RC transmitter connection.
When a PPM receiver is connected and the connection is lost the autopilot goes into RC Scan Mode (in the RC Update Module) to determine what is connected (even though something already is connected).
The main issue with this is that PPM receivers don't go into RC Failsafe but I don't think it is an issue with this autopilot. It looks to be an issue with the RC Update Module and how it is handled at the module level for non I/O coprocessor autopilots.
Tested with an X8R (SBUS) and a Dragonlink (PPM) as well as a Dragonlink set to SBUS as the output. SBUS worked as intended. See screenshots below.
- always check with state machine before reboot/shutdown
- respect BOARD_HAS_POWER_CONTROL (shutdown from command, low battery, power button)
- px4_shutdown_request add optional delay and always execute from HPWORK
- px4_shutdown_request split out px4_reboot_request
- 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)
- 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
Daniel Agar
David Sidrane
Ryan Johnston
Beat Küng
Matthias Grob
Tanja Baumann
SalimTerryLi
mcsauder