- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear all,
I using the TC375 Lite Kit. On the Microbus interface I connected a click board that contains the IQS7211A touchsensor. When reading the sensor ID (that is 2 bytes 0xFB and 0x02) I realized that after the first byte successfully read the SDA line is not pulled up. If I continue reading the following bytes are as expected and the SDA is pulled up after each ACK. I using the 'reading I2C MAC address' example from Infineon that is only slightly modified to fit to the addresses/registers of the IQS721A touchsensor.
First I thought it might be a sensor issue. To check this I installed the board on a STM32 device. Now all bytes can be read as expected.
I attached two screenshots to demonstrate the problem.
I spend quite some time to analyse the problem. So I changed timing, opendrain and push/pull settings on the TC375. None of them improved the issue. It's even more confusing that if I read from other sensor addresses I can read several bytes with no problem. I also attached them with the word 'correct' in the file name.
The only thing I can see at the moment are some 'pull up' spikes at the end of almost each byte read transfer. However, for the decoding of the bitstream this seems to be of no relevance.
Anyone has any idea what is going wrong?
Best Regards
Markus
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Markus4711 ,
the TC375 Lite kit also contains an I2C EEPROM with an I2C address @0x50.
AFAIR few of the lower I2C slave address bits of this EEPROM device are "don't care"...
So there might be also a clash between the I2C EEPROM and the touchscreen sensor (at I2C slave address 0x56)?
Could you perform an access to I2C address 0x56 w/o the sensor being attached?
Best regards,
Thomas
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I re-copy the screenshots here to make it easier to read. Green circles stands for 'as expected', red circles stands for 'erroneous behavior'.
SDA stays low after the first byte:
Same I2C device connected to a STM32:
Reading from a different I2C device register with the TC375 - correct reading but 'pull-up' spikes after almost each byte.
Same address read with a STM32:
Best Regards
Markus
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Markus4711
Thank you for your interest in Infineon Semiconductor products and for the opportunity to serve you.
In the first figure, I'd like to know whether you can still read the expected read, even occur the "SDA line is not pulled up".
BR,
Jeremy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jeremy,
I cannot read the 2nd Byte correctly in the first example. It is expected to be 0x02 (as shown in the screenshot taken from the STM32 microcontroller) but I read 0x00.
I forgot to mention that the external pull-up resistors are exactly the same on the STM32 board and on the TC375 Lite Kit.
Best Regards
Markus
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Markus4711 ,
the TC375 Lite kit also contains an I2C EEPROM with an I2C address @0x50.
AFAIR few of the lower I2C slave address bits of this EEPROM device are "don't care"...
So there might be also a clash between the I2C EEPROM and the touchscreen sensor (at I2C slave address 0x56)?
Could you perform an access to I2C address 0x56 w/o the sensor being attached?
Best regards,
Thomas
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
bull's-eye. It is indeed the case that at register address 0x00 the EEPROM chip also feels addressed although it was not addressed with its device ID. It then returns 0x00 in the 2nd byte (since it has an autoincrement, this is theoretically the content of the memory address 0x01 - although it is probably more of a misbehaviour than a reliable value).
Unfortunately quite annoying, because the EEPROM chip declares the 3 lower address bits as don't care and thus endangers a problem-free interaction with up to 8 other I2C bus participants. I will now continue to implement the functionality of the touchpad sensor and hope that the address 0x00 remains an exception.
Thanks again for the advice. I probably wouldn't have discovered it so quickly.
Markus