TC375: I2C SDA not pulled high after first byte successful read

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Markus4711
Level 2
Level 2
First like received 10 questions asked 10 sign-ins

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

 

0 Likes
1 Solution
ThNo
Level 4
Level 4
First like given 25 sign-ins 5 solutions authored

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

View solution in original post

5 Replies
Markus4711
Level 2
Level 2
First like received 10 questions asked 10 sign-ins

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:

User20718_1-1681308966416.png

Same I2C device connected to a STM32:

User20718_2-1681309009541.png

Reading from a different I2C device register with the TC375 - correct reading but 'pull-up' spikes after almost each byte.

User20718_0-1681308883668.png

Same address read with a STM32:

User20718_3-1681309094405.png

 

Best Regards

Markus

0 Likes
Jeremy_Z
Moderator
Moderator
Moderator
1000 replies posted 250 sign-ins 100 likes received

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

0 Likes
Markus4711
Level 2
Level 2
First like received 10 questions asked 10 sign-ins

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

0 Likes
ThNo
Level 4
Level 4
First like given 25 sign-ins 5 solutions authored

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

Markus4711
Level 2
Level 2
First like received 10 questions asked 10 sign-ins

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

0 Likes