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.

UCD90160A: Alert Assert and Reset count

Part Number: UCD90160A
Other Parts Discussed in Thread: UCD90320, UCD9090A, UCD90160

I have questions about 2 different UCD90xxx Features

Feature 1: Alert Signal

On a system with 2 UCD90160s, we see the ALERT signal (combined from both devices) from the devices asserted approximately every 60 seconds for 25ms. We believe the cause is an Invalid Command as reported by the CML register - command 0x8D occurs approx every 60 seconds. That is, the Read_Temp1 command which, according to the manuals, is not supported on the UCD90160A.

1. Is this the expected behavior for an invalid command? That is, the alert asserts for 25ms and then de-asserts on its own?

2. Does a read of register 0x8D cause an alert to be asserted on the UCD90160A device? What should be the duration of the alert?

3. With this condition occurring, if read_vout register is read for all rails, the alert assert stops.
Why does the alert stop, if the invalid command is still occurring and no ARA msg is sent?

4.If we access the 0x8D register via "i2cget -y -f 13 0x67 0x8D", there is no alert asserted. Why?

Feature 2: Reset Count

We want to use the reset count feature but see different behavior to enable the feature on different UCD90xxx devices.

Procedure 1 works on UCD9090A but not on UCD90160A or UCD90320. We have to use procedure 2 to enable the reset count feature on UCD90160A and UCD90320.

Why is there a difference?


Procedure 1:

  1. echo 1 > rDC
  2. power cycle the card 
  3. reset count incremented as expected

UCD90160A, UCD90320

Procedure 1 does not work, we have to do these steps

Procedure 2

  1. echo 1 > rDC
  2. warm reboot
  3. the reset count rDC still 1 as expected
  4. power cycle card
  5. reset count incremented as expected

Also, is there a way to disable this feature once it's enable?

If yes, can it be reset back to zero?

  • Hi, Thomas,

    To answer your question:

    1. Regarding PMBusAlert: 

       1) Any invalid command that cause the supported status bits (in the below screenshot) to be set, then ALERT# will be asserted. And no, device will not de-assert the ALERT# on its own.

       2) If the fault condition still exist, the ALERT will not be de-asserted on its own unless: either ARA, or CLEAR_FAULT (03h) command is sent. Since there are multiple PMBus devices share the same bus, check if 03h command is sent to other devices.

       3) ALERT# is optional SMBus protocol => I2C commands will not trigger the ALERT#


    2. Regarding RESET_COUNT: the command should be the same for UCD9090A, and UCD90160, as well as UCD90320. Check device brownout feature to see if it is enabled or disabled (below screenshot). If reset_count reach the maximum of 65535, the next reset will cause the count to roll over and reset to zero. Once it is set to zero, RESET_COUNT is disable. So to disable this feature once it is enable, write value = zero to this command.


    Anne Ngo

    Texas Instruments

  • Regarding RESET_COUNT:

    The GUI has additional information regarding how the Reset Count feature should be configured:

    From the GUI there is this "mouse-over" note:

    Allows the user to track how many times the device has been reset.
    On a device that has not been configured, this value will be zero.
    Whenever this value is zero, the number of resets will not be tracked.
    This lowers the number of times that the FLASH is written.
    To use this feature, the value should be changed to one and a STORE_DEFAULT_ALL
    command should be issued. After that, this value will be incremented each
    time the device comes out of reset. ...

    The difference is that this note has the extra step to issue the STORE_DEFAULT_ALL command that is not in the User Manual.

    Is issuing this command the preferred method?

  • Hi

    In order to let the reset count function work, after setting the reset count to a non-zero number. you have to either soft reset the device by command or generate a fault event so that the device can write this non-zero number into the non-volatile memory. it has nothing to do with STORE_DEFULT_ALL.