TWI HW producing shortened ACK clock pulse

[Benjamin]

Hi everyone,

we are trying to use the TWI interface of the nRF52832 to communicate with a TI BQ28Z610 fuel gauge, using the TWI driver of the nRF5_SDK_13.0. For the last few days we had seen always the same behaviour: when we were trying to transmit more than 1 byte of data, the device address as well as the first byte were transmitted correctly, the second byte however produced a NACK.

We've been able to narrow down the problem to the ACK clock pulse after the first byte. As you can see from the attached scope screenshots, the relevant clock pulse has circa 1/4 of the length of a normal clock pulse. While I'm assuming that this behaviour brings a technical advantage in most cases (since the shorter clock pulse frees the interface earlier for subsequent communication) it leads to problems with the BQ28Z610.

My workaround at this point is to use the deprecated bit banging methods from twi_sw_master.c. I've insterted a 5ms delay after the function checks for the ack bit to delay the SCL line going low again.

Now the question is, since we're not fully happy with not being able to use the TWI hardware driver, is there any way to lengthen the relavant clock pulse using the TWI hardware? Has anybody else experienced problems with that behaviour?

tek00000.png tek00001.png tek00002.png

[RK]

There's no options in the nRF TWI hardware to change any of this. I checked out the spec sheet on the TI chip (capable chip!) and, as is rather common, there wasn't a lot of information about I2C timings. It does claim minimum 600ns high clock but doesn't really say where it needs that. Since they appear to define high as 90% you may not even have that, really not sure, you could ask TI but I doubt you'll get a great answer.

So options are. Find another sensor chip, find a to I2C chip which produces I2C your TI chip can handle and interface that over the protocol instead.

If you can live with a lower data rate xfer on the I2C and are in a hole I might try adding just a little capacitance to the I2C lines see if I can filter that pulse longer. I don't particularly love that idea, but I'd probably try it for interest.

[Benjamin]

Okay, thank you very much. I think we will go with using the bit banging method for now, since it doesn't really have an impact on system performance - it just would have been somewhat nicer to be able to rely on the HW interface. I was thinking about reporting the whole thing to Nordic as a bug but since (almost) nobody else seems to have this problem, it might rather be a problem of the TI chip than of the NRF52.

[Corentin]

Hello. I have exactly the same problem on a TI chip (ADS1114). Need a minimum of 600 ns and the TWI is too fast....