i2c bus clear #1595

New issue

Open

opened 2023-12-27 03:00:22 -06:00 by PepperoniPingu · 1 comment

PepperoniPingu commented

2023-12-27 03:00:22 -06:00

(Migrated from github.com)

Hi!

I have some software that is using i2c for the rp2040. Over a couple of months of continuous running there have been some failed transactions. Since these are rare, and, our i2c waveform is not too pretty when looked at with an oscilloscope, I presume my hardware implementation is at fault. Nevertheless it would be nice to try to properly recover from these crashes with an i2c bus clear sequence (a.k.a. software reset). To do this you simply send 10 negative pulses on scl. The purpose is to clock out potential data that is stuck in the output register of peripherals.

I suggest adding a standard method to do this, e.g. i2c_clear_bus();

The datasheet states in 4.3.13 that the i2c hardware block has a bus clear feature. But this seems not to be the case as discussed here.

I see two ways of solving this:

Bit banging
- Requires reconfiguring pins
- Like this
Sending out a read request to 0xFF
- This will also send start and stop conditions. A stop might be nice but not sure if the start is good or bad thing.

Thoughts?

Hi! I have some software that is using i2c for the rp2040. Over a couple of months of continuous running there have been some failed transactions. Since these are rare, and, our i2c waveform is not too pretty when looked at with an oscilloscope, I presume my hardware implementation is at fault. Nevertheless it would be nice to try to properly recover from these crashes with an i2c bus clear sequence (a.k.a. software reset). To do this you simply send 10 negative pulses on scl. The purpose is to clock out potential data that is stuck in the output register of peripherals. I suggest adding a standard method to do this, e.g. `i2c_clear_bus();` The datasheet states in 4.3.13 that the i2c hardware block has a bus clear feature. But this seems not to be the case as discussed [here](https://github.com/apache/nuttx/issues/4746#issuecomment-962454952). I see two ways of solving this: - Bit banging - Requires reconfiguring pins - [Like this](https://github.com/apache/nuttx/pull/4786) - Sending out a read request to 0xFF - This will also send start and stop conditions. A stop might be nice but not sure if the start is good or bad thing. Thoughts?

lurch commented

2023-12-27 05:58:04 -06:00

(Migrated from github.com)

The datasheet states in 4.3.13 that the i2c hardware block has a bus clear feature. But this seems not to be the case as discussed here.

Also discussed in https://github.com/raspberrypi/pico-feedback/issues/199

> The datasheet states in 4.3.13 that the i2c hardware block has a bus clear feature. But this seems not to be the case as discussed [here](https://github.com/apache/nuttx/issues/4746#issuecomment-962454952). Also discussed in https://github.com/raspberrypi/pico-feedback/issues/199