LPC55S69 I2C stuck after SCK disconnect/connect

[Fastfox]

Hi,

I accidentally found a way to get I2C stuck and so far could not find a solution for it. Hope someone can give some hints.

• LPC55S69 Evaluation board
• SI7055 I2C temperature sensor connected to FC2
• Using NXP I2C driver and freeRTOS on top of those

Case if fairly simple. Temperature measurements means that we write one byte to sensor, wait for a while and read result.

I noticed that if I disconnect SCK wire, temperature reading(I2C write) fails(naturally). If I then connect SCK again and try to read temperature, I2C write never returns. Bug is in MCU side, sensor does not keep lines down or anything.

What I have found out so far is that in RTOS driver level it does not return because NXP driver never calls the `I2C_RTOS_Callback` given to `I2C_MasterTransferCreateHandle`. In NXP level it hangs because `I2C_RunTransferStateMachine` called by `I2C_MasterTransferHandleIRQ` is called only once(`kStartState`) and then nothing. I2C also sends nothing to lines when it gets stuck(checked with scope)

I have tried to eyeball and debug the driver code, but it looks solid to me. I am suspecting that maybe the actual I2C peripheral is somehow messed up.

When I disconnect the SCK, I can see following events in NXP I2C driver(I2C_RunTransferStateMachine)

status=5244961, state=6(kStartState) -> result=0
status=5245025, state=2(kTransmitDataState) -> result=2608(kStatus_I2C_StartStopError)
// RTOS callback called -> error returned to application

And after this next write is just

status=5244961, state=6 -> result=0

//Stuck

For reference, if I disconnect SDA wire, writing the byte fails like this:

status=5244961, state=6 -> result=0
status=5245057, state=2 -> result=2611(kStatus_I2C_Addr_Nak)
// RTOS callback called -> error returned to application
status=5244961, state=0 -> result=2609(kStatus_I2C_UnexpectedState)

After this I2C is working just fine and interrupts from I2C are coming through if I connect the SDA again.

[frank_m]

I think the problem is your external I2C device, the SI7055.

Most I2C devices are static designs, i.e. have static state machines. If you interrupt a read or write transfer in the middle (not all 9 bits transferred), it gets stuck in that state machine.

The usual way to resolve this is to reconfigure the I2C pins as GPIOs (with OD), and pulse SCL until SDA is released.

Or, a power cycle that resets both master and slave node. Or, hypothetically, you could powercycle the slave alone.

[Fastfox]

Hi frank_meyer,

I think the problem is your external I2C device, the SI7055

I have already tried to confirm that this is not the case this before contacting you. There are two things that hint the opposite IMHO.

Bug is in MCU side, sensor does not keep lines down or anything

and

I2C also sends nothing to lines when it gets stuck(checked with scope)

I have also tried to e.g. power cycle the sensor, but it is still in initial state(does nothing, does not draw the lines)

[frank_m]

Ok if you are aware of this point.

I would make a trace of of the I2C bus, covering the failing transfer and preverably a few transfers before. And check where exactly the problem happens, and relate it to your (or the SDK) code.

Perhaps experimenting with different (lower) SCL speeds, pull-up resistors, and boards.

[Alice_Yang]

Hello Fastfox,

Yes, I also meaning deinit and init after stuck. What about other 50% time, do you mean even thought deinit/init, it still can't communicate with I2C salve?

BR

Alice

[Fastfox]

Yes that is what it means. 50% of times after deinit/init, no interrupts coming from I2C.

[Alice_Yang]

Hello Fastfox,

How about restart I2C after stuck.

BR

Alice

[Fastfox]

I have tried to abort/deinit/init after the failure(i.e. not after it is stuck). It seems to help maybe 50% of time. "Help" meaning that it does not get stuck when used for the next time.

I have not tried to recover from stuck I2C as it is a bit complex. You would need to kill/restart RTOS task, RTOS driver sempahores and stuff.