I2C Communication Blocking Microcontroller

[AidenPrevey]

I am experiencing an issue where inconsistent wiring on an I2C bus causes my STM32F4 to deadlock. I was able to partially fix the issue by slightly modifying the attach method in i2c_transaction.cpp to also include a check for the error state in the first if (see below for the changes made to my code) along with adding deadlock detection to my RF calls. This has seemed to increase the reliability of the system, but now the system seems to get stuck in the I2C_EV interrupt handler. By probing the bus, I have both seen SDA and SCL staying low while the STM is hung, both without and with the internal pullups being enabled, respectively. Directly connecting those pins to +5v not through an external pullup pulls the device out of the interrupt loop. The wiring issue also sometimes causes the STM to experience a hard fault, but I haven't been able to track where the fault occurs yet, and I believe that it is related to the overall issue.

I am looking for either advice on what changes to make to my code to improve the reliability of my system, or if there are issues within modm's I2C handler that can be improved.

Code Diff.
The project is using the 2021q2 release of modm as an update to 2024q4 caused issues within our code when migrating to fibers. We hope to update eventually, but need more rigorous testing on our end. We are not against adding patches to our own branch. As far as I can tell, the only change to the i2c_master.<cpp|hpp> files is the addition of setting the ISR priority, which has a default of 10 in both places.

[salkinium]

Are you using internal pull ups only? Those are very weak (~50-100kOhm), it's possible that a I2C target is pulling too much current at some point and the lines stay low (~50-100kOhm on 5V is just ~0.05-0.1mA).
Can you retry this with ~5-10kOhm external pullups on the I2C bus?

The STM32 I2C peripheral respects clock stretching, ie. when the clock is held low externally, the peripheral just waits until it unfreezes. The SMBus includes timeouts for these reasons, but we haven't enabled that in our driver (yet?).

There is a modm::i2c::resetDevices function that get's called on initialize. It strobes the clock 9 times to try and get I2C targets unstuck. Not sure if it'll help for your problem (technically it deals with a different I2C bus problem).

Edit: You could also replace the I2C controller with a bit-bang controller to see if that improves things.

the STM to experience a hard fault, but I haven't been able to track where the fault occurs yet

You should be able to attach a debug probe and use scons debug to launch the GDB TUI. Then break HardFault_Handler to catch the hardfault and then do backtrace to see where it interrupted. Alternatively see the modm:platform:fault module.

an update to 2024q4 caused issues within our code when migrating to fibers

That's unfortunate, but you should still be able to upgrade by setting the modm:processing:protothread:use_fiber option to no. Might even still work for 2025q2.

[AidenPrevey]

Thank you for getting back to me so quickly. There are external 10kOhm resistors on the slave device's daughter board.

The SMBus timeouts seem to be pretty close to what I would be looking for; however, I'm using I2C fast mode, and the data sheet says that the SMBus only supports 100KHz. Would I be able to just use the timeout features?

With the clock-stretching, I know that for my problem, the I2C_EV is constantly called, and I should hopefully be able to work within that. (Call sw_reset after a timeout?)

[salkinium]

Would I be able to just use the timeout features?

I mean it's not implemented in our driver, so you'd have to write some code. Considering how complicated the I2C driver of the STM32 is, that could be quite a task.

I wonder if there's a interrupt source that we don't acknowledge in the interrupt. Have you done scons debug and put a breakpoint on the interrupt when it's stuck to inspect the registers?