Description
As of 2023-12-28, the STM32 driver for I2Cv1 (STM32F1, STM32F2, STM32F4, STM32L1) leans heavily on interrupts, as this is how i2cv1 was designed to be used. In multiple places, there's a process that goes roughly like this in thread mode:
- Set waker
- enable interrupts
- poll-fn loop to check events/errors:
- if error, return Err
- if done, continue on to the next step
- if not done or error, return Pending
In the interrupts, we do something like:
- Check and store events/errors to a static
- disable interrupts
This makes interrupts essentially a "oneshot". BUT! If we got an interrupt, BUT the event/errors we care about weren't active (due to some race condition? Unclear as of now), we never re-enable the interrupts, which means that the pollfn hangs as it is never awoken again.
#2364 fixed one specific case of this, but it's not clear today whether that should be applied to ALL patterns in i2cv1 that use this oneshot interrupt pattern. It might be okay to just add that everywhere! But nobody has had time to dig into that or make a case one way or another.
Until someone digs into this, this issue exists to document "hey this is maybe weird heads up", and will be linked into the code.
If you notice async I2C is hanging
Congratulations! You are a good candidate to investigate! See where the I2C is hanging, and see if applying a similar "enable interrupts" call like in #2364 helps. If so, please open a pull request.