embassy-stm32: i2cv1 may be prone to deadlock

[jamesmunns]

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.

Maybe related to #560 and #619.

[jamesmunns]

If you notice your I2C is hanging, check out the workaround from #2887, you might be able to clear the lockup by reinitializing the I2C peripheral.

[fmckeogh]

Would this apply to v2 (STM32F3)? I've been experiencing hanging only when using the async interface (#2884)

[jamesmunns]

@fmckeogh not sure! It would be worth it to check the errata list.

I haven't looked at V2, but V1 has had a couple of reworks to catch missed events (esp #2742), which might also be problematic in V2.