MSP PMBus Library Users Guide
v1.00.00.00
|
The MSP430™ PMBus software library is based on PMBus v1.2, but does not support the following features defined in the PMBus v1.2 specification:
The MSP430™ PMBus software library is implemented as a level on top of the MSP430™ SMBus library.
The application consists of the code to initialize the MSP430™ hardware and makes calls to the PMBus functions. The PMBus level process the commands it receives from the application level and makes the required function calls to the SMBus library. The SMBus level interfaces with the I2C peripheral to communicate with the PMBus slave device.
See the examples included with the release package for further details on using the library.
The PMBus level source code is device independent, but the SMBus level interacts with the microcontroller I2C peripheral and is device dependent. The PMBus libraries and examples were developed for the following MSP430™ microcontroller families:
The initialize the PMBus library for use the application must first initialize the I2C peripheral and, if desired GPIO pins for SMBALERT and CONTROL lines. Then the application must call the PMBus_init function before any PMBus commands.
The PMBus library implements PEC as an optional feature. Applications that require PEC must enable this feature by calling the PMBus_enablePEC function before any PMBus commands are sent to the slave device.
Generating the PEC byte involves invoking the CRC-8 algorithm provided in a function. The CRC function performs an XOR operation on the input data stream with the CRC-8 polynomial C(x) = x8 + x2 + x1 + 1. This calculation is done in the order bits are received and also can be considered a brute force polynomial division technique. The algorithm used to calculate the CRC byte is modified from the application report CRC Implementation With the MSP430.[3]
PMBus master devices that implement PEC have either prior knowledge of whether or not the slave supports the feature, or they are expected to determine this by reading information from the slave. The master transmitter generates the PEC byte and inserts it at the end of the transmit data stream. If the PEC byte is not acknowledged by the slave, then the transaction is considered invalid.
If the master is receiving, then it generates the extra clock cycles needed to receive the PEC byte from the slave as the last byte of the transaction. Master receivers can then check the validity of the PEC byte by generating their own PEC and comparing it to the one received from the slave device. PMBus slave devices that implement PEC must be able to respond to master devices with or without PEC support. Slave transmitters must have the capability of generating PEC bytes and inserting them as the final byte of any transaction if requested. Slave receivers must be able to accept the PEC byte, check to see if the byte is valid or not, and respond with an ACK/NACK accordingly.[2]
The PMBus specification defines set of command for interfacing with power management devices. Each command is assigned a one byte command code. Some commands have defined transmit and receive protocols for interfacing with the slave device. There are some command codes whose protocols are left as device specific. The MSP430™ PMBus library supports both types of commands
See the API Guide for detailed documentation of all the PMBus functions.
For all the pre-defined protocol PMBus commands, applications can use the PMBus_cmdRead and PMBus_cmdWrite functions. The PMBus library will translate the passed in command code to the required protocol automatically. Define's for all the standard command codes can be found in the PMBus library header file.
A example usage of the PMBus "VIN_ON" command on a TPS544C20 device might look like:
// Write VIN_ON 4.25 V Command_Buff[0] = 0x11; //LSB Command_Buff[1] = 0xF0; //MSB int8_t ret = PMBus_cmdWrite(0x1B, // TPS544C20 Device Address PMB_VIN_ON, // #define of the VIN_ON 0x35 command code - see pmbus.h Command_Buff, // TX buffer 2, // TX bytes sent 100000); // Software response timeout cycles
The MSP430™ PMBus library provides functions to call the low level SMBus command protocols. These functions enable applications to access the device-specfic PMBus commands. The function names map directly to SMBus protocol names to enable easy mapping from the slave device's PMBus documentation to MSP430™ PMBus function calls.
For example, the PMBus DEVICE_CODE (0xFC) command is manufacturer specific. The TPS544C20 device device defines this command's read transaction to use the SMBus "ReadWord" protocol.
// Verify the ID of the device (0x0153 for TPS544C20 Rev 3) // Note that DEVICE_CODE (0xFC) is manufacturer specific but it's accessed // with Read_Word/Write_Word commands. // So, we call the specific ReadWord function directly uint8_t Resp_Buff[PMB_MAX_PACKET_SIZE + 4]; if ((PMBus_cmdReadWord(TPS544C20_ADDRESS, 0xFC, Resp_Buff, timeout) != PMBUS_RET_OK) || ( Resp_Buff[0] != 0x53) || ( Resp_Buff[1] != 0x01) ) { // Stay in loop if device didn't respond OK while(1) ; }
In the event that a SMBALERT was detected, the PMBus library provides a PMBus_ReceiveByteARA function to enable applications to send the receive byte packet to the alert response address to determine which device triggerd the alert. Support for SMBALERT and ARA is optional, and manufacturer specific. Applications must consult the device documentation for usage details for their PMBus slave device.
An example application showing the usage of SMBALERT and ARA with the TPS544C20 is included in the examples included in the installation package.
Applications may define a CONTROL line to provide on/off control for PMBus devices. An example application showing how to configure a MSP430™ microcontroller GPIO pin as a CONTROL line is included in the examples directory.