1
\$\begingroup\$

I'm working to bring up ADV7610 (similar to ADV7611) on a Linux based embedded system (TI AM5728 platform).

By all account, I think the Chip-Select, Reset and I2C bus are all configured correctly. There is not much to worry about the bus itself, as I have no problem communicating with other devices on the same bus.

The device is supposed to show up in 0x4c. Here is what I see when I run i2cdetect:

i2cdetect -y -r 0                                                                                                                                                                                      
    0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: 10 -- 12 -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- 22 -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- UU 3d 3e 3f 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- UU UU UU 5b -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --  

Nothing there on 0x4c.

However, when I use i2cget tool, it is responding correctly:

i2cget -y -f 0 0x4c 0xeb                                                                                                                                                                 
0x51
i2cget -y -f 0 0x4c 0xea
0x20

The hex values of 0x51 and 0x20 correspond correctly to the device ID as per the datasheet.

Here is the raw traffic trace of i2cdetect:

   i2cdetect-2043  [000] ....   619.790641: i2c_read: i2c-0 #0 a=04b f=0001 l=1                                                                                                                      [70/40604]
   i2cdetect-2043  [000] ....   619.790713: i2c_result: i2c-0 n=0 ret=-121     
   i2cdetect-2043  [000] ....   619.790820: i2c_read: i2c-0 #0 a=04c f=0001 l=1
   i2cdetect-2043  [000] ....   619.790892: i2c_result: i2c-0 n=0 ret=-121     
  a=053 f=0001 l=1
   .
   .
   .
   i2cdetect-2043  [000] ....   619.792347: i2c_result: i2c-0 n=0 ret=-121     
   i2cdetect-2043  [000] ....   619.792482: i2c_read: i2c-0 #0 a=054 f=0001 l=1
   i2cdetect-2043  [000] ....   619.792554: i2c_result: i2c-0 n=0 ret=-121     
   i2cdetect-2043  [000] ....   619.792662: i2c_read: i2c-0 #0 a=055 f=0001 l=1
   i2cdetect-2043  [000] ....   619.792734: i2c_result: i2c-0 n=0 ret=-121     
   i2cdetect-2043  [000] ....   619.792868: i2c_read: i2c-0 #0 a=056 f=0001 l=1
   i2cdetect-2043  [000] ....   619.792940: i2c_result: i2c-0 n=0 ret=-121     
   i2cdetect-2043  [000] ....   619.793048: i2c_read: i2c-0 #0 a=057 f=0001 l=1
   i2cdetect-2043  [000] ....   619.793120: i2c_result: i2c-0 n=0 ret=-121     
   i2cdetect-2043  [000] ....   619.793593: i2c_read: i2c-0 #0 a=05b f=0001 l=1
   i2cdetect-2043  [000] ....   619.793727: i2c_reply: i2c-0 #0 a=05b f=0001 l=1 [00]
   i2cdetect-2043  [000] ....   619.793732: i2c_result: i2c-0 n=1 ret=1   
   i2cdetect-2043  [000] ....   619.793844: i2c_read: i2c-0 #0 a=05c f=0001 l=1

What can might be going on here?

\$\endgroup\$
  • 1
    \$\begingroup\$ I think I know but I must ask: How does the i2cdetect tries to find precence of chip? Does it simply send slave address with read mode? \$\endgroup\$ – Justme Apr 2 at 15:21
  • \$\begingroup\$ @Justme Yes, with the -r switch, adress in read mode is set and then single byte is clocked out from the slave followed by the NACK from master. Presence of the slave is detected by the acknowledge after address (there is no other response to use for this). Reading extra byte is not needed for identification, but probably helps to minimize probability of disturbing slave into some locked state. (Without explicit -r switch i2cdetect decides based on slave address which method to use.) \$\endgroup\$ – Martin Apr 2 at 16:42
  • \$\begingroup\$ @Justme I can confirm that it simply writes slave addresses in read mode. \$\endgroup\$ – Adam Lee Apr 3 at 22:10
3
\$\begingroup\$

I have seen this before, with chips closely related to the ADV7610 and even other video chips from Analog Devices.

The chip considers a single I2C read operation as invalid, and it will not acknowledge the address for a read operation because no register address was written to it first.

The chip only responds to a I2C read operation, if it happens after writing a register address before the read.

As far as my memory serves, there must be no I2C stop condition between the end of register address write, and the I2C data read must happen with a repeated start condition.

The datasheet does mention that when invalid register address is used, it will not acknowledge the read operation. But it is not specifically explained anywhere that the sequence does not allow writing register address and reading of data in two separate operations, while it is more common that they are also supported as two separate operations.

Consider it as a special feature of the chip's I2C interface that must be known, documented and handled as required.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Thanks for clearing that up! Never thought i2cdetect couldn't be trusted..! \$\endgroup\$ – Adam Lee Apr 3 at 22:15
2
\$\begingroup\$

In the datasheet, you have linked (ADV7611) at page 175 a write sequence and read sequence are depicted, both starting with addressing the device in write mode.

I do not see it specified anywhere explicitly, but it is well possible that these are only possible ways to communicate with the device and starting the communication with read address (LSB 1) is not acknowledged by the device, which causes i2cdetect in -r mode to fail.

Your i2cget command does exactly what is depicted in figure 67 -- sending single byte in write mode, repeated start and read.

To mimic the behavior of i2cdetect (with the -r switch) you can call i2cget command without register address. Then only read access is attempted and it should fail if my assumption above is correct.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Thank you for the explanation. It cleared up my confusion a whole lot. I suppose I can't trust i2cdetect 100% to check whether a device is up or not. \$\endgroup\$ – Adam Lee Apr 3 at 22:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.