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]

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

[A.Danyadi]

The slave is BQ76942 not BQ76940. Very different. And BQ76942 needs and does clock stretching.

BQ76942 Technical Reference Manual

BQ769x2 Software Development Guide

BQ76952EVM: IIC SCL is pulled low

Setting this below can reduce the clock stretching events, this way the error ratio is about 10%. 

I'm sad to hear that errata 149 has never fixed. I consider this is the answer for the ticket.
Maybe it is related to Arm Cortex-M4 CPU?
Can I expect the same problem if I use the nRF52805?

Update: the clock timing is perfect if there is nothing on the bus.

[hmolesworth]

Looks good; the errata 149 applies only to the nRF52832 peripheral as far as I know, not related to the Cortex-M4, since the issue was not reported on 52840, 52833, 52805, 52811. nrf52805 errata