Master I2C Bus Busy

[mspenard603]

Occasionally I see LPI2C_MasterGetStatusFlags() report Bus Busy even though SDA and SCL are high. What would cause this? And, how do I recover from the situation? As I tried to re-init I2C but it still reports bus busy.

[mspenard603]

I've been seeing issues myself of late. Since upgrading from SDK 2.5.1 to 2.12.1. RX and TX timeouts with the bus reporting busy. And I'm not seeing such on my scope.

[mspenard603]

Yes, I've been reading through that. I tried bit-banging clock cycles via GPIO as suggested someplace. Then doing an I2C_MasterInit() and a ClearFlags() but this doesn't clear the Master Bus Busy MBF bit. How do I clear that bit?!

[igorpadykov]

Hi mspenard603

for recovering i2c one can look at hints provided on

https://community.nxp.com/t5/i-MX-Processors/I2C-reset/m-p/253182

Best regards
igor

[mspenard603 · Accepted solution]

Got it. You use I2C_MasterReset() which sets the software reboot bit in MCR. Which then clears Bus Busy bit in MSR.

And you have to call I2C_MasterReset() before doing a I2C_Init()

[ping1]

Hi, 

I have same problem.

But inside LPI2C_MasterInit(),  LPI2C_MasterReset(base) is called first. Not sure why should user call it again. The problem for me is that after calling LPI2C_MasterInit, the bus flag set to busy. Can I call reset afterwards?

Regards!

Ping

[jamesk]

I understand the suggested approach is a workaround to the issue.

Does anyone know why occasionally LPI2C_MasterGetStatusFlags() reports Bus Busy even though SDA and SCL are high?

I also see this often enough on our dev. product which is built on using NXP iMXRT 1052.

Should this be considered as a NXP driver bug?

[p_shep]

Finding this as well.

Transfer 'fails' returning bus busy, however the lines are high in between transactions as seen by a scope, and actually the transaction on the line completes properly - well, as far as the code allows since the driver is saying the transaction failed.

It also seems that once it's in this state, is can't recover on it's own. In that it's not just the occasional transaction, once it happens, it returns bus busy for ever.

[p_shep]

This is a problem.

The suggestion of calling master reset, then re-initialising the bus isn't helping. The driver is still returning bus busy after resetting when both IO line are clearly high.

[p_shep]

And if I step through the code with a debugger, the busy flag magically disappears and it starts working again