Actions
Forum Thread Details
  • State Suggested Answer
  • Replies 8 replies
  • Answers 4 answers
  • Subscribers 47 subscribers
  • Views 740 views
  • Users 0 members are here
Related

I2C read bug

tekmeister

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("\nb1[0] = %x, b2[0] = %x, b3[0] = %x, b4[0] = %x, b5[0] = %x, b6[0] = %x\n", 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.

Parents
  • 0

    image

     

    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

Reply
  • 0

    image

     

    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

Children