HandFault exception in PROLOGUE of DMA1_Stream interrupt

[gicho]

I see sporadic hardfaults (STM32F4 target). The application is quite complex - it uses 3 UARTS to communicate to the outside world and to other modules, also monitors digital compass on the I2C bus and not-so-often accesses an SPI FLASH on SPI1 peripheral. In the meantime I use the ICU peripheral (on timer 5) to monitor external RF signal from 433MHz receiver. This signal is quite noisy and it triggers large number of interrupts at random time, something like 1000+ per second, while the period of the pulses (the noise) varies from 30 to 5000+ us. This ICU interrupt is currently the highest priority as it needs to capture the signals with us-level precision (well, 10..20us errors might be acceptable).

In this scenario I get sometimes hardfaults, and strangely I could not track back the original reason. I have seen the hardfault at least 50 times in recent weeks but once I got some more information from eclipse:
https://www.dropbox.com/s/jtcbgkidwre5vvg/Eclipse_HardFault_InDMA_IRQ_PROLOGUE.jpg?dl=0

Beside hardfaults, quite often I see the system "hanging" doing nothing - the user interface was running for some minutes or hours and at some point of time it does not run any more. If I pause the debugger I always see the I2C interrupt being active. No more tasks are running (that's why UI stopped) and the I2C interrupt retriggers forever.

Today I read about I2C problem and saw Giovanni's comment that I2C is problematic and it needs to run in highest IRQ priority:
http://forum.chibios.org/phpbb/viewtopic.php?f=16&t=2434#p19309

Maybe all this is related somehow? It is also possible that there are 2 separate problems (one for the I2C interrupt, e.g. some strange reaction from the slave and some error flag that is not correctly handled, and another for the hardfault?).
Could it be that I need to bring the I2C priority above this ICU interrupt? As long as it is not that long I could tolerate it - 20us will be acceptable and should not disturb the ICU receive state machine.

[Giovanni]

Hi,

Do you have debug options enabled in chconf.h?

The STM32 I2C is problematic, we implemented a lot of workarounds into the driver so it should be "safe" if configured correctly, highest IRQ priority for I2C is one of the workarounds.

Giovanni

[gicho]

Yes, all debug options are enabled. I will try the IRQ priority fix, if this doesn't help I will have to rewrite the I2C code using no interrupts (maybe libopencm3 driver or std lib ones).
Thank you for the hint, hope that the priority will help.

[Giovanni]

You could do software I2C easily.

Do you need to do the ICU capture at the same time of I2C transactions? you could suspend ICU momentarily then resume it.

If the ICU handler is short enough it is possible it does not interfere with I2C.

Giovanni

[gicho]

ICU handler is relatively short - there are no long running activities, just simple Manchester decoding, I think it is below 5us (@84MHz) in any case. But I cannot disable it.
There is an I2C thread that polls the ecompass chips every 20ms, it reads some 12-18 bytes in each transaction.
In parallel, the ICU callbacks are used to monitor the output of 433MHz receiver in order to react on messages from remote system. Those messages might come at any time and should not be lost.

For now I have increased the priority of the I2C interrupt and this seems to solve the problem (or it is so rare that I haven't seen it yet). But I saw another minor issues that I will post in a new thread.

Thank you again for great support!