nrf52dk_nrf52832 i2c clock pulse issue

[A.Danyadi]

Hi All,

My issue is may connected to

 TWI HW producing shortened ACK clock pulse 

I'm using:

• nRF52 DK dev. board
• nrf52dk_nrf52832_defconfig

//overlay

&i2c0 {
    appi2c: appi2c@8 {
        reg = <0x08>;
        label = "APPI2C";
    };
};

//compiled device tree

i2c0: arduino_i2c: i2c@40003000 {
	compatible = "nordic,nrf-twi";
	#address-cells = < 0x1 >;
	#size-cells = < 0x0 >;
	reg = < 0x40003000 0x1000 >;
	clock-frequency = < 0x186a0 >;
	interrupts = < 0x3 0x1 >;
	easydma-maxcnt-bits = < 0x8 >;
	status = "okay";
	pinctrl-0 = < &i2c0_default >;
	pinctrl-1 = < &i2c0_sleep >;
	pinctrl-names = "default", "sleep";
	appi2c: appi2c@8 {
		reg = < 0x8 >;
		label = "APPI2C";
	};
};

//source code
#include <zephyr/drivers/i2c.h>

#define APPI2C_NODE DT_NODELABEL(appi2c)
static const struct i2c_dt_spec dev_i2c = I2C_DT_SPEC_GET(APPI2C_NODE);

int app_i2c_transfer(uint8_t slaveAddress, bool read_write, uint8_t *data, uint16_t size)
{
  return read_write
             ? i2c_read(dev_i2c.bus, data, size, slaveAddress)
             : i2c_write(dev_i2c.bus, data, size, slaveAddress);
}

I get communication errors very several times. (More than 50%)

When the error occurs the first SCL impulse is half of the required. It's clear that at the beggining the slave is stretching the clock, but after releasing the master drives again too quickly.

The slave will nack the device address(0x08 in 7bit mode)

In 25% rate the communication is proper even to 256 bytes, but finally I got CRC error. For me this suggests that SDA is not sampled in the proper moment.

So my questions are:

• Does i2c driver api using a physical peripheral or emulates the lines by software?
• What kind of i2c errors can be detected by the api/driver? F.e. bus collision, timeout?
• What I do wrong, what I could do better?

Incidentally I use Texas Instrumet slave chip too (BQ76942) but I don't think it could be a problem.

It works properly with 3 other types of i2c master hardware:

• The original TI interface
• With an USB to I2C adapter controlled by .NET code
• With a Microchip PIC 8bit MCU

Thanks in advance,

Attila

[hmolesworth]

Too low a value of pull-up resistor leads to this phantom clock-stretching error, and the 'scope trace shows a very slow rise time from 10% to 90%. From the TI spec the max value of the pull-up is 1.5 kOhm, the nRF52 dev board is using a higher value (4k7 if I recall):

RPULLUP Pullup resistor(2) Pullup voltage rail ≤ 5 V 1.5 kΩ

[A.Danyadi]

Hi hmolesworth,

From one side you have the truth. The pull up resistor on the slave device to 3V is 3kOhm. (+paralell the 4k7 of the board) For EMC reasons, there is 0,25nF capacitor is on the lines. Alltogether it provides 3kR x 0,25nF = 0,75 uSec tRC (up to 63% of 3V).
The 1.5kR pullup resistance is the minimum not the maximum...
But still not explanation, why the i2c master makes impulse less than 5uSec which is expected @100kHz?

[hmolesworth]

Ah, agreed, I see the 1k5 is a minimum. I would suggest simply removing the 0,25nF while testing to be sure it is not causing a phantom clock stretch (which I think it is). Rise time to 90% (TI spec) is over 1,000nSec with the values you quote.

[A.Danyadi]

Hi hmolesworth,

Here I come with the test results after eliminating all capacitive elements and lowering the pullup resistors to the minimum 1k5 to reach the maximum rise speed.

Additionally collected some timing requirements of I2C slaves that are supported by nrf samples. 

Now @ 100kHz the clock rise time from 10% to 90% is ok: 600ns<1000ns, but because the first SCL impulse is often shortened (2.5-3us instead of 5us) the tHIGH is out of the most 100kHz device specifications. (2us<4us !) f.e. the TI BQ chip or LSM6DSO

It is a hw/sw bug not a phantom clock stretch

Nack situation:

After configured the BQ chip into tolerate high clock speed, but still using @100kHz the communication is of course proper (even if the rise time is out of spec.)

Testing the 400kHz mode of nrf52832 there is the same issue. Frequently can found SCL pulse less than 800ns without rise/fall time!

It's easy to imagine this being a problem at a 400kHz device, where tHIGH min is commonly 600ns.

So the question is still open. Is it possible to improve the driver or change some configuration?

Best regards,

Attila

[hmolesworth]

I accept your argument, but may I suggest disconnecting the SCL line from the BQ76942 slave - keeping the pull-ups unchanged - and capture the same traces you just posted. If the first clock pulse is still too short with the BQ disconnected then yes this is a nRF52832 hardware or software bug; if the first clock pulse is now normal then this is an unwanted clock stretch. If the latter then maybe this is due to some timing issue or start issue.

Either way we need some Nordic expert attention here :-)

As an aside, this trace shows something - maybe the BQ - is holding the SCK line low prior to the actual clock edges, and that something may be generating an unwanted clock stretch. Disconnecting the BQ might remove that suspiciously low SCK. If disconnecting the BQ CLK doesn't remove that suspicious low clamp to 0v then something in the nRF52832 hardware or software is incorrect

I should add that the problem caused by a phantom clock stretch - which would normally be benign - is TWIM errata 149 leading to a short clock pulse.

Edit: I though you were having issues reading the BQ, but "Incidentally I use Texas Instrument slave chip too (BQ76942)" implies it is actually a BH1749 that is being read, given that is the datasheet just posted? So for the test I propose SCL has to be disconnected from both slave parts.