SC18IS600 Status stuck on BUSY F3 even though I2C lines are free

[dbatt]

For those not familiar with the SC18IS600, it is an SPI to I2C-bus interface chip. I am using a MPC5643L Microcontroller.

I am reading and writing to several different i2c slave addresses using write N bytes, read N bytes and read buffer commands. This works successfully for some time and I can verify each message is being sent correctly multiple times.

After some time the check status command starts only returning a busy status (0xF3 indicating that the i2c bus is busy), but when I probe the i2c bus with an oscilloscope, the sda and scl lines are both high indicating that the bus is free and not busy.

I set a breakpoint on the slave device at the very top of the i2c interrupt and once I get stuck on F3 busy status I no longer receive any more i2c interrupts. (The slave i2c timeout interrupt is still working). 

I've tried almost every command possible on the SC18IS600 to try and break out of this state but nothing has worked. My next thought is to hard reset the SC18IS600 whenever this happens but obviously that is not ideal.

I have written to the SC18IS600 internal i2c timeout register however I am not receiving any F8 timeout statuses that I know of.

Any help is much appreciated and let me know if there's any more info I can give.

Thank you!

[dbatt]

The forced stop bit in software was a clever solution however I personally couldn't get it to free up the bus. I resorted to placing a jumper from a free GPIO pin to the ic's hardware reset pin (which wasn't being used before). I also slowed commands down as much as possible. When I receive multiple busy signals in a row I pulse the hardware reset then try the transmission again and this fixes the problem very quickly.

Thanks for everyone's input and if you think there might be a better solution don't hesitate to chime in!

[dbatt]

Thank you both for the help.

The data and clock lines were indeed going high but not in the right order to be a stop condition. My master processor can only access i2c through this IC but I was able to have my slave manually pull down the lines to  send a stop bit after a long timeout.

Here is a probe of that condition: (occurs after 12 seconds with no i2c interrupts to the slave)

(is this sufficient as a stop bit condition? - see cursors for timing - note this is by itself and not at the end of any a frame)

Assuming the above is a valid stop condition, I keep trying to write bytes then check the status but I continue to get only F3 busy.  

The line voltage levels look great as does the signal integrity. I also slowed down the I2C clock and am only sending one command every 10ms. I don't want to have to reset both devices every ~30 seconds, so I'd really like to get to the bottom of this. 

Any input is much appreciated!

[Lorenzo_Mch_IT · Accepted solution]

The busy bit is set when a start condition is detected and cleared when a stop condition is detected.

Even if both SDA and SCL lines are high, it may happen that they didn't get to that state via a stop condition,  for example when data is sent but because of glitches in the bus or the operation being aborted, no stop condition is sent at the end of the frame.

The solution is either to force a stop condition (if the i2c master interface is on a microcontroller with I2C mapped on GPIO pins, you usually reconfigure SDA and SCL to GPIO, and bit-bang enough clock cycles to complete a read from slave or bit-bang a stop and then reconfigure the pins to I2C usage) or to reset both SC18IS600 and the slave device it was communicating with (it's the only way to be certain they are both back to a valid internal status.

In this case it seems a reset is your only option.

Also check line voltage (if it's too low) and signal integrity (if there is noise that may cause glitches) and if you are sending too many requests to I2C (i.e. if you send another command before the previous one has completed), the datasheet is not clear about what happens if you do that, maybe the I2C request in progress gets interrupted abruptly and I2C communication gets stuck.

[guoweisun]

I will send to your sample source code for reference.