• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 98 subscribers
  • Views 831 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Interfacing DM648 I2C to ADV7171

Eddie3909
Guru 10385 points

Hi

I am trying to read from the ADV7171 I2C and it fails. Writes work as I can program color bar output and change modes. The DM648 says it does not receive an ACK during a read.

In the ADI I2C app note, the SCL signal goes low between the device addr and sub addr bytes. The DM648 outputs SCL high between the bytes. I'm not sure that this is the problem, but its something thats different between them.

I checked the I2C spec and couldn't find anything that states what level SCL should be, other than it should transition high when the SDA is low for the ACK bit.

Is there a way to get SCL to go low between device addr and sub addr bytes?

 3157.I2C clock between bytes.doc

In the above doc, the top plot shows what ADI expects (SCL going low between data). The lower plot shows a capture of the DM648 output. SCL is high between data. The "ADI expects" plot is from one of their app notes. The DM648 plot is what was captured using a scope on the DM648.

Thanks

 

 

  • 0
    TI__Guru*** 125430 points

    Eddie,

    The first diagram shows a write to an I2C slave with address 0100001b.  The second diagram shows a read from an I2C slave with slave address 0101011b.  It looks like a simple matter of having the wrong address.  Since you have the wrong address then no device acknowledges you.  The DM648 responds to a NACK by holding SCL low, which is the behavior you're seeing.

    You may want to check out this wiki page if you haven't seen it already:

    http://wiki.davincidsp.com/index.php?title=I2cTips

    Brad

  • 0 in reply to Brad Griffis
    Guru 10385 points

    Hi Brad

    Sorry I didn't explain it better. The two diagrams are not the same device. The first is cut and paste from a ADI doc I got from the internet. So the device addr is most likely different since I have no idea what I2C slave device they were using.

    The second one is from probing the DM648 SDA and SCL lines when talking to a ADV7171 video encoder slave.

    What I want to highlight by the diagrams is SCL going low between bytes in the ADI diag and staying high in the DM648 capture.

    The wierd thing is that I can read the TI video decoder no problem and we have verified setup and hold timing.

    Cheers

     

  • 0 in reply to Eddie3909
    TI__Guru*** 125430 points

    i can't tell from the diagram exactly what's happening.  The 2 diagrams do not correspond well.  In the second diagram the clock being high is because a stop condition is issued.  The last "lump" of clocks in the second diagram show a start condition, slave address (0101011b), Read, but then a NACK, i.e. there is either no slave with address 0101011b or else something is causing the slave not to respond.  Is the ALSB pin tied high?

  • 0 in reply to Brad Griffis
    Guru 10385 points

    Hi

     

    I couldn't find an ALSB pin in the data sheet ??[*-)]

    Cheers

  • 0 in reply to Brad Griffis
    Guru 10385 points

    Hi Brad

    The ALSB bit is set to 1. Hence the address is 0101011. (0x56)

    On the second diagram (the DM648), there is not enough data captured to see the start bit or the 0101 part of the write address
    But you can see the 0110 (0x6 the last 4 bits of the address with b0 at 0 for write,
    then 0 follows (the ACK followed by a blip when the ACK line is released by the ADV7171),
    then 0000 0001 (the subaddress),
    then 0 (the ACK followed by a blip when the ACK line is released by the 7171)
    then both high for a period of about 60 usec
    then 0 (the start bit) followed by 0101 0111 the Read address.
    We expect the next bit should be '0, an ACK by the 7171, but this is not occurring.

    By the fact that the first addr and sub addr are ACK'd, it shows that there is a device listening on the I2C bus.

    I'm wondering if its possible to configure the DM648 to have the SCL signal go low between the 0000 0001 sub addr and the 0101 0111 slave addr.

    I've tried shortening the period between the 0000 0001 and 01010111 and it didn't make a difference.

    Sorry for all the confusion I've caused due to improper diagram descriptions.

    Cheers

  • 0 in reply to Eddie3909
    TI__Guru*** 125430 points

    I think the only way to solve the problem is to get rid of that ADI device.  [;)]

    That particular device has a specific read sequence defined where you must first write the sub-address, then do a "repeat start" and then you can read from that sub-address.  It appears this is a very strict sequence, i.e. you can not issue a stop condition between the write of the sub-address and the read of the data.

    For information on how to implement the repeated start you should read section 4 of this I2C Tips wiki article.

  • 0 in reply to Brad Griffis
    Guru 10385 points

    Hi Brad

    Thanks for the "repeat start" idea. I will try it. The I2C Tips wiki is good.

    Unfortunately, changing the ADV7171 isn't an option (hardware is already done)[:'(]

    I compared the Analog Devices I2C app note Fig 1. READ SEQUENCE to the ADV7171 Rev C. Figure 35. In Fig 35, the slave addr is not issued the second time!

    4174.I2C_tech_note Analog Devices.pdf

    1856.ADV7171 Video Encoder Rev C.pdf

    I wonder if this is a ADI I2C unique thing or an error in their documentation. Fig 35 does not jive with the App note Fig 1.

    Cheers

  • 0 in reply to Eddie3909
    TI__Guru*** 125430 points

    I've seen other devices (e.g. audio codecs) that also require this same sort of sequence.  Specifically, issuing a stop and then a start between writing the sub-address and reading the data will not work on some devices.  For those devices you must use a repeated start.  That appears to be the case here.

  • 0 in reply to Brad Griffis
    Guru 10385 points

    Finally got around to trying the repeated start. It worked.

    (Ironic that we needed a TI guy to help us with and ADI problem - ADI support wasn't helpful)

    Thx and bunch[B*]