convert RCOutput to new virtual timer interface
cope with SDC vs SDMMC
use new SPIv3 driver. Correct clocks for SDMMCv2.
add STM32L431 support
port ChibiOS config to version 8
support SPIv3 driver model v2 on H7
use currcore in debug options
use new mmc API
disable speed optimizations in the bootloader to save a little flash
upgrade to halconf v8.4
relax constraints on QSP/flash clock.
add support for disabling QSPI reset in main firmware
this fixes an issue where a variable in SRAM1 gets set to a bad value
when we reset AHB1 with the top bit (a reserved bit)
the bug was only reproducible with this particular commit:
https://github.com/tridge/ardupilot/commits/cubeorangplus-crash-boot-bisect
but likely is just luck that it triggered on that commit. In this
instance it triggered as AP_OSD::singleton was reset to non-nullptr,
causing a panic() in AP_OSD::AP_OSD()
compiler was gcc 10.2-2020-q4
this zeros-watchdog was caused by a SPI DMA error on STM32F405:
https://discuss.ardupilot.org/t/crash-with-4-2-0-beta-and-4-3-0-daily-bdshot/83297
we had incorrectly left these internal errors enabled when asserts
were not enabled. That led to a osalSysHalt()
without these we get an spi_fail internal error, caught by the
SPIDevice code
this fixes the flash re-init problem when flash storage fills on
H7. It was caused by rejecting writes where one or more of the 32 byte
chunks was not all 0xff but was equal to the current data. That
happens when writing to the sector header in AP_FlashStorage
it also moves the interrupt disable inside the loop to allow for
other interrupts to run between blocks
we have now shown that interrupts being enabled during flash
operations can cause the infamous "68ms" bug, or watchdog when using a
32 bit timer on boards using flash for storage
The issue is quite repeatable with a load of a very large waypoint
file (over 500 waypoints) using "wp ftpload" in MAVProxy. This puts a
huge load on flash storage.
Our current working theory is that while doing flash writes for
storage on dual-bank we block access to only one bank, so if another
thread uses a timeout function with a short timeout while the flash
write is happening and chVTDoTickI calls code which crosses the flash
bank boundary then it can cause chVTDoTickI to violate the assumption
that no more than CH_CFG_ST_DELTA ticks pass while it is calculating
the value to set in the system timer. In that case we get a delay of a
full timer wrap, which is 68ms on boards with 16 bit timer and 70
minutes on boards with 32 bit timer
hwdef for DevEBoxH7v2
pin definitions for STM32H750
add QSPI to DevEBox bootloader
add external flash to DevEBox
rename EXTERNAL_PROG_FLASH_MB to EXT_FLASH_SIZE_MB
Add support for EXT_FLASH_RESERVE_START_KB and EXT_FLASH_RESERVE_END_KB
Disable HAL_ENABLE_SAVE_PERSISTENT_PARAMS when there is no bootloader flash available
relax storage health status with SD card backend
don't check SD card health unless USE_POSIX
binary sections rearranged on external ram
manage RAMFUNC through ldscript and optimize function placement in external flash
inline timer functions
optimize placement of ChibiOS and functions in ITCM and AXI RAM
fix chibios features on bootloader build with external flash
change H750 memory layout
increase line storage for SD card based parameters
comment external flash linker script
move vtables into DTCM
update ram map for H757
enable crashdump support with external flash
correct bootloader pins and generator on SPRacingH7/DevEBoxH7v2
setup external flash reserve regions
allow different RAM_MAP for external flash on H750 and H757
this avoids an issue with the ChibiOS 20.3 virtual timer
implementation that can result in a scheduling slip equal to the
system timer period.
Andy has been suggesting this change for a while. I resisted it as I
thought it would impact on soft-serial parsing, but it turns out it
doesn't.
Fixes issue #18383
with the new ChibiOS revision we were configuring for newer revisions
of the H7, which meant that we changed the ADC config. This broke ADC
readings on revX and revY H7 MCUs.
This PR fixes it in two ways:
1) change ChibiOS config to assume XY config chips
2) use 16 bit ADC for H7, which means the chip rev doesn't matter,
and also gives us 16x the resolution for ADC readinga, so we can
read smaller voltage and current values
this takes better advantage of the new UART code. Log download over
USB gets to 730 kbyte/s. For comparison, with the 4.0 code on the same
H7 we get about 300 kbyte/s
this gains about 20k of RAM, and has almost no impact on log download
speed at 921600 on a F427. The improved threading means we can afford
to have smaller buffers
refactor rcout into separate thread and process all dshot requests there
move uart DMA completion to event model
process dshot locks in strick reverse order when unlocking
convert Shared_DMA to use mutexes
move UART transmit to a thread-per-uart
do blocking UART DMA transactions
do blocking dshot DMA transactions
trim stack sizes
cancel dma transactions on dshot when timeout occurs
support contention stats on blocking locking
move thread supression into chibios_hwdef.py
invalidate DMA bounce buffer correctly
separate UART initialisation into two halves
cleanup UART transaction timeouts
add @SYS/uarts.txt
move half-duplex handling to TX thread
correct thread statistics after use of ExpandingString
set unbuffered TX thread priority owner + 1
correctly unlock serial_led_send()
don't share IMU RX on KakuteF7Mini
observe dshot pulse time more accurately.
set TRBUFF bit for UART DMA transfers
deal with UART DMA timeouts correctly
don't deadlock on reverse ordered DMA locks
change PORT_INT_REQUIRED_STACK to 128
Adjust SRAM1+SRAM2 to 256k as describe in the H743 reference manual
Provide access to mem_info() information
Co-authored-by: Andrew Tridgell <andrew@tridgell.net>