we are using the I2C interface on the PCH EG20T to communicate with a power supervisor under on-Time RTOS32. The I2C access is EEPROM based, with 16 bit addressing. The power supervisor device needs to do some clockstretching, if its not ready to responde immediately. If clockstretching is enabled, the I2C master in EG20T generates an arbitration lost IRQ. Now my basic question is: Is I2C interface capable of handling clock stretching?
Some details: Our driver depends on the flow description of the EG20T handbook. We also looked at the Linux driver and its equivalent. For a status read on the power supervisor device, I do the following sequence:
- Write device address 0x53, R/W bit clear for writing, perform I2C start condition
- Write high byte of register address to read from
- Write low byte of register address to read from
- Write device address 0x53, R/W bit set for reading, perform I2C restart condition
- Read register data which is my status byte
- Perfom a I2C stop condition
For some explanation, below a screenshot. We have inserted 100 ohms resistors in the SCL (yellow)/SDA (light blue) lines, to distinguish between the drivers. If signal goes low to ground, EG20T is driving the line, if it goes only to 0,5V, the power supervisor is driving the line. The sequence on the screenshot shows the status read access upon point 4: I2C restart condition, device addressing with R/W bit set. Now you can see a short clockstretching from the slave, holding the SCL line low for shorter than 10us. Now the data read starts and should clock out 8 pulses. But while the 5th clock everything blocks, EG20T drives SDA low and after about 3ms I got an arbitration lost IRQ (the magenta peak at the trigger)
Is this a known issue or what we are doing wrong?
Sorry for the long delay, but for some reason, we lost visibility of your case. We will start working on your issue, and will reply back as soon as possible
We are still checking into this for you. There may be a need to access some Intel Confidential content. Therefore, would you please apply for an EDC Privileged account: https://www-ssl.intel.com/content/www/us/en/forms/intelligent-systems/registration-po.html Apply for an Intel® Embedded Design Center Privileged Account. Once you submit it, please let me know so that I can get it quickly addressed for you. LynnZ
We apologize for the delay, thank you very much for your patience.
The CLKL (Low Speed Bus Clock) may help to solve this inconvenience, it is important to let you know that the CLKL is changed, it is also necessary to change the set value of the I2CBC register accordingly. You can review this information in the https://www-ssl.intel.com/content/dam/www/public/us/en/documents/datasheets/platform-controller-hub-... Intel® Platform Controller Hub EG20T Datasheet, in section 15.2, on page 545; all the I2CBC register information is available in section 18.104.22.168, page 561.
Please refer to the bits I2CMSTA, I2CRSTA, I2CBMTO, and I2CESRTO, these bits may help you to delay data processing. The information related to these bits is stated in sections 22.214.171.124, 126.96.36.199, and 188.8.131.52; on pages 557, 567, and 571 of the cited datasheet.
The supported Operating Systems by the Intel® Platform Controller Hub EG20T are:
Microsoft Windows* XP SP3,
Microsoft Windows Embedded Standard 2009,
Microsoft Windows Embedded Standard 7,
Microsoft Windows Embedded POS Ready 2009,
Microsoft Windows 7,
Microsoft Windows Embedded CE 6.0 R3,
QNX Neutrino, and
Wind River VxWorks.
You can confirm this information and the vendors that can give you support to the drivers associated to these Operating Systems on page 3 of the https://www-ssl.intel.com/content/dam/www/public/us/en/documents/product-briefs/atom-e6xx-embedded-c... Intel® Atom™ Processor e6xx Series with Intel® Platform Controller Hub EG20T Embedded Computing Platform Brief.
We hope this information is helpful to solve this case.