Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

PCA9306: Vref2 falling below threshold, what is the timing requirement that the chip could still working? (urgent)

Part Number: PCA9306
Other Parts Discussed in Thread: TCA9511A

Tool/software:

Hello support team,

As we've discussed before, Vref2's voltage stability has a lot to do with the behavior of PCA9306.

When there is the noise coming from the system resulting the Vref2 dropping below recommendation (2.1V), the chip will work abnormally.

However, adding a decoupling cap at Vref2 to avoid the noise would be the great solution to resolve this problem.

My customer is already doing the next generation project adding the decoupling cap, however, they still need to resolve the problem that those end equipment being already released.

They've ended coming up with the shorter cable to reduce the noise, please see the chart of the experiment below:

What we want to ask is that, is there the timing requirement that between what timing could the chip still works correctly?

I have two assumptions here:

1. more than about a period, Ex: 5us. Since the data we got are all smaller than 1us, and we can convince the customer that this is the short-term solution.

2. based on your experience, the data above would be able to support, but we do not have the numerical data at hand.

Could you please help to give some suggestion?

Thanks.

Dave

  • Hi Dave, 

    As we've discussed before, Vref2's voltage stability has a lot to do with the behavior of PCA9306.

    I am unfamiliar with the initial problem. Is there a previous thread for this case? 

    1. more than about a period, Ex: 5us. Since the data we got are all smaller than 1us, and we can convince the customer that this is the short-term solution.

    2. based on your experience, the data above would be able to support, but we do not have the numerical data at hand.

    It is hard to tell what exactly is happening on the customer system. Do we have a schematic of the customer implementation for the PCA9306? 

    Are there scope captures that show the VREF2 drop? 

    My guess at the table is that VREF2 drops below 2.2V for a time delta T (nanoseconds). The shorter the cable, the less time VREF2 < 2.2V. 

    How long can the HDMI monitor work for when VREF2 < 2.1V? 

    This question seems like it is more of a test for the customers HDMI monitor rather than a test for the PCA9306? 

    Regards,

    Tyler

  • Hello Tyler,
    e2e.ti.com/.../pca9306-vref2-falling-below-threshold-what-is-the-timing-requirement-that-the-chip-could-still-working-urgent

    The thread is here(internal forum).
    The assumption is correct, the shorter the cable between customer’s board and HDMI monitor, the dropping time shorter.
    Is there a way to say that the short cable is enough for solving the problem? (0.85m for 870ns)
    Customer would like to know if there is no risk.

    Dave

  • Hello Tyler,
    e2e.ti.com/.../pca9306-vref2-falling-below-threshold-what-is-the-timing-requirement-that-the-chip-could-still-working-urgent

    The thread is here(internal forum).
    The assumption is correct, the shorter the cable between customer’s board and HDMI monitor, the dropping time shorter.
    Is there a way to say that the short cable is enough for solving the problem? (0.85m for 870ns)
    Customer would like to know if there is no risk.

    Dave

  • Hi Dave,

    I believe you sent the link to this thread.

    e2e.ti.com/.../pca9306-vref2-falling-below-threshold-what-is-the-timing-requirement-that-the-chip-could-still-working-urgent

    Is there another one? 

    Is there a way to say that the short cable is enough for solving the problem? (0.85m for 870ns)

    I think this is dependent on the HDMI Monitor spec? 

    Can it handle <2.2V for 870 ns before failing? 

    PCA9306 is probably okay, however, I need to double check the schematic if you have one. 

    Regards,

    Tyler

  • Hello Tyler,

    (1) PCA9306: Unwillingly voltage spike at SMBUs clock resulting in the error - Interface - INTERNAL forum - Interface - INTERNAL - TI E2E support forums

    Please see this link, thanks.

    LX-VC01N_Vref2 measurement with different cables_1105.xlsx

    Also, I've sent out the experiment that we done for this case.

    I think the answer we need is that, can we make sure that the length ex:0.85m is OK for the usage?

    As Michael replied before, I agree with the noise would generating the failure at Vref2 pin, but we need the numerical result to convince our customer, thanks.

    Dave

  • Hi Dave,

    I see the discussion continued over email. Is there any other info I am missing on this case? 

    ""The problem happens at connecting the motherboard to VGA-UHDSP2 : https://www.sanwa.co.jp/product/syohin?code=VGA-UHDSP2, and then passing to monitor.""

    The issue seems to be a result of the VGA-UHDSP2 device connecting to the HDMI connector to the PCA9306 through a long cable. 

    However, the issue is not due to our PCA9306 level translator. The spike is not being caused by TI's device. The spike is being caused by excess capacitance being charged upon the initial connection of the HDMI module. 

    I don't see how I can provide an answer if 0.85m is okay for usage... This is a system level problem not a PCA9306 problem. The customer will need to conduct the necessary cable testing to determine if their system will work or not. 

    In cases like these, I would generally recommend some type of hot-swap buffer for this application. Something like the TCA9511A controls the Input and Output sides and connects them only after each side is idle HIGH. This avoids the signal dropping in the case of cable connection. 

    However, TCA9511A would not work since the PCA9306 is level translating and this is an HDMI connection (not I2C). Has the customer considered controlled the PCA9306 EN pin to keep the PCA9306 in High-Z while the cable connection is being made? This way the excess cap loading does not pull the signal to GND upon the initial connection. 

    Regards,

    Tyler

  • Hello Tyler,

    Thanks for the explanation.

    I think we need the timing confirmation from your side.

    We already find the solution that the reason is caused by noise, however, do we have the numerical data here?

    What I need to know is that when the Vref is below the suggested voltage, how long will the chip still be at working state?

    Based on the chart here, if the Vref2<2.2V time is <1us, could we say that this is ignorable?

    If it is, I think we can totally resolve this issue.

    Thanks.

    Best Regards.
    Dave

  • Hi Dave,

    What I need to know is that when the Vref is below the suggested voltage, how long will the chip still be at working state?

    The PCA9306 is always in a "working state." 

    The correct usage of the PCA9306 is dependent on customer application. 

    The PCA9306 is operating as it should be according to the datasheet as long as the voltage translation condition is met: 

    If we follow the note:

    Voltage translation is not supported when VREF2 drops < 2.4V. Therefore, the device is not operating correctly when a voltage of VREF2 < 2.4V is present on the supply pin. 

    The question that should be asked is whether or not the customers HDMI can handle that large of a drop out. 

    For the correct usage of the device in the customer's application, I would suggest always keeping VREF1 = 1.8V, which means EN = ~ 2.4V, while VREF2 = 5.0V. 

    If there is significant drop in voltage on VREF2, I would consider adding a larger decoupling capacitor on the VREF2 pin as this will help to hold VREF2 at 5.0V and prevent large drop outs in voltage due to connecting the cable. 

    Regards,

    Tyler