Preventing interrupt storms on STM32

[Giovanni]

Is the SW able to keep the vehicle flying in case of a watchdog reset? (by keeping the last state safe or something else of this kind).

Giovanni

[tridge]

Is the SW able to keep the vehicle flying in case of a watchdog reset?

not for quadcopters. For a fixed wing aircraft we are able to restore enough to fly, and we have successfully demonstrated that:
https://www.youtube.com/watch?v=ZGuTIPLI_e0
(video is in Italian)
for safety reasons we don't re-arm a quadcopter after a reset as we have no way of knowing if the vehicle is close to people. If you are flying high enough then you could command a re-arm and recover a quadcopter, but in practice (at legal heights) you won't recover before hitting the ground.

[tridge]

I've looked into why the timeout for I2C didn't save the vehicle, and it is pretty obvious. A timeout of osalThreadSuspendTimeoutS() will just activate the calling thread, but that thread will never get scheduled if an ISR is pending. So timeouts for peripherals don't work for the case of interrupt storms.
If we want to fix this then we could check if the thread is runnable in the ISR and if it is then do a RCC reset and (optionally) do _i2c_wakeup_error_isr(). Or we could just apply the ISR limit patch.
I'm now thinking that the ISR limit patch, or something equivalent, should be enabled by default.

[tridge]

It turns out this fix also fixed another long standing issue we've been chasing, which is lag on a uart gimbal on the Solo. The lag was caused by corrupted bytes on the uart due to the high ISR latency caused by the i2c interrupt storm on each i2c transaction. At 230400 baud we need to handle bytes every 43usec for non-DMA uarts, but as the i2c isr is higher priority than uart isr we dropped bytes, which corrupted comms, which caused gimbal lag
Unfortunately we can't use DMA for that uart due to conflicts with DMA on SPI and I2C
so a two-for-one fix

[Giovanni]

Fixed the BTF clearing as bug #1045.

I am still looking into implementing that "IRQ storm" handling concept.

Giovanni

[tridge]

Fixed the BTF clearing as bug #1045.

thanks!

I am still looking into implementing that "IRQ storm" handling concept.

ok, thanks. If you need anything more from me on that then let me know. We've been running it for a while now and it is nice to know that if we do find another similar bug then it won't lead to a complete lockup.
Cheers, Tridge