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.

DS90UB954-Q1: REFCLK Sequencing?

Part Number: DS90UB954-Q1

Hi,

What is the REFCLK sequencing requirements?

I notice in section 7.4.4 of the datasheet it says: "REFCLK should be applied to the DS90UB954-Q1 only when the supply rails are above minimum levels"

Then it looks like in Figure 55 that REFCLK is being applied before the supply rails are above minimum levels (REFCLK applied as VDD starts to ramp up). What is the correct sequencing?

I also notice the DS90UB954-Q1 I2C does not ACK when I have a 26MHz REFCLK applied. However it does ACK when I remove the REFCLK (REFCLK pin is open). I am using the ASEDV-26.000MHZ-LR-T as a 26MHz REFCLK. I must be missing something in the datasheet - why is it unresponsive when the 26MHz REFCLK is applied?

See a scope capture of REFCLK below. Note the device is operating in VDD_SEL=LOW, and VDDIO = 1.8V.

Thanks,

Nicholas

  • Hello Nicholas, Figure 57 in the 954 datasheet shows a detailed power-up sequence assuming you are using synchronous mode. If not then look at figure 58 for the power-up sequence. As for the REFCLK it must meet the specs given in table 3 which according to your scope capture it looks like it is. Are you able to verify your power-up sequence with the scope showing the power rails and the REFCLK sequence is following figure 57? Regards, Nick

  • Hi Nick. Thanks for the reply, yes I am using synchronous mode. See the REFCLK sequencing below. Note that PDB is pulled high well after this. Still, the 954 is unresponsive when the REFCLK is applied as described in the previous post. Thanks for your help, Nicholas.

     

  • Hello Nicholas,

    Can you make it such that the REFCLK is available to the 954 prior to PDB going high?  Then check register 0x04[4] to see if it is showing valid REFCLK.

    If issues persist can you get a scope capture showing the actual power sequence?  Show the power rails, PDB, and REFCLK.

    Regards,

    Nick

  • Hi Nick,

    Yes, REFCLK is available to the 954 prior to PDB going high. Note The PDB pin has a 33kohm pull up and 10uF cap to ground (recommended in the datasheet). As referenced in the previous post, PDB is pulled high well after REFCLK is applied. See the zoomed out scope capture below.

    I am not able to check that register (or any register), because the 954 is unresponsive (NACKs) when the REFCLK is applied. The 954 does however ACK and I am able to read registers when REFCLK is removed.

    Thanks,
    Nicholas

  • Hello,

    Can you decrease the REFCLK Vpp?  It looks like you are slightly above your VDDIO of 1.8 volts which is not recommended in table 3.  Also can you put the I2C lines on the scope?  I want to see if it NACKs or if it is completely unresponsive.

    Regards,

    Nick

  • Hi Nick,

    I'll see what I can do about REFCLK Vpp.

    In the meantime, see the I2C lines below. Note the cross-talk is because of my probing method, not the PCB.

    Thanks,

    Nicholas

  • Hi Nicholas,

    I know if the clock source is too far outside of the spec then the device will not recognize it and should continue to use the internal AON clock.  But I don't believe this is part of your issue.  If you start the device without REFCLK available and apply it after some time.  Try to do register reads before it is active and after.  See if the device can see a valid clock in register 0x04[4].

    Regards,

    Nick

  • Hi Nick,

    I can do register reads before applying REFCLK, but after I apply REFCLK it has the NACK'ing issue so I cannot read register 0x04 while REFCLK is applied.

    Thanks,

    Nicholas

  • Hi Nick,

    I lowered REFCLK Vpp to approx 1.2V, and I am still seeing the same issue. See scope capture of REFCLK below:

    Thanks,

    Nicholas

  • Hello,

    This is definitely a strange issue here, have you tried on any other units?  Are you able to provide a register dump of the device without the REFCLK and the IDX/MODE strapping?  Also I sent you a connection request can you share your schematic over private message?  One last thing are you able to verify that the 954 still has LOCK to the serializer when using the REFCLK and the issue is only related to I2C?

    Regards,

    Nick

  • Hi Nick,

    I see same the results on two other units (3 out of 3 show the issue).

    See register dump attached.

    I messaged you the schematic.

    I'll let you know about LOCK to the serializer.

    Reg_Dump.txt
    TI954 Reg Dump on start up
    IDx = 0V
    REFCLK pin is open
    
    Register: Value
    0x00: 0x60
    0x01: 0x00
    0x02: 0x1e
    0x03: 0x00
    0x04: 0xc3
    0x05: 0x01
    0x06: 0x00
    0x07: 0xfe
    0x08: 0x1c
    0x09: 0x10
    0x0a: 0x7a
    0x0b: 0x7a
    0x0c: 0x83
    0x0d: 0x09
    0x0e: 0x08
    0x0f: 0x7f
    0x10: 0x00
    0x11: 0x00
    0x12: 0x00
    0x13: 0x00
    0x14: 0x00
    0x15: 0x00
    0x16: 0x00
    0x17: 0x00
    0x18: 0x00
    0x19: 0x00
    0x1a: 0x00
    0x1b: 0x00
    0x1c: 0x00
    0x1d: 0x00
    0x1e: 0x04
    0x1f: 0x02
    0x20: 0x30
    0x21: 0x01
    0x22: 0x00
    0x23: 0x00
    0x24: 0x00
    0x25: 0x00
    0x26: 0x00
    0x27: 0x00
    0x28: 0x00
    0x29: 0x00
    0x2a: 0x00
    0x2b: 0x00
    0x2c: 0x00
    0x2d: 0x00
    0x2e: 0x00
    0x2f: 0x00
    0x30: 0x00
    0x31: 0x00
    0x32: 0x00
    0x33: 0x00
    0x34: 0x40
    0x35: 0x00
    0x36: 0x00
    0x37: 0x00
    0x38: 0x00
    0x39: 0x00
    0x3a: 0x00
    0x3b: 0x01
    0x3c: 0x14
    0x3d: 0x6f
    0x3e: 0x00
    0x3f: 0x40
    0x40: 0x00
    0x41: 0x86
    0x42: 0x74
    0x43: 0x01
    0x44: 0x00
    0x45: 0x00
    0x46: 0x00
    0x47: 0x00
    0x48: 0x00
    0x49: 0x00
    0x4a: 0x00
    0x4b: 0x12
    0x4c: 0x00
    0x4d: 0x00
    0x4e: 0x02
    0x4f: 0x00
    0x50: 0x00
    0x51: 0x00
    0x52: 0x00
    0x53: 0x00
    0x54: 0x00
    0x55: 0x00
    0x56: 0x00
    0x57: 0x00
    0x58: 0x1e
    0x59: 0x00
    0x5a: 0x00
    0x5b: 0x00
    0x5c: 0x00
    0x5d: 0x00
    0x5e: 0x00
    0x5f: 0x00
    0x60: 0x00
    0x61: 0x00
    0x62: 0x00
    0x63: 0x00
    0x64: 0x00
    0x65: 0x00
    0x66: 0x00
    0x67: 0x00
    0x68: 0x00
    0x69: 0x00
    0x6a: 0x00
    0x6b: 0x00
    0x6c: 0x00
    0x6d: 0x7c
    0x6e: 0x88
    0x6f: 0x88
    0x70: 0x2b
    0x71: 0x2c
    0x72: 0xe4
    0x73: 0x00
    0x74: 0x00
    0x75: 0x00
    0x76: 0x00
    0x77: 0xc5
    0x78: 0x00
    0x79: 0x01
    0x7a: 0x00
    0x7b: 0x00
    0x7c: 0x20
    0x7d: 0x00
    0x7e: 0x00
    0x7f: 0x00
    0x80: 0x00
    0x81: 0x00
    0x82: 0x00
    0x83: 0x00
    0x84: 0x00
    0x85: 0x00
    0x86: 0x00
    0x87: 0x00
    0x88: 0x00
    0x89: 0x00
    0x8a: 0x00
    0x8b: 0x00
    0x8c: 0x00
    0x8d: 0x00
    0x8e: 0x00
    0x8f: 0x00
    0x90: 0x00
    0x91: 0x00
    0x92: 0x00
    0x93: 0x00
    0x94: 0x00
    0x95: 0x00
    0x96: 0x00
    0x97: 0x00
    0x98: 0x00
    0x99: 0x00
    0x9a: 0x00
    0x9b: 0x00
    0x9c: 0x00
    0x9d: 0x00
    0x9e: 0x00
    0x9f: 0x00
    0xa0: 0x02
    0xa1: 0x0f
    0xa2: 0x00
    0xa3: 0x00
    0xa4: 0x08
    0xa5: 0x00
    0xa6: 0x00
    0xa7: 0x00
    0xa8: 0x00
    0xa9: 0x00
    0xaa: 0x00
    0xab: 0x00
    0xac: 0x00
    0xad: 0x00
    0xae: 0x00
    0xaf: 0x00
    0xb0: 0x00
    0xb1: 0x00
    0xb2: 0x00
    0xb3: 0x08
    0xb4: 0x25
    0xb5: 0x00
    0xb6: 0x08
    0xb7: 0x00
    0xb8: 0x8c
    0xb9: 0x33
    0xba: 0x03
    0xbb: 0x74
    0xbc: 0x80
    0xbd: 0x00
    0xbe: 0x00
    0xbf: 0x00
    0xc0: 0x00
    0xc1: 0x00
    0xc2: 0x00
    0xc3: 0x00
    0xc4: 0x00
    0xc5: 0x00
    0xc6: 0x00
    0xc7: 0x00
    0xc8: 0x00
    0xc9: 0x00
    0xca: 0x00
    0xcb: 0x00
    0xcc: 0x00
    0xcd: 0x00
    0xce: 0x00
    0xcf: 0x00
    0xd0: 0x00
    0xd1: 0x43
    0xd2: 0x94
    0xd3: 0x07
    0xd4: 0x60
    0xd5: 0xf4
    0xd6: 0x00
    0xd7: 0x00
    0xd8: 0x00
    0xd9: 0x00
    0xda: 0x00
    0xdb: 0x00
    0xdc: 0x00
    0xdd: 0x00
    0xde: 0x00
    0xdf: 0x00
    0xe0: 0x00
    0xe1: 0x00
    0xe2: 0x00
    0xe3: 0x00
    0xe4: 0x00
    0xe5: 0x00
    0xe6: 0x00
    0xe7: 0x00
    0xe8: 0x00
    0xe9: 0x00
    0xea: 0x00
    0xeb: 0x00
    0xec: 0x00
    0xed: 0x00
    0xee: 0x00
    0xef: 0x00
    0xf0: 0x5f
    0xf1: 0x55
    0xf2: 0x42
    0xf3: 0x39
    0xf4: 0x35
    0xf5: 0x34
    0xf6: 0x00
    0xf7: 0x00
    0xf8: 0x00
    0xf9: 0x00
    0xfa: 0x00
    0xfb: 0x00
    0xfc: 0x00
    0xfd: 0x00
    0xfe: 0x00
    0xff: 0x00

    Thanks,

    Nicholas

  • Hi Nicholas,

    Thank you for sending the schematic allow me some time to review.

    Regards,

    Nick

  • Hi Nick,

    I got your latest message. See the register dump in my previous message on this thread. And yes, it happens on multiple devices. I appreciate your help.

    Thanks,

    Nicholas

  • Hi Nicholas,

    Thank you for coming back to this forum, it is the best way for me to track open issues.  I just wanted to take things offline in case you didn't want to share a schematic on a public forum.  As for the refclk issue, you said that as soon as you apply it to the refclk the chip NACKs?  Can you inject an external clock source like a function generator to generate a clock signal?  

    Can you also pull the remote registers for me as well?  

    Regards,

    Nick

  • Hi Nick,

    No problem, I appreciate you letting me share the schematic privately. Unfortunately, supplying REFCLK via a function generator is a no go due to poor signal integrity. To change the REFCLK frequency, I will have to order a 25MHz oscillator to replace the 26MHz oscillator that is currently on the board.

    Also there are no remote registers right now, I have not connected it to a serializer yet.

    Thanks,

    Nicholas

  • Hi Nicholas,

    Okay, that's too bad I thought we could try to adjust the signal until we found something that worked.  So its not possible to try any other clock source here? 

    Regards,

    Nick

  • Hi Nick,

    Yes, it's unfortunate. I can order a 25MHz clock source and replace the 26MHz one. Heads up, it might be a while before I get that tested. Some other projects are currently taking priority over this one. However, I will come back to the forum when it is tested.

    Thanks,

    Nicholas

  • Hi Nicholas,

    Were you ever able to verify that you can LOCK to a serializer?  Also the waveforms you are showed in the images are probed right at the pin of the part right?

    Can you also probe the power pins again with a differential probe and a max bandwidth of MHz and zoom in to get a power noise measurement?  Maybe somehow the oscillator is coupling noise onto the PCB and is interfering with the device.

    Regards,

    Nick

  • Hi Nick,

    I hope you are well. I am back on this project again, so I'll be able to reply more regularly. Thank you for your patience.

    No, was not able to verify a LOCK to a serializer.

    Yes, the waveform is probed at the pin.

    Note I just replaced the 26MHz reference with a 25MHz one (PN: ASEDV-25.000MHZ-LR-T), and it has the same issue.

    Can you tell me more about the internal 25MHz oscillator described in section 7.4.4 of the datasheet? Is this internal oscillator sufficient enough to LOCK to a serializer or stream CSI data out? Note I was not able to LOCK to a serializer when using the internal oscillator.

    I'll see what I can do about probing the power pins.

    Thanks,

    Nicholas

  • Hi Nicholas,

    The internal oscillator is primarily there to make sure that you can still communicate to the device with I2C if the clock signal is lost.  It is not sufficient to maintain stable LOCK.  With that said you may be able to achieve LOCK and out put valid CSI data while using it, but it isn't robust enough for a production setting.

    Regards,

    Nick

  • Hi Nick,

    What is the required PDB voltage for normal operation? There seems to be a contradiction in the datasheet.

    Section 9.2.1 and Typical applications recommend using a 33kohm pull up to 1.8V with 10uF to ground on PDB. With the internal 50kohm pull down on PDB, the node will sit at approx. 1V. This contradicts the normal operation PDB voltage detailed on page 7 of the datasheet (which says normal operation PDB > 1.5V). See the highlighted sections in the datasheet below:

    Thanks,

    Nicholas

  • Hi Nick,

    I may have found something I am violating in the datasheet, but it's still not quite adding up.

    Table 229 details the start up sequence timing. T3 says the minimum VDDIO rise time is 0.2 ms. If you look back to my 2nd post, I have a scope capture of 1.8V rail and REFCLK start up. Note that the rise time for the 1.8V rail is 0.1ms, which is less than the 0.2ms spec.

    Do you think this violation is causing an issue during startup? Also note I can talk to the deserializer using this rise time of 0.1ms when the REFCLK is disabled (0 ohm resistor between oscillator and REFCLK pin removed).

    Maybe also related to this issue, I have found a startup sequence where I can communicate to the deserializer via I2C while the REFCLK oscillator is enabled (recall the original problem was that I could not communicate whenever REFCLK was applied). The startup sequence involves me slowly cranking up the 1.8V rail supply voltage from 0V-1.8V by hand, 100mV at a time using a DC power supply. If I do this, I can communicate via I2C to the deserializer while REFCLK is applied. However, if I read the status register it does not show a valid clock is applied (register 0x04[4]).

    Any idea why the register does not show a valid clock is applied with this updated startup sequence?

    Hoping you can help shed some light on these results.

    Thanks,

    Nicholas

  • Hi Nicholas,

    To answer your first question I would still follow the recommended layout given in the datasheet.  As for the contradiction, I think it could be worded a bit better however you should be able to measure the voltage at the pin and you will see 1.8 volts.

    For your second question I suppose it is possible that the ramp time may be an issue, it is hard to know every possible failure if the specs are not met but it would be good to adjust if possible.  Also if it is showing no valid refclk is available that leads me to believe that the device is locked to the internal oscillator and not receiving the clock.  Are you able to probe right at the pin and ensure that it is getting all the to the device?

    Regards,

    Nick

  • Hi Nick,

    Are you sure you PDB should be sitting at 1.8V? If I measure the pin, it reads 1.06V which agrees with the equation for a 33kohm and 50kohm voltage divider.

    Also, I am able to reduce the ramp time however the issue still persists. Yes, I can see a clean REFCLK when probing on the pin.

    Do you think this is a sequencing error?

    Thanks,

    Nicholas

  • Hi Nicholas,

    I would think this is is a sequencing issue but I thought you already shared the power-up sequence and it seemed to be matching.  Can you maybe share a more detailed sequence showing VDD18, PDB, REFCLK, and VDDIO?  We can take a full look at the sequence.

    Regards,

    Nick

  • Hi Nick,

    Yes, the previously posted waveform captures shows the full sequence:

    1. VDD18 is turned on (VDDIO tracks VDD18 very closely)

    2. REFCLK turns on shortly after

    3. PDB charges slowly and eventually pulls the device out of reset

    I have also tried enabling REFCLK after PDB goes high, and the issue still persists.

    Side note: I noticed that if I FORCE_REFCLK_DET in register 0x02[0] before enabling REFCLK that I can communicate with the deserializer after enabling REFCLK. However, register 0x04[4] and 0x04[2] still shows invalid REFCLK and no lock to the serializer.

    Thanks,

    Nicholas

  • Hi Nicholas,

    Let me check with my team again and see if there are any better ideas.

    Regards,

    Nick

  • That would be great. I appreciate it, Nick.

    Thanks,

    Nicholas

  • Hello Nicholas,

    So first thing here is the internal pull-down on the PDB is relatively strong as you mentioned.  It would be good to try a much lower value on the external pull-up, I think something like 1k - 5k could work better in keeping the PDB voltage above the necessary threshold. 

    Another thing to try is to show a similar scope capture as you showed before but instead of showing the enable signal of the oscillator, show it actually oscillating, along with VDD18 and PDB.

    Finally on the one scope capture you shared of the oscillator compared to VDD18, this clock signal appears to have a bit of an offset.  Is it possible that offset is present currently and is causing the clock signal to not go below the VIL threshold?

    Regards,

    Nick

  • Hi Nick,

    I switched the pull up to 3.3kohm and the capacitor to 20uF. The issue persists.

    See the scope capture you asked for below:

    If I recall correctly, the offset you're referring to was because of how I probed. As you can see in the latest scope capture and on the previous zoomed in REFCLK scope capture, it oscillates from 0-1.8V. 

    Thanks,

    Nicholas

  • Thank you for sharing the additional screenshots.  Also did you probe the voltage on the PDB pin?  Can you confirm it is above 1.5V?

    Regards,

    Nick

  • Yes, PDB sits at 1.7V.

    Thanks,

    Nicholas

  • Hi Nick,

    I am somewhat skeptical of the deserializer IC on my board. See the device marking in the picture below. There is a "P" in front of the "UB954Q". If I look up "PUB954Q" on TI's part marking lookup, nothing comes up. Have you seen this device marking before and can you confirm that it is a genuine TI part? I'm not sure where our turnkey sourced this part from. I just sent them an email, asking about it.

    Do you have some samples laying around that you can send me? I would like to be sure that the IC is the issue, and not the board/schematic. It would be extremely helpful if you're able to send some.

    Thanks,

    Nicholas

  • Ok now we are getting somewhere.  The P in the PUB954 stands for prototype which is a problem.  I think for some older parts they needed a different clock frequency but I would need to look into that.  The best place to go for samples is samples.ti.com however the stock is probably very low.  Let me check if there is anything I can do but probably will be very difficult. 

    Regards,

    Nick

  • Hi Nick,

    Ah I see. Is a different clock frequency the only difference? Also does that mean it is not compatible with a UB953 serializer?

    Yes, unfortunately there is no stock on samples.ti.com. I would buy from Arrow, Digikey or Mouser but they do not have stock either.

    That would be great if you could find something. Worst case, a UB936 might work as an alternate to the UB954.

    Thanks,

    Nicholas

  • Hi Nicholas,

    So there is going to be a large number of differences between your device and the production level device.  It could still work with 953 but it would not be worth the time to try and dig up some scripts that may be hundred or thousands of lines long.  I think all stock is going to be out for the foreseeable future but 936 will work as an alternative.

    Regards,

    Nick