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.

[hmolesworth]

Just in case the supply for the TWI slaves is different from the nRF52832, typically where slaves are powered from an nRF io pin, how long before starting the TWI is the supply to the slaves stable? Which supply do the TWI pull-ups attach to? Are any other i/o pins to the slaves driven high before the TWI supply is stable? If the supply is indeed separate, phantom power/back-drive issues may arise; ignore this comment if the supplies to nRF52832 and Slaves are the same.

[A.Danyadi]

Currently I only use the BQ76942 on the bus. I attached the other datasheets only for comparison and because some of those are included in the SDK examples...

I will make a trace when no slave is connected.

But as I read the TWIM errata 149 I think this is exactly my problem.

Just don't know how to ensure my chip is belongs to this? 
This anomaly applies to IC Rev. Engineering C, build codes CIAA-BA0, QFAA-BB0.

And don't know is it resolved at all or not and in which revision?

My hardware is the following:

The slave is a battery pack, it has own 3.3V regulator which provides the voltage for the pullup resistors. So the bus is pulled up from the slave side. The battery has an I2C connector with 3 short twisted wires. (yes I know it has extra capacity on the bus, but the batteries were manufactured more than 2500pcs and have no I2C issues with other masters) This I2C plug is connected to the nRF52 DK board.

About the clock stretching: The "suspicious low clamp to 0v" is the slave clock stretching after the start condition, what is not surprising and absolutely normal. The slave tells this way that it needs some time to prepare to receive the slave address then releases when ready. This is the moment when the nRF52832 generates too short (or longer) pulse.

On the previous figure from the ground level you can see whether the slave or the master is pulling down the clock. The difference in the low level can be attributed to the master's IO mosfet Rdson resistance or something else resistive element in the ground path. This shouldn't be a problem either, in fact some circuits, e.g. I2C isolators intentionally using this ground level shifting technic.

[hmolesworth]

Maybe try giving the BQ longer to get ready before starting a TWIM transfer. The odd thing is the other parts such as BQ76940 are not supposed to hold SCL low: "Does the BQ769x0 AFE ever drive the SCL line? No, it is a target device only and does not drive the SCL line. This device does not do clock stretching" see sluub41a.pdf

All variants of the nRF52832 have errata 149 issue, it was never fixed. The nRF52833 is a better choice, perhaps.

Hardware version and Production configuration is in NRF_FICR->INFO.VARIANT

Edit: Came accross this note: "The clock stretching on the BQ76952 cannot be disabled. Clock stretching is used on many devices. The BQ76930, BQ76940 family does not use clock stretching. The SPI is also an option for the BQ76952, although it is a little more complex" see bq76952evm-iic-scl-is-pulled-low