I2C Bus error handling

Hello,
I have a functionnal I2C Bus except sometimes i have a lockup problem (one of the slave holds SDA low).
After looking for a solution on different website, I found this :

In this scenario the external slave might be holding SDA low to transmit a 0 (or ACK). In this case it will not release SDA until it gets another falling edge on SCL. Even in this case it's not until it tries to transmit a '1' that it will actually release SDA after seeing SCL fall. The end result is that the bus will hang. If the I2C tries to initiate a new transfer it will hit an "arbitration lost" condition because SDA won't match the address it's sending.
 
A workaround has been reported to work even on these devices. By configuring the I2C for "free data format" and then reading a byte the I2C will immediately start sending clocks to input data (rather than trying to send an address).

So I would like to do so but I have no idea on how to do that. I would be grateful, if you can help me with this issue.
And I am interrested in any possible solution to this problem.

What RIC describes should be part of the startup code of all I2C systems when there isn't a reset line to all slave devices.

Yeah, I guess it has to be done by releasing the I2C module and using the pin as a simple I/O.

niak niak
Thank you for the answer.
 
But how do you toggle the SCL line using the I2C Library ?
Maybe it's not possible.
So I set the pin has an output and toggle it ?
Or there is an register to modify in order to do so ?

Try something like this.

You only do it on startup and if the bus has hung.   Start your timer, zero it on every successful I2C operation and when it times out check the bus.  If SCL is high and SDA is low, poll it for longer than the slowest device takes to send a byte.  Any transitions - reset the timer.  No transitions - abort any I2C operations, disable the MSSP (I2C) peripheral, bitbang the 9 SCL: bus reset sequence, wait and check the bus is free then reenable the MSSP in I2C mode

We're having issues in where on a noisy ARM-powered board, MCP2317 stop working. We have knowledge of this fact by being unable to read back a register value, so we do the reset.

DavidBLit

DarioG
We're having issues in where on a noisy ARM-powered board, MCP2317 stop working. We have knowledge of this fact by being unable to read back a register value, so we do the reset.

Write to LATx, not PORTx!  Oh, wait... wink:

 
No that's not that
I prefer PICs over them, as far as I could see...

DarioG
...
I prefer PICs over them, as far as I could see...
...

I am very curious as to why.  The peripheral suite is at least comparable (I'm thinking of vendors like ST and Freescale) and the span of the Cortex-M0 at the low end to -M4 at the high (with a relatively consistent instruction set) seems a benefit over the "step-function" changes in architecture through the PIC spectrum.
 
...and you're not burdened with artificially crippled compilers...
 

DarioG
...
Of course it does work  just my opinion

...and the opinions of those with a great depth of experience should always be valued!  cool: [8)]