RP2040 I2C_RESET

[vxj9800]

I have been working on adding RP2040 hardware support to PX4-Autopilot which uses Nuttx as the RTOS. The only thing missing in this PR right now is the I2C_RESET.

The datasheet of RP2040 states that the MCU has Bus Clear Feature (Page 478) which can handle the problem of SDA stuck to LOW. Thus, it makes sense that the rp2040_i2c_reset() function in rp2040_i2c.c file just returns OK since the hardware is taking care of the problem automatically, I presume.

I would like to know if I am thinking in the right direction or not. If yes, then I think the rp2040_i2c_reset() should rather return the state of the bus, that is whether it is stuck or not. This way, the i2c implementation of PX4, or any other app for that matter, will know whether the bus clearing attempt was successful or not. Then select ARCH_HAVE_I2CRESET could be added to the Kconfig file to allow defining CONFIG_I2C_RESET. It is important to define CONFIG_I2C_RESET since a some parts of i2c implementation in PX4-Autopilot depends on this.

[xiaoxiang781216]

@yunkya2 do you have any suggestion?

[davids5]

What is unclear to me is if 4.3.13. Bus Clear Feature, can be requested via a command register. If it can be, that is what should be defined as the reset function. If not, since the CONFIG_I2C_RESET interface is optional and in this case not needed. What about not having the CONFIG_I2C_RESET option in the Kconfig?

[vxj9800]

@davids5 I also had the same question regarding how to initiate the bus clear process. Surprisingly, the datasheet does not provide any explanation on how to do that nor any of the I2C registers have anything related bus clear to my understanding. I am presuming that the MCU somehow detects that the SDA line is stuck to low and automatically initiates the Bus Clear process.

[davids5]

@vxj9800 - you could try to ask Synopsis or look as some other i2c drivers like xtensa, esp that have something similar but I have no clue if it is the same IP.

[Ouss4]

ESP32-C3 has a hardware reset option. There are a couple of registers to write to in order to initiate the procedure.
https://github.com/apache/incubator-nuttx/blob/master/arch/risc-v/src/esp32c3/esp32c3_i2c.c#L1138-L1160

[yunkya2]

I have developed the driver by referring the cxd56's implementation because I found that both SoC have same I2C IP.
As @vxj9800 points out, there are no further descriptions about the Bus Clear Feature in the datasheet and I have no information how this feature works.
@Ouss4 ESP32_C3 seems to have a different I2C IP because the register defintions in hardware/esp32c3_i2c.h is different to RP2040's one.

[Ouss4]

Yes, I'd actually be surprised if they had the same IP, I just wanted to mention that this feature exist on ESP32-C3.

In any case, if there are no information for the RPi it can be done in software like most of the other chips.

[yunkya2]

I think so, too. Let me try it.

[yunkya2]

I have incorporated the bus recovery sequence like another I2C_RESET implementation and issued PR #4786.
The code sequence seems to be working as expected, but I cannot confirm whether the sequence recovers from the bus stuck condition because it is difficult to reproduce.

[vxj9800]

An update on the existence of I2C Bus Clear feature on the hardware side. It is discussed in the documentation of the RP2040 but is not active in the silicon as per the discussion on the pi pico forum and as per the issue raised on github.

[yunkya2]

@vxj9800 Thank you for the interesting information. I understood that our only choice is the software solution like #4786.