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.

UCD90320: Maximum delay from CTRL pin -> low to first EN -> low?

Part Number: UCD90320

Hello,

Is there a predictable maximum delay time between the PMBus CONTROL pin being pulled low and the first EN in sequence being de-asserted?

I checked on the bench using the UCD90320EVM-783 and manually toggling CTRL in the Fusion GUI, and observed delays from 8 us to 20 us across ~20 attempts. In my application, I need this value to be <= 100 us.

If the CTRL pin can't give me <= 100 us delay time, is there a GPI that is faster that would?

Thanks,

Jonathan

  • The max delay will be over 100us since EN is updated at 100us interval.

    Thanks

    Yihe

  • Hi Yihe,

    Thanks for the reply. So if EN is updated at 100 us intervals, we could worst-case expect +100 us for the EN state change.

    What kind of delay is there on the front end + logic (recognizing that CTRL has changed states, and the internal logic to propagate that to the EN value)?

    Even though the total operation will be greater than the initial 100 us target, it might be okay, if we can quantify the upper limit.

    Thanks,

    Jonathan
  • The processing time of detecting CTRL is kind of dynamic and could be range up to 150us if there are heaving processing due to GPI interrupts/ faults responses/LGPO evaluation. if before CTRL toggles, the system is running without much loading(fault, GPI interrupts, LGPO), the uppliver would be 50us at most for the frond end + logic.
    Regards
    yihe
  • Thanks Yihe. So worst case we could expect 250 us from CTRL going low to the first EN being de-asserted, with typical values much less than that based on loading / program, as observed on the EVM.

    Jonathan