I2C read bug

Start and Stop Condition

Each I2C command initiated by master device starts with a START condition and ends with a STOP condition. For both conditions SCL has to be high. A high to low transition of SDA is considered as START and a low to high transition as STOP.

After the Start condition the bus is considered as busy and can be used by another master only after a Stop condition is detected. After the Start condition the master can generate a repeated Start. This is equivalent to a normal Start and is usually followed by the slave I2C address.

Microcontrollers that have dedicated I2C hardware can easily detect bus changes and behave also as I2C slave devices. However, if the I2C communication is implemented in software, the bus signals must be sampled at least two times per clock cycle in order to detect necessary changes.

I2C Data Transfer

Data on the I2C bus is transferred in 8-bit packets (bytes). There is no limitation on the number of bytes, however, each byte must be followed by an Acknowledge bit. This bit signals whether the device is ready to proceed with the next byte. For all data bits including the Acknowledge bit, the master must generate clock pulses. If the slave device does not acknowledges transfer this means that there is no more data or the device is not ready for the transfer yet. The master device must either generate Stop or Repeated Start condition.

If you read this carefully, somewhere in either the library routine or your code there needs to be Ack sent to the slave. My guess would be your code... It also depends on the slave (buffer internal) how much data can be sent without a pause. You need to look at the datasheet to see how the slave (your device) acts in this transfer...

Clem

Hi Clem,

My question is specifically around the I2C API implementation for the Azure Sphere, not a general question on the I2C protocol.

I experienced exactly the same problem. No resolution yet that I know of.

Repeated first byte on I2C read with Azure Sphere

Hi David,

I did see your issue, but I wasn't sure if it was the same root cause or not. If it is the same problem, then I think I have identified more about the nature of when it happens.

My workaround for now is to read no more than 8 bytes at a time:

int32_t retVal = I2CMaster_Write(i2cFd, dev_id, &reg_addr, 1);
if (retVal < 0) {
    return -1;
}

uint16_t i = 0;

/*
    there seems to be a bug where bad data is returned when reading more than 8 bytes at a time
    so read in blocks of 8 bytes for now
*/

for (i = 0; i < len; i += 8)
{
    uint8_t readLength = len - i;
    if (readLength > 8)
    {
        readLength = 8;
    }

    retVal = I2CMaster_Read(i2cFd, dev_id, &reg_data[i], readLength);
    if (retVal < 0) {
        return -1;
    }
}

I suspect it's the same issue. I'll try reading in chunks of 8 and see what happens.

I experienced the same problem when trying to port some Arduino drivers. Took me very long time spent debugging and then I blamed it on sensor in question. Reading in smaller chunks works fine.
Seems that sensor was innocent then.

I think you should to check the returned value by the function I2CMaster_WriteThenRead

"Returns: The combined number of bytes successfully written and read, or -1 for failure, in which case errno is set to the error value. A partial result, including a transfer of 0 bytes, is considered a success."

https://docs.microsoft.com/en-us/azure-sphere/reference/applibs-reference/applibs-i2c/function-i2cmaster-writethenread#r…

javagoza It's not that the count of the bytes is incorrect, it's the fact that the first byte is repeated. The data is wrong.

The problem seems to occur in both I2CMaster_Read and I2CMaster_WriteThenRead. In my case using a PN7120 NFC reader I have to wait for an IRQ signal between writing and reading so can't use I2CMaster_WriteThenRead anyway.