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.

DS90UB947-Q1: MODE_SEL1 and GPIOs

Part Number: DS90UB947-Q1
Other Parts Discussed in Thread: ALP

Hi everybody!

I had an issue with the GPIO1 of the DS90UB947 in conjunction with MODE_SEL1 configuration. While I already found a solution, there was nothing in the datasheet on that particular behavior and maybe someone could provide additional information.

GPIO1 is used as an input to transfer a UART signal the corresponding GPIO of the Deserializer (DS90UB948). That worked fine in the former design with MODE_SEL1 in configuration #1 (0 V) - see Table 8 in the DS90UB947-Q1 datasheet. Because the current design uses coax cable, I changed MODE_SEL1 to configuration #4 (799 mV). Now GPIO1 became an output with permanent low level right after reset and could not be changed by register configuration. After some trial and error I found that setting MODE_SEL1 to configuration #3 (591 mV) made GPIO1 work as expected.

According to Table 8 configurations #3 and #4 should result in the same device functional mode. Does anyone know what's the difference between these two configurations and can share information on that? 

Best regards,

Martin

  • Hello Martin,

    Looking at Table 8 pg33 of the DS90UB947 datasheet, I see that each pair of values has the same listed outcome.

    I will research what is missing related to STRAP function or notes from the table.

    I can see from strap MODE_SEL '1' to '3' that the listed difference is the COAX column.

    Could you discuss the change from differential-STP/STQ to COAX for your application?  

    I will send back information after the internal team research.

    When you tried to use registers to change GPIO1, there is an input output, remote use, and drive level for output.

    see reg 0xE (I think you had already adjusted this) datasheet - 42

    see reg 0x13 - reads the strapping information from the analog input

    the listed MODE controls, can normally be overriden internally

    Regards,

    Joe Quintal

    Regards,

    Joe Quintal

  • Hello Joe,

    thanks for your answer! Our former design used STP cables but we found the connectors somewhat cumbersome and switched to coax cable with MCX connectors. I found that the setting coax vs. STP doesn't make much of a difference in practical use but I wanted it to be in the right mode, just in case...

    After loading configuration #4 with 799 mV at Mode_Sel1 register 0x0E setting doesn't seem to alter the state of GPIO1 pin. I changed the register setting so that GPIO1 should be an output with high level (and read back the register to make sure the content was right) but the pin didn't change.

    I had no time yet to test the other even-numbered configurations but it would be interesting to see if  they also show the strange behavior...

    Best regards,

    Martin

  • Hello Martin,

    Trying to separate your questions into 2 sections.

    1) In the DS90ux949 the third field for Mode Select 1, is listed as REM_EDID_LOAD.

    Trying to keep EXT_CTL and REM_EDID_LOAD the same as your MODE_SEL1, as #1, please try #3 and see if that helps.  I am still researching why GPIO1 should have another function. 

    Note: there are special conditions where a deserializer GPIO input is forward to a serializer GPIO output, also. 

    (2) 

    If you are trying to use MCX and coax cables,  you may have vastly different performance over the STP type cable, no power over coax."

    www.ti.com/.../slyt726.pdf    "" has a discussion of insertion and return loss.

    at the max OLDI Clock (Single) 95Mhz, with 35 bits (or 31 bits) per pixel the Forward Channel bit rate is 3.36Gbps.

    The Back channel depending on deserializer is 5,10,20Mbps. 

    THORLABS has the intended use microwave SMA cable ranges. 

    Regards,

    Joe Quintal 

  • Hello Joe,

    as mentioned in my 1st post configuration #3 works for our system but I'm still interested in more information why #4 doesn't. Please let me know what your team finds out!

    Best regards,
    Martin
  • Hello Martin,
    There are interactions between Deserializer and Serializer during initial backchannel communication. So for a specific experiment, Hold the Deserializer in reset PDB = 0. Reset and Release the Serializer, using the ALP tool, configure the GPIOs for your use. Write and Read them as you expect. Once this works, change the MODE_SEL and repeat again with the Deserializer in PDB-reset.
    Do a register dump, the default values, and your programmed values are known.

    If that works as expected, then repeat with allowing the Deserializer to release from reset. Some Serializers are overwritten in function with the Deserializer. The next part is to get the register maps, so you can see if Deserializer override is occuring.

    Related to all devices, make sure the Power Sequence, strapping voltages are the desired values. A power supply taking too long to ramp, can cause the MODE_SELECT value to change also. Reading this from the I2C register confirms that.

    I asked other application engineers, that is our guess for now.
    Regards,
    Joe Quintal