MSP PMBus Library Users Guide
v1.00.00.00
|
The PMBus standard was developed by a group of companies that envisioned the need for a power-management protocol that has a well-defined physical communication layer and includes support for implementing commonly used power-management commands. I2C was considered the preferred standard for implementing the physical communication layer because it provided a simple means to relay data representing commands, control, and information over a serial bus.[4] In addition to the data and clock lines provided by I2C, the PMBus protocol implements the optional alert response (for host notification in the presence of a fault) and control line (for turning the slave device on/off). The PMBus command layer provides a set of 256 commands that the host microcontroller can use to instruct slave PMBus devices.
The PMBus protocol also implements a timeout feature (present in SMBus) that prevents slower slave devices from holding the clock line for longer than the specified timeout interval. This limits the minimum allowable frequency of I2C transactions to 10 kHz, similar to SMBus but absent in I2C. For further differences in timing and DC specifications between the protocols, see System Management Bus (SMBus) Specification V2.0.[2] A new feature that increases reliability and robustness of this protocol is Packet Error Checking (PEC). PEC was first introduced in version 1.1 of the SMBus protocol and is implemented by using a Cyclic Redundancy Check-8 (CRC-8) algorithm to validate the integrity of a transaction.
It should be noted that PMBus can function as a 2-wire protocol. The data and clock lines are retained from the I2C protocol for transmitting/receiving data and for controlling the clocking of data respectively. The alert response and control signals are optional implementations/enhancements for host microcontrollers that are willing to trade two GPIO pins for the ability to service a system fault and to turn the slave device on or off using software.
The figure below shows the architecture of the PMBus host microcontroller's communication model. The application layer is at the user-interaction level and also can be viewed as a data translation/interpretation layer. It performs application services and issues requests to the PMBus layer. The PMBus layer accepts commands from the application layer. It processes these commands and passes them to the SMBus layer which implements the SMBus communication state machine and instructs the hardware access (I2C) layer on how to execute the commands. The I2C layer, in conjunction with the alert response and control line, provides the physical interface needed for direct communication with the slave device.
The following significant features uniquely identify the PMBus protocol and establish its position as a valuable part of any power-management system.
The SMBALERT line is used by slave devices to notify the master in the presence of a system fault. This line is a wired-AND signal and is tied high at reset similar to I2C clock and data lines. The slave device can pull it low at any time to notify the host microcontroller that it needs to communicate. When the master PMBus device receives an alert from the slave, the master can be configured to read the status registers of the slave device to determine the type and location of the fault. Once the fault has been read and recorded, the slave device can be notified and its status registers reinitialized. In systems that have multiple slaves tied to the bus, the master uses the Alert Response Address (ARA) to determine which slave pulled the alert line low. If multiple slaves are asserting the alert simultaneously, the slave with the lowest address wins. This application report, however, deals with alert response implementation for single slave only; for multi-slave implementation with the alert response, see System Management Bus (SMBus) Specification V2.0.[2]
On/off control of the slave device is achieved by using the control line in combination with commands on the bus. The control line is configured as active high or active low based on the ON_OFF_CONFIG command. The OPERATION command can then be used to turn the slave device on/off through software.
PEC is optionally implemented in PMBus devices but is highly recommended due to the critical nature of data validity in power-management systems. Packet Error Code (also PEC) bytes are generated using the popular CRC-8 algorithm that is based on performing XOR operations on the input bit stream with a fixed CRC polynomial. The PEC byte is calculated on all bytes in the I2C transaction including device address and read/write. PEC does not include start, stop, ACK/NACK, and repeated start bits.
PMBus defines a set of standard commands for interacting with power management devices. Each command has a defined command code and protocol format. The protocol formats are standard SMBus command protocol formats and the specific protocols for each PMBus command are defined in the Appendix of the PMBus specification[3].
PMBus allows for device specific commands. The SMBus protocol for device specific commands are specified by the device manufacturer.
See the SMBus specification[2] for definition of the command protocols.