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: Clarification on 0xDB Command Usage for UCD9032 Remote Upgrade

Part Number: UCD90320

Hi team,

I have a query regarding the 0xDB command used to make a UCD remote upgrade effective.

Does issuing the 0xDB command inherently follow the required power-down sequence? If not, could you please advise on the recommended procedure to perform a UCD remote upgrade while maintaining the proper power-down and power-up sequence?

Thank you for your guidance.

Best regards,
Elsa Eldhose

  • Hi 

    No DB command is to reset the device and no sequence to follow

    regards

    yihe

  • Hi Yihe,

    We would like to ensure that the correct sequence is followed during the reset process after the upgrade. Since the 0xDB command for a soft reset does not support maintaining this sequence, could you please suggest an alternative method that would allow the sequence to be followed?

    Best regards,
    Elsa

  • HI

    If that's the user case, the rails need be off first.

    you can do the reversed order of the turn on.

    Regards

    Yihe 

  • Hi Yihe,

    We need clarification on how GPI Faults interact with the "Faults shutdown other rails" feature in Fusion Digital Designer.

    Setup:

    • One EN pin is connected to a GPIO
    • GPIO is configured as:
      • GPI
      • GPI Fault enabled
      • Active High polarity
    • EN default state is Active High
    • Writing 0 to this pin is done via PMBus GPIO commands (0xFA GPIO_SELECT,0xFB GPIO_CONFIG).
    • In GPI Fault Responses, when this GPI is driven low (fault condition), only some rails are configured to shut down
    • Separately, the system is configured such that if any rail faults, all rails should shut down

    Questions:

    1. When we deliberately write 0 to the EN pin and trigger a GPI fault, how does the controller classify this event?
      1. Is it treated as a rail monitoring fault (OV/UV/OC/OT/TON_MAX)?
      2. Is it treated as a PMBus user‑triggered fault?
      3. Or is it treated as a GPI‑originated fault, independent of rail monitoring faults?
    2. When the GPI fault shuts down the selected rails, will this action cause a cascading shutdown of all rails because the system is configured to shut down all rails when any rail faults?

    Best Regards,
    Elsa Eldhose

  • HI

    I saw the same question posted in a separated thread.

    We will like to have one thread for one particular question. so this thread will be closed.

    Regards

    Yihe