I'm running I2C commands on secondary priority to a PIT module, that can delay I2C interrupt handling by about 50µs. I notice however, that, when a transfer completes followed by a stopbit and followed by a startbit before I can handle these interrupt flags, my code no longer responds to the transfercomplete. I deviated from the proposed flowchart by removing the return statements in the stopbit and startbit handling, to be able to process that TransferComplete that happened about 50µs ago.
Thus, I assume this TransferComplete flag is cleared when a start bit is received. I was not expecting this, nor do I find this behavior described in any manuals.
Kind of annoying, but I figured I would get around it disabling the FACK bit ('1') and 'manually' perform the ACK/NACKing when actually handling the TransferComplete (auto-ACK on addressing though, but setting FACK to '1' after an address match).
And here I run into the main problem. When the first byte of data is received, the ISR launches after the 8th clock, I write '0' to TXAK, I see the acknowledge on the oscilloscope (so far, so good), but after the ACK, SCL is kept low. I did read the data register (I find the value on on the oscilloscope in my buffer), I cleared the interrupt flag (no further interrupts follow anyway) and the bus hangs like this indefinitely.
I'm evaluating my ISR by means of driving some GPIOs hooked up to an oscilloscope, for my convenience. (In the screenshot, you can see these on C3 and C4.)
Message was edited by: Giovanni Vandelannoote Changed attachment to a clearer oscilloscope screenshot