LTC3882-1
65
Rev A
APPLICATIONS INFORMATION
shaking status bits are in the MFR_COMMON register.
When the part is busy executing an internal operation, it
will clear bit 6 of MFR_COMMON (LTC3882-1 Not BUSY).
When internal calculations are in process, the part will
clear bit 5 of MFR_COMMON (LTC3882-1 Calculations Not
Pending). When the part is busy specifically because it is
ter that supports that function. Clock stretching does not
allow the LTC3882-1 to communicate reliably on busses
operating above 400kHz. Operating the LTC3882-1 with
PMBus SCL rates above 400kHz is not recommended.
System software that detects and properly recovers from
the standard PMBus NACK responses or BUSY faults
described in PMBus Specification V1.2, Part II, Section
10.8.7 is required to communicate above 100kHz without
clock stretching.
Refer to Application Note 135 for techniques that may
also apply to implement a robust PMBus interface to the
LTC3882-1.
Status and Fault Log Management
Due to internal operation, very infrequently the LS byte of
STATUS_WORD may be inconsistent with the state of bits
in the MS byte. This condition is quite transient and can
normally be resolved by simply re-reading STATUS_WORD.
If power is lost during an internal store of a fault log to
EEPROM, a partial write of the log can result. In this situ-
ation, the LTC3882-1 will not indicate that a fault log is
present the next time adequate supply voltage is applied
(bit 3 of STATUS_MFR_SPECIFIC). The existence of a
partial fault log can be detected by examining the header
of the log (MFR_FAULT_LOG). If the first two words of
the Fault Log Preface contain valid data as specified by
Table 2, and STATUS_MFR_SPECIFIC does not indicate the
presence of a complete fault log, then a partial log existed
in EEPROM at boot and has been retrieved to RAM. The
only way to then determine how much of the log is actually
valid is by subjective evaluation of the contents of each log
event record. MFR_FAULT_LOG_CLEAR will permanently
erase a partial fault log, allowing a subsequent log to be
written. It is a good practice to always check for a partial
fault log at power-up if fault logging is enabled (bit 7 of
MFR_CONFIG_ALL_LTC3882-1).
LTpowerPlay – An Interactive Digital Power GUI
LTpowerPlay is a powerful Windows-based development
environment that supports Linear Technology Power Sys-
tem Management ICs, including the LTC3882-1. LTpower-
Play can be used to evaluate LTC products by connecting
to a Linear Technology demo circuit or user application.
Figure 46. Example of a Polling Loop to Write VOUT_COMMAND
// wait until bits 6, 5, and 4 of MFR_COMMON are all set
do
{
mfrCommonValue = PMBUS_READ_BYTE(0xEF);
partReady = (mfrCommonValue & 0x68) == 0x68;
}while(!partReady)
// now the part is ready to receive the next command
PMBUS_WRITE_WORD(0x21, 0x2000); //write VOUT_COMMAND to 2V
transitioning V
OUT
(margining, off/on, moving to a new
VOUT_COMMAND, etc.) it will clear bit 4 of MFR_COM-
MON (LTC3882-1 Output Not In Transition). These three
status bits can be polled with a PMBus read byte of the
MFR_COMMON register until all three bits are set. A com-
mand immediately following all these status bits being set
will be accepted without a NACK, BUSY fault or ALERT
notification. The part can NACK commands for other
reasons, however, as required by the PMBus specifica-
tion (e.g., an invalid command or data). An example of a
robust command write algorithm for the VOUT_COMMAND
register is provided in Figure 46.
It is recommended that all command writes be preceded
with such a polling loop to avoid the extra complexity of
dealing with busy behavior or unwanted ALERT notifica-
tions. A simple way to achieve this is to embed the polling
in subroutines to write command bytes and words. This
polling mechanism will allow system software to remain
clean and simple while robustly communicating with the
part. For a detailed discussion of these topics and other
special cases please refer to the application note section
located at www.linear.com/designtools/app_notes.
When communicating using bus speeds at or below
100kHz, the polling mechanism previously shown pro-
vides a simple solution that ensures robust communica-
tion without clock stretching. At bus speeds in excess
of 100kHz, it is strongly recommended that the part be
enabled to use clock stretching, requiring a PMBus mas-
