• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 4 answers
  • Subscribers 33 subscribers
  • Views 1734 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.

DS90UH948-Q1: Configuration and I2C Issue

Richard Elmquist
Mastermind 45250 points
Part Number: DS90UH948-Q1
Other Parts Discussed in Thread: TCA9539, ALP

My customer is asking the following questions:

We are connecting to J13 of the Deserilzer DEV board DS90UH948-Q1EVM. We are using IO Expander EVM withTCA6424A and TCA9539 installed. But we are not seeing any activity on the I2C bus on the deserializer side.   It seems to stop at the Link cable.  When I have hooked up the oscilloscope to the I2C line on the Deserializer side, nothing ever changes.

 I’m pretty sure the addresses are correct.  Right now we are using the default addresses for the serializer and deserializer and they are showing up on the Launchpad and through the bus pirate. 

Serializer Address:            0x0C (x18 & x19)

Des ID (0x06):                     0x2C (x58 &x59)

General Config (0x03):  Setting to 0xDA (turn on pass-through)

When looking through the Launchpad it does come up that it is connected to the deserializer (and it auto-populates DesID 0x06). 

We are trying to send I2C communication through FPDLINK from deserialzer to  the serilizer that has a PIC (lauchpad) connected to the serilizer . Is this possible?


My confusion might be that there is actually no physical I2C connection between the serializer and the deserializer. The customer is assuming that the deserializer, in decoding the FPDLINK signal, will parse out the I2C commands then send them to the I/O expander. This is where I am not sure as it would seem that the I2C commands would have to be sent via an I2C link to then be passed through to the expander. It may be that I do not understand the FPDLINK and what is contained in the signal. Can the customer do this? Please let me know the steps that the customer need to take to be able to do this application.

Thanks for your help with this!

Richard Elmquist

  • 0
    TI__Mastermind 45250 points
    Has anyone had a chance to look at the request above?

    Can you give a time frame as to when you might be able to provide the information?

    Thanks for your help with this!

    Richard Elmquist
  • 0 in reply to Richard Elmquist
    TI__Expert 8165 points
    Hi Richard,

    It is possible to have an I2C master on the serializer or deserializer side. When an I2C master is located on the deserializer side, the I2C commands on the local I2C bus are sampled and sent over the FPD-Link III back channel to the serializer. The following app notes provide general information on this topic:

    www.ti.com/.../snla131a.pdf
    www.ti.com/.../snla222.pdf

    To send I2C command from the deserializer side to the serializer, ensure that the Pass-Thru is set on the deserializer. Also check that the serializer ID is loaded in the deserializer register 0x07.

    Regards,
    Davor
  • 0 in reply to Davor Glisic
    TI__Mastermind 45250 points
    Davor,
    Thanks for your help with this!
    I will let you know if the customer has any further questions.
    Have a great day!
    Richard Elmquist
  • 0 in reply to Richard Elmquist
    TI__Mastermind 45250 points
    Davor,
    The customer is still having issue.
    Do we have any source or example code that might be able to help the customer?
    Is it possible that you might be able to work directly with them?
    Please let me know if might be able to help.
    Richard Elmquist
  • 0 in reply to Richard Elmquist
    TI__Expert 8165 points
    Hi Richard,

    Are they trying to send commands from the Analog LunchPad (ALP)/MSP430 on the serializer side to the IO expander on the deserializer side?

    If so, the MSP430 would act as an I2C master. They should see I2C traffic on the I2C bus that connects to the serializer I2C pins. Can they verify that they see the I2C traffic on the serializer side of the system?

    Can they read/write registers from the deserializer? They should see I2C trafic on the serializer I2C pins, but not on the deserializer I2C pins.

    For accessing the IO expander from the serializer side, they need to ensure that they define SlaveID (serializer register 0x07) by setting the register to the actual I2C address of the remote device. What is the remote device in this case? One of the TCAxxx devices?

    They also need to set the SlaveAliasID (serializer register 0x08) to a unique I2C address. When accessing the remote device from the ALP/MSP430, they should use SlaveAliasID.

    They also need to ensure that the link between a serializer and a deserializer is established and communication is error free. They should check status and error reporting registers on the serializer and deserializer.

    Regards,
    Davor
  • 0 in reply to Davor Glisic
    TI__Mastermind 45250 points
    Davor,

    Thanks for your quick response!

    I will relay these questions to the customer and will let you how the customer responds.

    Thanks for your help with this!

    Richard Elmquist
  • 0 in reply to Richard Elmquist
    TI__Mastermind 45250 points

    Davor,

    Here is the response from the customer:

    Are they trying to send commands from the Analog LaunchPad (ALP)/MSP430 on the serializer side to the IO expander on the deserializer side?

                    Yes this is exactly how we have it set up.  We have tried with our own code (dev board) and with the Launchpad.

    If so, the MSP430 would act as an I2C master. They should see I2C traffic on the I2C bus that connects to the serializer I2C pins. Can they verify that they see the I2C traffic on the serializer side of the system?

                    Yes, we can see traffic on the serializer side.

    Can they read/write registers from the deserializer? They should see I2C traffic on the serializer I2C pins, but not on the deserializer I2C pins.

                    It seems that we can, I have written to the deserializer (through the serializer) and turned on pass-through which resulted in losing an address, but was able to turn it back off to get the address back.

    For accessing the IO expander from the serializer side, they need to ensure that they define SlaveID (serializer register 0x07) by setting the register to the actual I2C address of the remote device. What is the remote device in this case? One of the TCAxxx devices?

    I did set the SlaveID in register 0x07. I will have to look up again which address I used for the IO-Expander.

    They also need to set the SlaveAliasID (serializer register 0x08) to a unique I2C address. When accessing the remote device from the ALP/MSP430, they should use SlaveAliasID.

    I believe I tried this, but I will double check this again.  So I am to assume I create my own I2C address here, one that isn’t already in use?

    They also need to ensure that the link between a serializer and a deserializer is established and communication is error free. They should check status and error reporting registers on the serializer and deserializer.

                When turning on both the serializer and deserializer the respective registers are set with each others’ address.  When they aren’t connected it is shown that the register is not pre-populated.  We are seeing some errors, but it’s a continuously changing error.   It has been a couple of weeks since I have seen this, so I will be setting this all up again tomorrow to see exactly what is going on and will attempt the SlaveAliasID again.

    Here are some additional comments from the customer:

    Having the two dev boards (serializer and deserializer), the serializer pre-populates register 0x06 with the correct Deserializer’s address.  However, the CRC registers are continuously changing.  (Registers  0x0A & 0x0B until they both get to FF. Resetting the registers, they start at 0 and max out again.  Also in Register 0x0C (General Status) has a value of 0x03.

    Please let me know if you have any further questions for the customer. It just seems that they are able to get a proper connection. Is there anything else that could be causing this?

    Thanks for your help with this!

    Richard Elmquist

  • 0 in reply to Richard Elmquist
    TI__Mastermind 45250 points
    Davor,
    Have you had a chance to look at the replies from the customer?
    Please let me know if you have any further questions.'
    Thanks for your help with this!
    Richard Elmquist
  • 0 in reply to Richard Elmquist
    TI__Expert 8165 points
    Richard,

    Yes, I reviewed the comments. It appears that they have some CRC errors (bit errors on the back-channel). Can they check the connection between the SER and DES board? What specific EVMs are they using? Have they modified them? We don't expect any back-channel errors as the back channel signals are running at relatively low datarates (10s of Mbps). Can they get new EVMs?

    Regards,
    Davor