Post Go back to editing

ADUM1401 VOD goes momentarily low during power up of VDD2.

Hello,

I'm using the ADUM1401 in an application where VDD1 is up long before VDD2. VID is pulled up to  VDD2 and when I monitor this signal during startup I can see it following VDD2 as expected.

When looking at VOD, this signal is high when VDD2 is unpowered. But during the ramp up of VDD2, a short (5-10 µs) glitch occurs on VOD, which is undesired, because this goes into a falling-edge triggered circuit. What is the cause of this glitch and is there any way to prevent this?

Best regards,

Jan

  • Hello Jan60,

    The ADuM140x outputs will default high when the input side supply is unpowered as shown in Table 15. However, this table details the behavior under static conditions. As you've seen, there is the potential for the output to momentarily switch low while the output side supply ramps up.

    The ADuM340x contains an undervoltage lockout circuit that keeps the device off until the supply voltage is greater than 2.4 V. This family is pin-compatible with the ADuM140x.

    DaveC

  • Hi Dave,

    I'm experiencing the "problem" when the input side is ramping up while the output side is already powered. Would the ADuM340x behave differently in this case?

    Kr,

    Jan

  • The ADuM340x has UVLO circuitry on both sides of the isolation barrier, so it should eliminate the glitch you were seeing during the VDDI ramp.

    Regards,

    DaveC

  • Hi Dave,

    I had other priorities, but I just ordered samples of the ADUM3401. I'll post the result in this thread.

    Kr,

    Jan

  • The ADUM3401 indeed solved the issue. Thanks Dave

  • Apparently, the issue was solved with the ADUM3401 on one of the proto boards.

    On another board, this issue is still present: a small 1µs dip on the output when the input powers up.

  • Can you provide a scope shot of the input supply ramp and output?

  • Hi Dave,

    I attached the scope plot.

    The component is on an SMPS with my ground leads all over the place, so you can ignore the noise.

    You can clearly see the glitch in the output (yellow trace). The width of this glitch is approximately 1µs.

    Kind regards,

    Jan

    This message is subject to the following terms and conditions: MAIL DISCLAIMER<http://www.barco.com/en/maildisclaimer>

  • Hello Jan,

    There are UVLO blocks on both the input and output sides of the device. On the output side, the output goes low if VDDO is below the threshold  and is active above the threshold. This doesn't apply to your case since you're looking at VOD and VDD1 is static. For the input side, if VDDI is below the threshold the input is disabled and internally set to low, and no refresh is set to the receiver. What you're seeing is the internal signal in the VID path being set low before the refresh is disabled.

    There are two potential solutions: hold VID low during the VDD2 ramp, or disable VOD (by pulling VE1 low) until the VDD2 ramp is complete.

    DaveC

  • Hi Dave,

    I’m a bit confused with your last line: “What you're seeing is the internal signal in the VID path being set low before the refresh is disabled”.  Since the sending side is powering up, I’m guessing the refresh is enabled before the internal signal is following the input, momentarily passing the low to the receiving side. Is there an iCoupler that does this in the other order (letting the internal signal follow the input before the refresh is enabled)?

    The problem is that I want the output VOD to remain high, so holding VID low will not help. Disabling VOD until VDD2 has ramped up is also not possible, since both are on separate grounds and the only way to cross is … through the iCoupler.

    The RC filtering on the VOD filters out this glitch, so I can live with it. But I would have preferred to solve it at the root.

    Will the width of the glitch remain fairly constant over temperature and batches?

    Kind regards,

    Jan

    This message is subject to the following terms and conditions: MAIL DISCLAIMER<http://www.barco.com/en/maildisclaimer>