We're working on a project that interfaces an nRF9151 with a BQ40Z50 from Texas Instruments (via I²C / TWI / SMBus), and we've noticed the communication is unreliable. The BQ40Z50 appears to be using clock stretching.
The product specification for the nRF9151 says that its TWIM peripheral supports clock stretching, but that support is "non I²C compliant". We may be running into that "non I²C compliance" but wanted to get Nordic's thoughts on this before we make that conclusion.
Using a Logic analyzer, we've narrowed the root cause of the problem to this exchange. The BQ40Z50 is trying to send the bit sequence 1011 01xx. Here, it does so successfully:
But sometimes the same sequence comes out wrong:
In these diagrams, clock stretching is occurring in the yellow region. At the end of clock stretching, the clock pulse is very short. The nRF9151 drives the clock low again quite soon after stretching ends!
The BQ40Z50 is not expecting this, so, in the second case, it does not even recognize that first pulse as a clock. It does not switch to sending the second bit of its bit stream, and thus two 1 bits are recorded in error (the first two bits should be 10, not 11).
This doesn't seem to be the fault of the BQ40Z50, as its datasheet says that it requires the "clock high period" be a minimum of 4.0 μS, which it is certainly not. Even in the case where it works, it's below the minimum, so it's only working by luck.
The nRF9151's datasheet says that "the SCK pulse following a stretched clock cycle may be shorter than specified by the I²C specification", which we unfortunately did not read before pairing these parts up, and they're now in a design together that is at a stage where it is difficult to change. Are we correct in concluding that the nRF9151's "non I²C compliance" in this area simply means these parts cannot interface with each other? Or is there some workaround that could save our design?
