I2C stall during ACK low period(SCLK is low, SDA is high)

[yihe_zuo]

Hi all,

We used the below API for I2C read and write operation.

lpI2Cstatus = LPI2C_DRV_MasterSendDataBlocking(I2C_INSTANCE, I2C_temp_id, 1u, (bool)false, 2);

lpI2Cstatus = LPI2C_DRV_MasterReceiveData(I2C_INSTANCE, masterBuffer, bufSize, (bool)false);

when we set the baud rate with 400kbits/s , there is 25us delay during the I2C slave register read operation.However, when we set the baud rate with 200kbits/s, there is no delay. 

the operation sequence is : slave address+register address(write operation)/ +slave address+register value(read) response from slave node.

May we know the reason?

It will be appreciated if any ideas.

The HW is based on S32K144 ECU.

[yihe_zuo]

In addition, may we know if LPI2C supported the clock stretching in master mode not slave mode?

if yes, when is it triggered?

[danielmartynek]

i @yihe_zuo,

Yes, the master can also stall the bus (stretch SCL):

That would mean the transmit FIFO is empty after the slave address is sent, and the bus is stalled while the LPI2C master is waiting for the next command with the register address.

Can you increase the CORE/BUS clock frequency to test it if this is caused by SDK overhead?

Regards,

Daniel

[yihe_zuo]

Hi Daniel,

We consulted with our slave device supplier (TAS5760 Amplifier) that it didn't support clock streching. 

In the slave device datasheet, it is mentioned that it also can support by 400kbits/s.

our HW pullup resistors is designed with 10K for SCLK/SDA line.(it is designed to support 100kbits/s).

Based on the info, is it possible if the delay is caused by master operation LPI2C from NXP S32K ? If yes, which conditions can trigger the 

results? if no, may we know why?

[danielmartynek]

Hi @yihe_zuo,

This an expected behavior as per the I2C specification and user manual (UM10204):

https://www.nxp.com/docs/en/user-guide/UM10204.pdf

Regards,

Daniel

[yihe_zuo]

Hi daniel,

Thanks for your kind support.

From the attached picture, the SCK is pulled with low status after NACK bit(in the normal I2C standard, it should be high to indicate that the bus is idle )

May we know what kind of driver setting in the S32 can lead to this kind of setting?

in our I2C Read/write setting, the stop bit is disabled to be sent in the bus.

looking forward to your reply soon.

[danielmartynek]

Hi,

In this picture, the SCL line is pulled low by the Slave device.

The Master is busy until the Stop bit is sent.

S32K1xx RM:

In the images you posted, the SCL line is also low.

So, I have difficulties to understand what you mean.

Regards,

Daniel

[yihe_zuo]

From the slave device TI feedback, they don't support clock streching.

That's the reason I asked if there are any special handling from NXP HW or/and driver on 400Kit/s.

[danielmartynek]

Hi @yihe_zuo,

As I already mentioned in the thread two weeks ago, it could be because of CPU overhead caused by the implementation of SDK the driver.

I don't think this has something to do with the LPI2C HW.

As I wrote, you can change the system frequency and if it is because of the overhead, you should see different delay.

Also, you can use the simple non-SDK example S32K144_Project_LPI2C

And create a simple LPI2C receive function, and then you should see no delay.

This example can be helpful as well:

https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K144-I2C-Master-MPL3115A2-S32DSR1-v3/ta-...

Regards,

Daniel

[yihe_zuo]

Thanks for the prompt reply.

The bus clock for I2C is already set with 37Mhz which is almost to the maximum limit 40Mhz when PLL is used.

If so , does it mean the SDK driver won't support 400kit/s?

How should we use the below code and SDK driver? which one can be for official use?

[danielmartynek]

Hi @yihe_zuo,

The LPI2C module is Fully-Functional in HSRUN.

And the BUS_CLK can be up to 56MHz in HSRUN.

You should see a significant difference at 56MHz BUS_CLK.

Also, the driver uses interrupts, so you can set the highest interrupt priority to LPI2C.

I'm afraid you can use either the SDK or your own implementation without SDK.

And the two non-SDK examples should help you.

But the example I linked is just a simple example for your reference, it is not an official driver.

Regards,

Daniel