cpu/sam0_common/periph_i2c: reliably unstuck bus

[maribu]

Contribution description

On a setup I have on my desk I can reliably get the I2C bus stuck. But the current unstuck logic will not get unstuck it. Adding a power cycle of the I2C bus to the unstuck logic does fix the issue, so let's do that.

Testing procedure

I2C should still work. E.g. as seen here on the same54-xpro:

> i2c_scan 1
2025-11-17 22:29:58,475 # i2c_scan 1
2025-11-17 22:29:58,477 # Scanning I2C device 1...
2025-11-17 22:29:58,483 # addr not ack'ed = "-", addr ack'ed = "X", addr reserved = "R", error = "E"
2025-11-17 22:29:58,487 #      0 1 2 3 4 5 6 7 8 9 a b c d e f
2025-11-17 22:29:58,491 # 0x00 R R R R R R R R - - - - - - - -
2025-11-17 22:29:58,495 # 0x10 - - - - - - - - - - - - - - - -
2025-11-17 22:29:58,500 # 0x20 - - - - - - - - X - - - - - - -
2025-11-17 22:29:58,505 # 0x30 - - - - - - X - - - - - - - - -
2025-11-17 22:29:58,510 # 0x40 - - - - - - - - - - - - - - - -
2025-11-17 22:29:58,515 # 0x50 - - - - - - X - - - - - - - X -
2025-11-17 22:29:58,520 # 0x60 X - - - - - - - - - - - - - - -
2025-11-17 22:29:58,524 # 0x70 - - - - - - - - R R R R R R R R

In addition, when the bus gets stuck, the current I2C transaction does indeed still fail. But subsequent transactions will work again.

In master using my cursed setup, the bus would stay stuck once it is stuck and never recover.

Issues/PRs references

None

[crasbe]

Would it make sense to alter the success variable if the bus-unsticking was successful?

Can't really comment on the function of the code, as I don't have the hardware nor experience with the SAM0 in general.

[maribu]

I think there are still some other factors that I do not fully understand yet.

[riot-ci]

Murdock results

✔️ PASSED

1b5be2e Update cpu/sam0_common/periph/i2c.c

Success	Failures	Total	Runtime
10932	0	10932	12m:52s

Artifacts

• Documentation preview

[maribu]

Would it make sense to alter the success variable if the bus-unsticking was successful?

Sadly not. When the bus got stuck, the I2C transfer failed. The I2C interface driver does not know how the failed communication can be fixed. E.g. i2c_read_reg() might be able to just retry by starting a new I2C transfer to read the requested register. But it is not clear if the interface is actually idempotent. Even a register read could change the device's state (even though that would usually be a sign of a poor interface).

In the end, only the device driver knows the exact communication semantics and could gracefully handle a failed communication. But each and every driver we have just passes on the buck to the application by reporting an error. That is usually good enough: Calling e.g. again some i2c_sensor_foo_read() should be good enough, even if the previous sensor read failed.

The goal of the bus-unstucking is to allow subsequent communication to succeed. If an app was designed with a noisy I2C bus in mind and actually retries on failure, it can then recover gracefully from the stuck bus situation without having someone to go on-site and power cycle the device.