• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 6 replies
  • Subscribers 63 subscribers
  • Views 3191 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 124147
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents
  • 0

    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.

Reply
  • 0

    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.

Children
Related