Infinite loop in the `i2c (or Twim) implementation` of nrf52840_hal

It's more like a question than a conclusion but thanks for link. So, it's not an addressing issue.

With that out of the way, I see the number of clock pulses in each capture is different.

  1. ESP32 has 9 before SDA goes high
  2. nRF has 8 before SDA goes high

My understanding is that after transmitting a byte of data, the master releases the SDA line (pushes it to the high state) which is pulled down (after one clock pulse) by the receiver to be counted as an ACK.

Why do they look different?

I think I understand now. The slave isn't responding to the nRF but is responding to the ESP32 (and that shows in ESP32's logic capture, where the SDA line is pulled down to acknowledge each byte unlike that of the nRF).

  1. The question is why wont it respond to the nRF?

Yes, the master pulses 9 times. The first 8 pulses are for data and the 9th is for ACK/NACK.

Your device is not responding. Common mistakes are invalid address, missing pull-up resistors, clock too fast...

To learn more about the protocol, I recommend reading the I2C specification.

Finally figured this out with a ton of help from @henrik_alser. So, to close this one out, here's the

Solution: There's two parts to it

  1. First, the current implementation of TWIM (i.e. the common i2c interface included in nrf-hal) ends up in an infinite loop if no slave ACKs an address that's placed on the bus (including situations where slaves could be sleeping). A PR has been submitted by Henrik Alser to fix this issue here - https://github.com/nrf-rs/nrf-hal/pull/166.
  2. Second, this i2c slave requires a specific wake condition to be met before any actual data can be exchanged. The data line needed to be held down for at least 60 us followed by a high of at least 1500 us, before sending any data (including the slave's address).

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.