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.

DS90UB948-Q1: I2C communication with Test Pattern Generator running

Part Number: DS90UB948-Q1

Hi Team,

I'm working with the 948/947 devices.  I'm attempting to display a test pattern with the Deserializer while the video side is initializing (which may take up to 5 seconds).  I've noticed when I start the internal TPG the remote ID in register 0x07 is never filled in (zero), and there is no I2C communication from the other side.  The registers show the following:

Reg 0x07 = 0x00, Reg 0x1C = 0x23, Reg 0x22 = 0x00, Reg 0x28 = 0x20

Register 0x1C shows dual link mode, 1-lane mode, and both channels locked.

Doesn't the remote ID get filled in by the Serializer once RX lock has been detected? 

If I don't start the TPG, the remote ID is filled in every time.

Any info would be appreciated.

Best regards,

  • Hello,
    We received your query and this has been assigned to an owner for review.
  • Hi Tim,
    I will try test your condition by the end of this week.

    Regards,
  • Hi Darryl,

    Also, starting the Serializer test pattern generator appears to disable the I2C communication with the Deserializer.  Let me know what you find out.

    Regards,

    Tim

  • Any update on this issue?
    Thanks,
    Tim
  • We are having the same problem. Page 3 of the app-note SNLA132C and other comments in the datasheet imply that i2c communication across the link is available whenever the link is up. T.I. has an FAE in Detroit that probably knows the answer.
  • Hi Darryl,

    Were you able to replicate this issue?  It seems that starting the Deserializer TPG results in loss of I2C communication with the Serializer.  Likewise, starting the Serializer TPG results in loss of I2C communication with the Deserializer.  SNLA132C states or implies that bidirectional I2C should work with internal TPG.  There's no mention of this limitation.  Can this be confirmed or is there a workaround? 

    Best Regards,

    Tim

  • Has anyone been able to perform i2c operations over the link while either end is generating a test pattern?
  • I2C channel should work even when the TPG is started. Is the device locked? We may need to come back and ask for register dumps from the customers. We will set up a representative system and get back if we see any issues on our setups but we do not expect to see any issues

  • Yes, the channels were locked. The original post shows some of the register values. Let me know if you'd like to see additional registers. Thanks for looking into this.

    Best regards,
    Tim
  • Hi Tim

    I made the same setup on EVM, but can't replicate the issue. 

    Mode selection of 947 is: Mode_sel 0, 100; Mode_sel1, 000

    Mode selection of 948 is: Mode_sel0, 000; Mode_sel1, 000

    On 948, Reg 0x1c is 0x23, Reg 0x22 is 0x40 (the pass RGB bit is not available for UB devices, so it's fine), Reg 0x28 is 0x01 (bit 5 indicates the forward channel is not sending active video)

    Could you show me the setup of pattern generator? The value of Reg 0x64, 65, 66, 67 on 947.

    Best regards,
    Cera

  • Hi Cera,

    It will take me a few days to reestablish the test framework and obtain live debug values. However, inspecting the code I show the following for the 948 TPG. The initial post was for the 948 TPG.

    Reg 0x64 = 0x51, Reg 0x65 = 0x04, and 0x66, and 0x67 are set accordingly when writing to indirect registers.

    The TPG displays a blue screen, but subsequent I2C operations between Ser/Des are inoperative. What are you using to verify the I2C transactions?

    I'll have more info by the weekend.

    Best regards,
    Tim
  • Hi Tim,

    You can save all the register values when you test. Could you give me your email so that I can send my register setups to you? You may compare my registers with yours.

    Best regards,
    Cera
  • Hi Cera,

    I recreated the test environment and captured the register settings.  How are you verifying I2C communications after the 948 TPG is started?  

    My test setup involves two ARM processors, the 948 on one, and the 947 on the other.  I'll label these as ARM/948 and ARM/947.  After starting the 948 TPG, then ARM/947 can no longer talk to ARM/948 via the I2C.  I'm wondering if the TPG disables forwarding of I2C messages.  That's why I'm asking how you verified the I2C transactions.  It's not simply talking to 947 or 948 via I2C.

    I did notice that when I started the 948 TPG I could read the 948 registers, but not the 947 registers.  This was done from the ARM/948 side.  Does this occur for you, too?

    You can send me your register setting using my gmail account.  And, I can reciprocate by sending back my settings.  Use txylozwa for the name.

    Best regards,

    Tim

  • Hi Tim,

    The pattern generator on 948 is designed to test the 948-display link. If you use the pattern generator, the 948 clock is from the pattern. 947 and 948 use different clock, so they cannot communicate. Could you tell me why you use 948 to generate pattern? I suggest to use 947 to generate the pattern, and it can be used to test the 947/948 link and as well as the 948-display link.

    Best regards,
    Cera
  • Hi Cera,

    I'm traveling this week, so sorry for the delayed reply. The reason for using the 948 to generate the test pattern is that it's the side that boots up first. The ARM/947 may take up to 10 seconds to boot. Hence, we opted to display a test pattern from the 948 while the 947 side finishes booting.

    Regarding the different clocks are you saying that the I2C communications will not work with the 947 while the 948 TPG is running?

    Best regards,
    Tim
  • Hi Tim,

    Yes, the I2C communication will not work with 947 when 948 TPG is running.

    Best regards,
    Cera