EVAL-ADM1275EBZ Datasheet, PDF (34/48 Pages) Analog Devices – Hot-Swap Controller and Digital Power

ADM1275
ADM1275 ALERT PIN BEHAVIOR
The ADM1275 provides a very flexible alert system, whereby
one or more fault/warning conditions can be indicated to an
external device.
FAULTS AND WARNINGS
A PMBus fault on the ADM1275 is always generated due to an
analog event and causes a change in state in the hot-swap output,
turning it off. The three defined fault sources are as follows:
• Undervoltage (UV) event detected on the UV pin
• Overvoltage (OV) event detected on the OV pin
• Overcurrent (OC) event that causes a hot-swap timeout
Faults are continuously monitored, and, as long as power is
applied to the device, they cannot be disabled. When a fault
occurs, a corresponding status bit is set in one or more
STATUS_xxx registers.
A value of 1 in a status register bit field always indicates a fault
or warning condition. Fault and warning bits in the status
registers are latched when set to 1. To clear a latched bit to 0—
provided that the fault condition is no longer active—use the
CLEAR_FAULTS command or use the OPERATION command
to turn the hot-swap output off and then on again.
A warning is less severe than a fault and never causes a change
in the state of the hot-swap controller. The eight sources of a
warning are defined as follows:
• CML: a communications error occurred on the I²C bus
• HS timer was active (HSTA): the current regulation was
active, but does not necessarily shut the system down
• IOUT OC warning from the ADC
• IOUT Warning 2 from the ADC
• VIN UV warning from the ADC
• VIN OV warning from the ADC
• VOUT UV warning from the ADC (ADM1275-1 and
ADM1275-3 only)
• VOUT OV warning from the ADC (ADM1275-1 and
ADM1275-3 only)
GENERATING AN ALERT
A host device can periodically poll the ADM1275 using the
status commands to determine whether a fault/warning is
active. However, this polling is very inefficient in terms of
software and processor resources. The ADM1275 has
GPOx/ALERTx output pins that can be used to generate
interrupts to a host processor.
• ADM1275-1: GPO1/ALERT1/CONV and GPO2/ALERT2
• ADM1275-2: GPO1/ALERT1/CONV
• ADM1275-3: GPO2/ALERT2
Data Sheet
By default at power-up, the open-drain GPOx/ALERTx outputs
are high impedance, so the pins can be pulled high through
resistors. No faults or warnings are enabled on the GPO1/
ALERT1/CONV pin at power-up; the user must explicitly enable
the faults or warnings to be monitored. The FET health bad
warning is active by default on the GPO2/ALERT2 pin at
power-up.
Any one or more of the faults and warnings listed in the Faults
and Warnings section can be enabled and cause an alert, making
the corresponding GPOx/ALERTx pin active. By default, the
active state of a GPOx/ALERTx pin is low.
For example, to use GPO1/ALERT1/CONV to monitor the
VOUT UV warning from the ADC, the followings steps must
be performed:
1. Set a threshold level with the VOUT_UV_WARN_LIMIT
command.
2. Start the power monitor sampling on VOUT.
If a VOUT sample is taken that is below the configured
VOUT UV value, the GPO1/ALERT1/CONV pin is taken
low, signaling an interrupt to a processor.
HANDLING/CLEARING AN ALERT
When faults/warnings are configured on the GPOx/ALERTx pins,
the pins become active to signal an interrupt to the processor.
(These pins are active low, unless inversion is enabled.) The
GPOx/ALERTx signal functions as an SMBAlert.
Note that the GPOx/ALERTx pins can become active indepen-
dently of each other, but they are always made inactive together.
A processor can respond to the interrupt in one of two basic ways:
• If there is only one device on the bus, the processor can
simply read the status bytes and issue a CLEAR_FAULTS
command to clear all the status bits, which causes the
deassertion of the GPOx/ALERTx line. If there is a persistent
fault—for example, an undervoltage on the input—the status
bits remain set after the CLEAR_FAULTS command is
executed because the fault has not been removed. However,
the GPOx/ALERTx line is not pulled low unless a new fault/
warning becomes active. If the cause of the SMBAlert is a
power monitor generated warning and the power monitor
is running continuously, the next sample generates a new
SMBAlert after the CLEAR_FAULTS command is issued.
• If there are several devices on the bus, the processor can
issue an SMBus alert response address command to find
out which device asserted the SMBAlert line. The
processor can read the status bytes from that device and
issue a CLEAR_FAULTS command.
Rev. D | Page 34 of 48