Device-os: [Gen3] I2C reads back address byte

Created on 7 Jun 2019  路  4Comments  路  Source: particle-iot/device-os

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)

bug confirmed realembedded-platform

Most helpful comment

Possibly the same problem as here: https://github.com/particle-iot/nrf5_sdk/pull/9

All 4 comments

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)
image

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

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

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

Was this page helpful?
0 / 5 - 0 ratings