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

[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