I2C read bug

Question

I'm trying to interface to an I2C device and have uncovered what I think is a major bug in the Azure Sphere I2C libraries. I have opened the I2CMaster, set the speed and try to read from the device: const uint8_t readLength = 8;
const uint8_t address = 0xD0;
uint8_t b1[20];
uint8_t b2[20];
uint8_t b3[20];
uint8_t b4[20];
uint8_t b5[20];
uint8_t b6[20];

I2CMaster_WriteThenRead(i2cFd, i2cAddress, &address, 1, b1, readLength);
I2CMaster_WriteThenRead(i2cFd, i2cAddress, &address, 1, b2, readLength);
I2CMaster_WriteThenRead(i2cFd, i2cAddress, &address, 1, b3, readLength);
I2CMaster_WriteThenRead(i2cFd, i2cAddress, &address, 1, b4, readLength);
I2CMaster_WriteThenRead(i2cFd, i2cAddress, &address, 1, b5, readLength);
I2CMaster_WriteThenRead(i2cFd, i2cAddress, &address, 1, b6, readLength);

Log_Debug("
b1[0] = %x, b2[0] = %x, b3[0] = %x, b4[0] = %x, b5[0] = %x, b6[0] = %x
", b1[0], b2[0], b3[0], b4[0], b5[0], b6[0]); With a readLength of 8 or less, then the content of the output buffers is as expected, and the following is printed to the console: b1[0] = 61, b2[0] = 61, b3[0] = 61, b4[0] = 61, b5[0] = 61, b6[0] = 61 However if I make my readLength greater than 8, I get the following console output: b1[0] = 80, b2[0] = 0, b3[0] = 0, b4[0] = 0, b5[0] = 0, b6[0] = 0 and my output buffers contain an extra byte before the expected data. In other words, buffer[0] is rubbish, and my read data is from buffer[1] onwards. If I mix up the readLengths with a combination of values <=8 and > 8, then I discover that the first read of 9 or more bytes is good but subsequent reads of 9 or more bytes are bad with the additional byte at the start, until the next read of 8 or less bytes which is good. Can anyone else reproduce this? I'm using an external I2C device with address 0x77 on the click socket #2.

tekmeister · Answer

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;
 }
}

Fred27 · Answer

I experienced exactly the same problem. No resolution yet that I know of. Repeated first byte on I2C read with Azure Sphere

clem57 · Answer

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

javagoza · Answer

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…

I2C read bug

Top Replies