As discussed in this thread
https://community.particle.io/t/i2c-invalid-reads/50214
and this test code
#define MASTER 0
#define speed 100000
#define SLAVE_ADDRESS 0x18
#if MASTER
void setup() {
Serial.begin(115200);
Particle.function("sendData", sendData);
//Wire.setSpeed(speed); // optional but same result
Wire.begin();
}
int sendData(String cmd) {
for (int i = 0; i < 1; ++i) {
uint8_t count = Wire.requestFrom(SLAVE_ADDRESS, 6);
// delay(10); // doesn't change anything
while(Wire.available()) {
char c = Wire.read();
Serial.print(c);
}
Serial.println();
}
return 0;
}
#else
void requestEvent() {
Wire.print("456789");
}
void setup() {
//Wire.setSpeed(speed); // optional but same result
Wire.begin(SLAVE_ADDRESS);
Wire.onRequest(requestEvent);
}
#endif
I could confirm with Argon as master (probably true for other Gen3 too) and Photon as slave, with any call to sendData - after the first - the reported data will be "prepended" with (SLAVE_ADDRESS << 1) & 0x01.
When swapping roles (Photon=master, Argon=slave) the master receives the correct data.
Tested with 1.1.0 and 1.2.1-rc.2 (on both devices)
Possibly the same problem as here: https://github.com/particle-iot/nrf5_sdk/pull/9
@perotom Thanks for digging into this issue 馃憤. I also did some tests:
Test case 1: Argon(Master) - Xenon(Slave)

Test case 2: Photon(Master) - Photon(Slave)

Test case 3: Argon(Master) - Photon(Slave)

From the Logic Analyser(Test case 3), we can find there is no too long or too short clock pulse as is in the case you provided i2c-clock-stretching-on-nrf52840, so it might be not the same issue, and software TWI driver twi_sw_master.c is deprecated, we're using the hardware TWI driver.
From Test case 3, we can see the extra byte is sent from Gen2 device, I'll continue to look into this issue, if you have any other new discoveries, you can leave it here. Thank you!
From my side I can tell it happens in about 0.1% of requests, so you might need to write your own test script to see the effect (We did a loop where we read on byte every 100ms and compare it to the previously read value). The Electron doesn't suffer from this behaviour.
Resolved in #1829
Most helpful comment
Possibly the same problem as here: https://github.com/particle-iot/nrf5_sdk/pull/9