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?

[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.

[A.Danyadi]

Hi guys and all the subscribers,

It is not worth arguing about what is documented and what is not.

The facts are as follows:

• slave using clock stretching 
  • desired frq = 400kHz
    TWIM unusable
  • desired frq = 100kHz
    • slave doesn't support high clock frq (400kHz)
      TWIM unusable
    • slave supports high clock frq (400kHz)
      clock frq must limited to 100kHz
      
• slave doesn't using clock stretching
  No issue

Slowly after the first quarter of the 21st century, clock stretching is not a magical thing.

In the beginning, I used Dialog Semiconductor's (now owned by Renesas) BLE module.

I was fed off:

• weak intelligence of KEIL IDE
• hard to install the development environment
• hard to find documentation
• weak support
• the I2C peripheral was prone to freezing (may be attributed to the Cortex M0 processor?)

On the other hand, I like Nordic Semiconductor

• VS code is a perfect IDE (IntelliSense etc.)
• good documentation
• good support
• Zephyr RTOS