The ChibiOS 21.11.x merge dropped the rev X/Y conditionals upstream, which
left our STM32_ENFORCE_H7_REV_XY define a no-op on every H7 board that does
not set MCU_CLOCKRATE_MHZ 480. That silently disabled the errata 2.2.15 AXI
SRAM read corruption workaround and applied rev V only ODEN, CSICFGR and
ADC boost settings to rev X/Y parts.
stm32_clock_init() sets the ODEN bit in SYSCFG_PWRCR to put the core
into overdrive, which is required above STM32_SYSCLK_MAX_NOBOOST.
hal_lld_init() then reset every APB4 peripheral, and SYSCFG is on APB4,
so ODEN was cleared while the PLL kept running at the higher rate. The
core was left above its VOS1 rating with no indication.
The exclusion was already intended: the AHB4 reset above masks off
RCC_APB4RSTR_SYSCFGRST, but SYSCFG is not on AHB4 so it had no effect
there. On AHB4 that bit is GPIOBRST, which STM32_GPIO_EN_MASK already
covers, so that line is left alone.
Measured on an STM32H743 rev V at 480 MHz: SYSCFG_PWRCR reads 0x00
after boot without this change and 0x81 with it.
Picks up ArduPilot/mavlink commit 13f2f7351a which adds specific
failure reason enums to MAG_CAL_STATUS:
- MAG_CAL_FAILED_ORIENTATION (6)
- MAG_CAL_FAILED_RADIUS (7)
- MAG_CAL_FAILED_OFFSETS (8)
- MAG_CAL_FAILED_DIAG_SCALING (9)
- MAG_CAL_FAILED_RESIDUALS_HIGH (10)
These replace the previous MAG_CAL_BAD_ORIENTATION and
MAG_CAL_BAD_RADIUS entries with more granular failure codes.
Incorporates ArduPilot ChibiOS pulls #99 , #100, and #101 to fix issues
in the SD card drivers which can cause the flight controller to hang
(and subsequently watchdog) or the logging thread to fall asleep forever
and be unable to recover.
Both results can happen during flight. The former result happens on F4
and F7 only, the latter happens on H7 too. The issues are mostly
triggered by an SD card that is rapidly connected and disconnected, such
as vibrating in its socket, though random card communication failures
could trigger them too. They have existed for a very long time.
Testing was performed on Cube Black (F4), Pixhawk 4 Mini (F7), and Cube
Orange (H7). The issues were reproduced using an SD card extender, then
deliberately unlocking and carefully wiggling the flat flex cable. After
these patches, this can be done apparently indefinitely and the logging
thread always comes back and logging restarts after the SD card is
securely attached again.
Note that some boards are evidently vulnerable to this wiggling shorting
out the SD power rail and resetting the CPU too. Software can't fix
that, so vehicles with poor SD card connections need to be fixed
properly!
it was possible for a runtime allocated subscriber, client or server
to trigger a call to a pure virtual handle_message function in the
HandlerList class as the constructor ordering inserts the handler into
the list before the vtable pointer is updated to the vtable for the
child class. The same issue happens on destructor
this could happen in a couple of places in ArduPilot:
- the MPPT battery driver does runtime allocation of a client on an
R/C switch
- the DroneCAN_Serial client is started after the thread starts so
packet processing is started
thanks to Thomas and Sid
Fixes the following issues:
* Compound array elements subject to tail array optimization could be
decoded incorrectly, causing a decode failure.
* Invalid array lengths could be sent over the wire if a
longer-than-max array was encoded (though only the max number of
elements was sent).
* Lengths were not validated when decoding arrays of compound elements
using TAO, causing memory corruption if an invalid length was received.
* Union tags were not validated, causing undefined behavior if an
invalid tag was received.
Andrew Tridgell
Andy Piper
Christian Petri
Peter Barker
Julian
Thomas Watson
MattKear
bugobliterator
Iampete1
Tim Tuxworth
Tom Pittenger
Randy Mackay