I2C: Master ACK in Hold mode not working (clock strechting)

[Ing-Dom]

Hi,

I try to read out a SHT21 sensor.
While this works on SAMD21 Arduino, with Hold mode or no hold mode, in the pico it works only with "no hold method".

It seems that the master (pi pico) does not ACK the bytes from the slave.

thats the code:

`

#include <Wire.h>
#include <Sodaq_SHT2x.h>

void setup()
{
Wire.setSDA(4);
Wire.setSCL(5);

Wire.setClock(10000);
Wire.begin();
Serial.begin(9600);
}

void loop()
{

uint16_t result;

Wire.beginTransmission(0x40);
Wire.write(0xE3);
delay(100);
Wire.endTransmission();

Wire.requestFrom(0x40, 3);
uint32_t timeout = millis() + 1000; // Don't hang here for more than 300ms
while (Wire.available() < 3) {
if ((millis() - timeout) > 0)
{
Serial.print(" timeout: ");
Serial.println(Wire.available());
break;
}
}

//Store the result
result = Wire.read() << 8;
result += Wire.read();
result &= ~0x0003;   // clear two low bits (status bits)

//Clear the final byte from the buffer
Wire.read();

`

Sending the command to the slave works. After the read command, the slave is pulling SCL down. After releasing it, slave sends 8 bytes, but there is no ACK (SDA Low at 9th clock) from the master:

Thats what it looks like on SAMD21:

as you can see, the frst bytes are ACKed with SDA Low, the third and last byte is NACKed.

[earlephilhower]

FYI, the Wire transmission is buffered until the end due to the HW requirements on the Pico (need to fill the FIFO before transmission can begin). So you probably want to move that delay() down...

Wire.beginTransmission(0x40);
Wire.write(0xE3);
Wire.endTransmission();
delay(100);

if you want or need a 100ms delay between write and read transactions. Otherwise the read will happen immediately after the write completes.

No real idea w/the clock stretching reports. The I2C read is pure HW driven. SCL is set to a pullup on-chip, but obviously the device is able to drive it low since the scope trace shows it low.

You might want to use the RPi forums https://www.raspberrypi.org/forums/viewforum.php?f=144 to see if your experience is unique or if others have worked through it. Per the docs, it seems like clock stretching should work just fine on the Pico...

[Ing-Dom]

I copied some code from a library, you are right, that delay is not placed correctly.

I had a look on

`size_t TwoWire::requestFrom(uint8_t address, size_t quantity, bool stopBit) {
if (!_running || _txBegun || !quantity || (quantity > sizeof(_buff))) {
return 0;
}

_buffLen = i2c_read_blocking_until(_i2c, address, _buff, quantity, !stopBit, make_timeout_time_ms(50));
_buffOff = 0;
return _buffLen;

}`

To be honest, I have not much experience with I2C and unfortunately, the arduino libraries are poorly documented, but I would expect from requestFrom to not block. It shouldn't read the data, it should only send the "read request", the slaves 7 bit address + 1 indicating a read and after that, store received bits async in some buffer which can be checked with wire.availible() and read out with wire.read().

This is not the way your Wire lib is expected to work, is it?

I will now dive into the SAMD (Zero) Wire lib maybe I find something there...

[earlephilhower]

Unfortunately, the way Arduino has defined the API, Wire::requestFrom has to return the number of bytes read. So, I'm not sure how you'd do that without blocking until the bus transaction finishes.

What you can do here, if you really need to not block, is use the raw Pico-SDK calls. The core includes the full pico-sdk with all the headers, so your Arduino code can just include the appropriate #include <hardware/i2c.h> and any add'l ones you need and use the non-blocking I2C calls.

Assuming you really do need 100ms from the write to the slave being able to read, the 50ms I2S read timeout might be the problem (you'd get 0 as the return value from the fcn. in that case). You can raise that 50ms to 200ms and easily give it a go. If that's the case, we can add a Wire::setTimeout() method to allow specifying this hardcoded ("seems reasonable to me" guessed) value.

[Ing-Dom]

yes you are right, everything I found in the meantime indicates that the Wire lib is designed blocking.
But why the availible function then? Looks redundant to me.

I had a quick look on the pico sdk, it seems there is no support for non blocking read.

The sensor needs up to 85ms for the measurement. But I could use the non blocking mode, I would prefer that anyway.
This is getting more general for me here, figuring out what is wrong and eventually fix some bugs.

But as you pointed out already - it seems to be that 50ms timeout causing the problem.
I will increase it and give it a try.

edit: when increasing to 200, it works.

it seems the zero implementation has a bigger timeout.

[earlephilhower]

OK, seems like a Wire::setTimeout API would be useful. Can you open an issue here requesting it, so we can track it? It's almost trivial, but I don't want to end up forgetting about it.

[ZinnerC]

@earlephilhower I quickly would like to follow up with regard to Wire::setTimeout.
Do I understand that correct that basically when the I2C would not react longer than the set timeout it would restart the I2C?
Because I have a situation which probably could use Wire::setTimeout.
The SCL line seams to stay pulled down. By what I don't know yet. However, if I "listen" on the SCL line and check if there is a "prolonged" LOW on the respective line I would restart the I2C.
Would the timeout which I could set with Wire::setTimeout take care of this?
Wire::clearTimeoutFlag and Wire::getTimeoutFlag would be handy too.