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]

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

[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

[PaKa]

The TWI on all the nRF52 and nRF53 series devices is the same so the behavior is the same for this specific item. For the nRF52832 this is given as an errata, for all the other devices this behavior is documented in the PSes.

[hmolesworth]

Ah, .. thanks paka for that information. So that means switching to the nRF52833 which we thought fixed all the documented errata on the nRF52832 (except for the 833 errata list) doesn't in fact fix them all? Do we have to search the PS for these, or is there a list which shows which of those errata are now considered "features"?

[PaKa]

So an errata is an item where the device doesn't work as shown in the specification. If the specification covers what the device does then you don't have an errata. You always need to read the PS to see how the part will operate. From the nRF52833 PS intro to the TWIM module:

Listed here are the main features for TWIM:

• I²C compatible
• Supported baud rates: 100, 250, 400 kbps
• Support for clock stretching (non I²C compliant)
• EasyDMA

and later:

This TWI master supports clock stretching performed by the slaves. The SCK pulse following a stretched clock cycle may be shorter than specified by the I2C specification.

[hmolesworth]

"then you don't have an errata" .. No, you have a hardware bug which should have been fixed. Items such as this will cause developers a lot of trouble; take the time spent on this case as an example. At the very least the documentation should show a trace of the shortened pulse to clarify the text.

This response is meant as helpful feedback.