this affects boards that share sdcard on the same bus as another SPI
device. In this case it was a QiotekZealotH743 where logging stopped
this issue is that the SPI hooks for MMC SPI did not do a DMA channel
lock before the SPI device lock. So when the RAMTRON driver on the
QiotekZealotH743 which is on the same SPI2 bus as the sdcard did an
operation we had a lock order violation
use regular ChibiOS RAM areas for RAM functions
exclude board.o from RAM functions and add some comments
use separate linker script for H750
use correct RAM area for process stack on H750/H743
update EXCLUDE items to put __early_init in flash on H730 and H750
optimize H730 ramfunc usage
correct calculation of advanced timers
add support for linker script configuration in mcu config script
use linker script configuration for H750 and H730
add single OTG_HS support on H730 via OTG2
make sure complimentary channels get advanced timers
complemntary timers do not require advanced mode
allow custom clockspeeds of 550Mhz
correct debug pins on H730
support custom clockrate of 520Mhz on H730
correct H730 USB end point pins
restructure linker script for STM32H730
allow chibios_hwdef.py to set advanced timer on L431
don't define RAMFUNC on STM32H730
clock tree for STM32H730
create non-cacheable memory area for SDMMC DMA
don't look for RAM_MAP in bootloader with external flash
this was already done on many (most?) boards, and greatly reduces DMA
sharing which improves performance of UARTs. This changes the default
to no DMA on I2C
Added support for stm32l4+ processor
- Added scripts for hwdef generation
- Tested in custom hardware prototype (stm32l4r5vit6)
- Tested all peripherals and auto pilot modes.
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
Peter Barker
Andrew Tridgell
Andy Piper
bugobliterator
tsubashmail@gmail.com
Ryan Friedman
Kirill Shilov
Lokesh Ramina
Nick Exton
Michael Oborne