Lpi2c issues

[vignesh3]

Hi everyone,

I am facing issue with this line of code,

/* Check which event caused the interrupt */
if (LPI2C_Get_MasterTransmitDataRequestEvent(BaseAddr))
{
/* More data needed for transmission */
if (!Lpi2c_Ip_MasterCmdQueueEmpty(Master))
{
/* If there are queued commands, send them */
Lpi2c_Ip_MasterSendQueuedCmd(BaseAddr, Master);
}
else
{
MasterCmdQueueEmpty = TRUE;
}
}

This LPI2C_Get_MasterTransmitDataRequestEvent(BaseAddr) should return true but if i2c is reading for 5-10 minutes then this function always return false after that no more communication happens.

[vignesh3]

Hi @danielmartynek and @Erica407Den ,

How can I check that SDA line pulled low by MicroController or slave devices?

And I have confirmed that SDA line is being pulled low by using Logic Analyzer.

[danielmartynek]

Hi @vignesh3,

Can you measure the bus with an oscilloscope?

Is the SDA line kept low by a slave device on the bus?

If so, refer to UM10204 I2C-bus specification and user manual

https://assets.nexperia.com/documents/user-manual/UM10204.pdf

An example is in AN4803 I2C Non-Blocking Communication

tI2C_fault I2C_Restore(void)

https://www.nxp.com/docs/en/application-note/AN4803.pdf

Regards,

Daniel

[vignesh3]

Hi @danielmartynek ,

How can I do the cycle power reset?

[vignesh3]

If the data line (SDA) is stuck LOW, the master should send nine clock pulses. The device
that held the bus LOW should release it sometime within those nine clocks. If not, then
use the HW reset or cycle power to clear the bus.

How can I send the 9 clock pulses, I am using S32K322 MC.  

[danielmartynek]

Hi @vignesh3,

The RTD I2C drivers do not have such a function.

You would need to do it using the the Port/SIUL2 drivers.

That mean you need to reconfigure the SCL pin from LPI2C to GPIO and toggle it.

Refer to in AN4803 I2C Non-Blocking Communication

There is a pseudo code that does that.

tI2C_fault I2C_Restore(void)

https://www.nxp.com/docs/en/application-note/AN4803.pdf

Regards,

Daniel

[vignesh3]

Hi @danielmartynek ,

Here the application note says when ever I2C_TIMEOUT fault flag sets at the time it is generating 9 clock pulses right, still do I need to externally generate that 9 clock pulses?

The I2C_TIMEOUT fault flag is set, when the I2C_BUS_BUSY fault persists more than 150 µs (number determined as double of longest I2C message). The message transfer is not completed and the bus is still in busy state because the data transmission on the I2C bus is affected by the noise. Timeout feature prevents processor to stick for ever when this condition occurs on the I2C bus. After the timeout fault occurs, the software disables the I2C module and sends nine clock pulses followed by NACK and the stop signal.

[danielmartynek · Accepted solution]

Hello @vignesh3,

Yes, you need to reconfigure the pin to GPIO (disable LPI2C) and toggle it, the implementation is down to you.

To power cycle the I2C Slave, you have to power it down.

[vignesh3]

Hi @danielmartynek ,

Thanks for the reply.

Siul2_Port_Ip_Init(NUM_OF_CONFIGURED_PINS0, g_pin_mux_InitConfigArr0);

In this, I am initializing all the pins.

It is generated code by the S32DS tool, So in between I need to initialize I2C clk as GPIO, Can I use generated code or Do I need to modify this g_pin_mux_InitConfigArr0 structure or Is there any alternate way for this?

[danielmartynek]

Hello @vignesh3,

Have a look at the APIs in 

Siul2_Dio_Ip.h

Siul2_Port_Ip.h

If you have any specific question about Siul2, please create a new thread.

Thank you

[vignesh3]

Thanks @danielmartynek , I will check on that.

[vignesh3]

Hi @danielmartynek and @Erica407Den ,

How can I check that SDA line pulled low by MicroController or slave devices?

And I have confirmed that SDA line is being pulled low by using Logic Analyzer

[danielmartynek]

Hi @vignesh3,

I don't think it the LPI2C Master that drives it low.

Anyway, you can simply disconnect the SDA pin from the LPI2C module in SIUL2 (in the MSCR register of the pin).

Then, the pull-up resistor should pull SDA to VDD unless it is driven by a slave device connected to the bus.

[Erica407Den]

Hello!

The issue where LPI2C_Get_MasterTransmitDataRequestEvent(BaseAddr) returns false after 5-10 minutes of continuous I2C reading could stem from I2C bus problems (clock stretching, noise, slave issues), the LPI2C peripheral entering an error state (missed ACK, timeout, FIFO issues), or subtle problems in the software handling of interrupts (flag clearing). Debugging steps include implementing error handling, monitoring bus signals, checking the LPI2C status register, reviewing timeout configurations and slave device documentation, simplifying the test case, introducing delays, and verifying clock/power stability. The key is to identify if the bus is failing, the peripheral is erroring out, or the interrupt flag isn't being correctly managed over the extended read period.