> I did my I2C reset analysis many years ago but I found the reason in > som old code I had lying around, just sending 9 clocks will not > recover the case when stuck in an I2C write sequence. Adding START > into the sequence keeps the device in START once it has seen at least > one START, then the STOP will release the bus in the end. OK. I had some time to dig into the specs and understand why I was a bit cautious: Chapter 3.1.16 of the I2C specs describes the procedure of 9x toggling to be done when SDA is stuck low (which is super bad because you can't signal a STOP then). SDA can only stuck low in the read case. In the write case, the master controls SDA, and thus, you should be able to signal STOP immediately. So, for the write case, I'd think a single STOP before toggling should do. Toggling 9x even means you could then write something somewhere which in case of a PMIC can be really dangerous. (BTW I just noticed that the generic recovery routines in the I2C core do not send any STOP. Neither before nor after the toggling. This might need fixing but is a seperate issue). This is all from a theoretical point of view. I don't have a test case for that. Do you have a reproducibly misbehaving device?
Attachment:
signature.asc
Description: PGP signature
