Calculate proper I2C SDA hold time

[dhalbert]

Instead of empirically determining the I2C SDA hold time, calculate the number of clock ticks to get the 300ns required value. See https://www.nxp.com/docs/en/user-guide/UM10204.pdf#page-48, table note [3] for the origin of the 300ns value.

The hardware default is 1, but that is arbitrary, since the length depends on ic_clk. 2 was enough to fix several I2C devices. 5 was need for PA1010D. However, the calculated value is 38 for 300ns. So the other values were quite marginal; this should be a lot safer.

Tested with PA1010D, LIS3DH, BME280, BNO055, and TCS34725.

These two traces show 5 vs 38. Note that the hold time applies only when SDA falls and SCL is high.

[jepler]

This makes real sense!

[lurch]

@dhalbert You might want to also delete .github/workflows/cmake.yml from your fork, in order to get rid of those "skipped checks" icons 😉

[kevinjwalters]

This is a far better approach than using a fixed value of 125MHz clock cycles (clk_sys) of the RP2040. That sounded very device specific and was going to do peculiar things for under/over clocking.

Note that the hold time applies only when SDA falls and SCL is high.

Isn't the requirement to have SDA held regardless of its value as SCL falls and the 300ns is the protection for that?

BTW, in your traces I don't understand what's going on around 6.3us (based on timescale at top). SDA is changing but it's nowhere near an SCL fall? Is that the slave NAKing? Is that trace with 400kHz requested and 10k pull-ups?

[kevinjwalters]

From a look at your traces changing this value does not appear to affect the SCL low time (based on i2c->hw->fs_scl_lcn) which is good from the point of view of not impacting the i2c clock speed.

[dhalbert]

Note that the hold time applies only when SDA falls and SCL is high.

Isn't the requirement to have SDA held regardless of its value as SCL falls and the 300ns is the protection for that?

It's described in terms of the falling edge; see the USB spec screenshot below. I was just emphasizing that it is only for the case when SCL is high, which addresses:

From a look at your traces changing this value does not appear to affect the SCL low time (based on i2c->hw->fs_scl_lcn) which is good from the point of view of not impacting the i2c clock speed.

Yes, it took me a while to find what was being lengthened in the trace, because it's a specific case of SDA and SCL.

BTW, in your traces I don't understand what's going on around 6.3us (based on timescale at top). SDA is changing but it's nowhere near an SCL fall? Is that the slave NAKing? Is that trace with 400kHz requested and 10k pull-ups

It might well be the NAKing, but I haven't tried to analyze that. The trace is 100kHz and 10k pullups.

[kevinjwalters]

Each clock cycle looks around 3us which makes it around 330kHz?

[dhalbert]

Each clock cycle looks around 3us which makes it around 330kHz?

Oh, yes, maybe you are right, I did test at 400 kHz as well. I took a lot of traces.

[tannewt]

I noted on the CP PR that this likely won't work for 1mhz I2C because the fall time for it is 120ns.