element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Azure Sphere Starter Kit
  • Products
  • Dev Tools
  • Avnet Boards Community
  • Azure Sphere Starter Kit
  • More
  • Cancel
Azure Sphere Starter Kit
Forum I2C read bug
  • Blog
  • Forum
  • Documents
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Azure Sphere Starter Kit to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • State Suggested Answer
  • Replies 8 replies
  • Answers 4 answers
  • Subscribers 49 subscribers
  • Views 1379 views
  • Users 0 members are here
Related

I2C read bug

tekmeister
tekmeister over 5 years ago

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.

  • Sign in to reply
  • Cancel

Top Replies

  • tekmeister
    tekmeister over 5 years ago in reply to Fred27 +5 suggested
    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…
  • Fred27
    Fred27 over 5 years ago +3 suggested
    I experienced exactly the same problem. No resolution yet that I know of. Repeated first byte on I2C read with Azure Sphere
  • clem57
    clem57 over 5 years ago +2 suggested
    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…
  • clem57
    0 clem57 over 5 years ago

    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

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • Verify Answer
    • Reject Answer
    • Cancel
  • tekmeister
    0 tekmeister over 5 years ago in reply to clem57

    Hi Clem,

     

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

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • Fred27
    0 Fred27 over 5 years ago

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

    Repeated first byte on I2C read with Azure Sphere

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • Verify Answer
    • Reject Answer
    • Cancel
  • tekmeister
    0 tekmeister over 5 years ago in reply to Fred27

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

    • Cancel
    • Vote Up +5 Vote Down
    • Sign in to reply
    • Verify Answer
    • Reject Answer
    • Cancel
  • Fred27
    0 Fred27 over 5 years ago in reply to tekmeister

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

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • jgroman
    0 jgroman over 5 years ago

    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.





    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • javagoza
    0 javagoza over 5 years ago

    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…

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Reject Answer
    • Cancel
  • Fred27
    0 Fred27 over 5 years ago in reply to javagoza

    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.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube