XMC4000 Microcontroller Series for Industrial Applications
Power Management Bus (PMBus) Slave Device with XMC4000
Application Guide V1.0 2013-08
Microcontrollers
Edition 2013-08 Published by Infineon Technologies AG, 81726 Munich, Germany. © 2013 Infineon Technologies AG All Rights Reserved.
LEGAL DISCLAIMER THE INFORMATION GIVEN IN THIS APPLICATION NOTE IS GIVEN AS A HINT FOR THE IMPLEMENTATION OF THE INFINEON TECHNOLOGIES COMPONENT ONLY AND SHALL NOT BE REGARDED AS ANY DESCRIPTION OR WARRANTY OF A CERTAIN FUNCTIONALITY, CONDITION OR QUALITY OF THE INFINEON TECHNOLOGIES COMPONENT. THE RECIPIENT OF THIS APPLICATION NOTE MUST VERIFY ANY FUNCTION DESCRIBED HEREIN IN THE REAL APPLICATION. INFINEON TECHNOLOGIES HEREBY DISCLAIMS ANY AND ALL WARRANTIES AND LIABILITIES OF ANY KIND (INCLUDING WITHOUT LIMITATION WARRANTIES OF NON-INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS OF ANY THIRD PARTY) WITH RESPECT TO ANY AND ALL INFORMATION GIVEN IN THIS APPLICATION NOTE. Information For further information on technology, delivery terms and conditions and prices, please contact the nearest Infineon Technologies Office (www.infineon.com). Warnings Due to technical requirements, components may contain dangerous substances. For information on the types in question, please contact the nearest Infineon Technologies Office. Infineon Technologies components may be used in life-support devices or systems only with the express written approval of Infineon Technologies, if a failure of such components can reasonably be expected to cause the failure of that life-support device or system or to affect the safety or effectiveness of that device or system. Life support devices or systems are intended to be implanted in the human body or to support and/or maintain and sustain and/or protect human life. If they fail, it is reasonable to assume that the health of the user or other persons may be endangered. Power Management Bus (PMBus) Slave Device with XMC4000
Trademarks of Infineon Technologies AG AURIX™, C166™, CanPAK™, CIPOS™, CIPURSE™, EconoPACK™, CoolMOS™, CoolSET™, CORECONTROL™, CROSSAVE™, DAVE™, DI-POL™, EasyPIM™, EconoBRIDGE™, EconoDUAL™, EconoPIM™, EconoPACK™, EiceDRIVER™, eupec™, FCOS™, HITFET™, HybridPACK™, I²RF™, ISOFACE™, IsoPACK™, MIPAQ™, ModSTACK™, my-d™, NovalithIC™, OptiMOS™, ORIGA™, POWERCODE™; PRIMARION™, PrimePACK™, PrimeSTACK™, PRO-SIL™, PROFET™, RASIC™, ReverSave™, SatRIC™, SIEGET™, SINDRION™, SIPMOS™, SmartLEWIS™, SOLID FLASH™, TEMPFET™, thinQ!™, TRENCHSTOP™, TriCore™. Other Trademarks Advance Design System™ (ADS) of Agilent Technologies, AMBA™, ARM™, MULTI-ICE™, KEIL™, PRIMECELL™, REALVIEW™, THUMB™, µVision™ of ARM Limited, UK. AUTOSAR™ is licensed by AUTOSAR development partnership. Bluetooth™ of Bluetooth SIG Inc. CAT-iq™ of DECT Forum. COLOSSUS™, FirstGPS™ of Trimble Navigation Ltd. EMV™ of EMVCo, LLC (Visa Holdings Inc.). EPCOS™ of Epcos AG. FLEXGO™ of Microsoft Corporation. FlexRay™ is licensed by FlexRay Consortium. HYPERTERMINAL™ of Hilgraeve Incorporated. IEC™ of Commission Electrotechnique Internationale. IrDA™ of Infrared Data Association Corporation. ISO™ of INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. MATLAB™ of MathWorks, Inc. MAXIM™ of Maxim Integrated Products, Inc. MICROTEC™, NUCLEUS™ of Mentor Graphics Corporation. MIPI™ of MIPI Alliance, Inc. MIPS™ of MIPS Technologies, Inc., USA. muRata™ of MURATA MANUFACTURING CO., MICROWAVE OFFICE™ (MWO) of Applied Wave Research Inc., OmniVision™ of OmniVision Technologies, Inc. Openwave™ Openwave Systems Inc. RED HAT™ Red Hat, Inc. RFMD™ RF Micro Devices, Inc. SIRIUS™ of Sirius Satellite Radio Inc. SOLARIS™ of Sun Microsystems, Inc. SPANSION™ of Spansion LLC Ltd. Symbian™ of Symbian Software Limited. TAIYO YUDEN™ of Taiyo Yuden Co. TEAKLITE™ of CEVA, Inc. TEKTRONIX™ of Tektronix Inc. TOKO™ of TOKO KABUSHIKI KAISHA TA. UNIX™ of X/Open Company Limited. VERILOG™, PALLADIUM™ of Cadence Design Systems, Inc. VLYNQ™ of Texas Instruments Incorporated. VXWORKS™, WIND RIVER™ of WIND RIVER SYSTEMS, INC. ZETEX™ of Diodes Zetex Limited. Last Trademarks Update 2011-11-11
Application Guide 3 V1.0, 2013-08
Power Management Bus (PMBus) Slave Device with XMC4000
Revision History Major changes since previous revision Date Version Changed By Change Description
We Listen to Your Comments Is there any information in this document that you feel is wrong, unclear or missing? Your feedback will help us to continuously improve the quality of our documentation. Please send your proposal (including a reference to this document title/number) to: [email protected]
Application Guide 4 V1.0, 2013-08
Power Management Bus (PMBus) Slave Device with XMC4000
Table of Contents
Revision History ...... 4 Table of Contents ...... 5 1 Overview ...... 6 1.1 System Overview ...... 6 1.2 PMBus Features...... 7 1.3 PMBus Protocols ...... 7 1.3.1 Send Byte ...... 8 1.3.2 Write Byte ...... 8 1.3.3 Write Word ...... 9 1.3.4 Read Byte ...... 9 1.3.5 Read Word ...... 10 1.3.6 Host Notify ...... 10 1.4 PMBus Commands and Data Formats ...... 11 2 Implementation of PMBus Slave on XMC4500 ...... 12 2.1 Hardware ...... 13 2.2 Software ...... 14 2.2.1 Software Flow ...... 15 2.2.2 Software API Functions ...... 16 2.2.2.1 PMBus Protocol Layer Interface API Functions ...... 16 2 2.2.2.2 I C Transport Layer Interface API Functions ...... 16 2.2.2.3 Data Storage API Functions ...... 17 2.2.2.4 Interrupt Handlers...... 17 2.2.3 Packet Error Checking (PEC) ...... 17 2.2.4 Fault Reporting Mechanism ...... 17 2.3 Implementation Consideration ...... 18 2.3.1 How to modify a response for a command ...... 18 2.3.2 How to add a command ...... 19 3 Application Example ...... 20 3.1 Getting Started ...... 20 3.1.1 Hardware Setup ...... 20 3.2 XMC4500 PMBus Software Package for Slave Device ...... 22 4 Conclusion ...... 23 5 References ...... 24
Application Guide 5 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Overview
1 Overview
The Power Management Bus (PMBus™) is a free and open standard power-management protocol with a fully defined command language that facilitates communication with power converters and other devices in a power system. It is a variant of System Management Bus (SMBus), and is a relatively slow speed, two-wire communications protocol based on the Inter-Integrated Circuit Bus (I²C). The PMBus standard defines over two hundred commands, and a substantial number of the commands are specifically for power conversion processes.. This application guide gives details of the PMBus standard and describes the implementation of the protocol on the Slave Device using the Infineon XMC4500 microcontroller. The XMC4500 microcontroller belongs to the XMC4000 industrial family based on the ARM Cortex-M4 processor core. The Universal Serial Interface Channel module (USIC) contained in the microcontroller is a flexible interface module covering several serial communication protocols including the Inter-Integrated Circuit (I²C).
1.1 System Overview
PMBus consists of a single host and multiple devices. It is a two-line communication protocol based on I²C. There are two optional lines, SMBALERT and CONTROL line.
Figure 1 PMBus communication architecture
Note: The SMBALERT# and CONTROL signals are optional to the operation of PMBus system. The PMBus 2 system can function with the two serial bus lines (I C).
Application Guide 6 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Overview
2 I C Serial Bus line 2 The Serial Bus Data and Serial Bus Clock line perform I C functions. These two are essential lines for the PMBus functionality.
SMBALERT# Signal The SMBALERT signal line is a an interrupt line for slave-only devices to notify the Host. The Slave can signal the Host through the SMBALERT line when a fault occurs and has to be reported. The Host will process the interrupt and access all the SMBALERT# devices using Alert Response Address and the devices that assert the signal will respond to the alert response address.
CONTROL Signal The CONTROL signal is an output signal on a PMBus Host. It can use this signal in conjunction with commands via the serial bus to turn the Slave Device on or off.
1.2 PMBus Features
The following features are recommended to improve the communication and data reliability, to create a robust PMBus system.
Timeout Mechanism The PMBus system adopts a timeout mechanism to resume the functionality if fault conditions happen. If the clock line is held low longer than a certain time, the device must reset the communication to resume normal functionality.
Fault Reporting The Slave Device is required to report the fault conditions to the Host during operation. The report can be via; the SMBALERT# signal using the host-notify protocol (section 1.3.6).
Packet Error Checking (PEC) An optional Packet Error Checking (PEC) feature is recommended, in order to significantly increase the data reliability. PEC checks the reliability of the received data packets via a cyclic redundancy check-8 (CRC-8) algorithm.
1.3 PMBus Protocols
In the XMC4500 implementation, the following types of PMBus command packet structures are supported: Send Byte Write Byte Write Word Read Byte Read Word Host Notify
Application Guide 7 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Overview
1.3.1 Send Byte
This is used by the Host (the PMBus master) to send a command to the Slave Device to perform simple tasks that do not require any data bytes. For example, the CLEAR_FAULTS command is used to clear all the fault flags in the system. The Host starts the communication by generating a start condition(S); write a 7 bit slave address with a write bit, followed by the 8 bit command. The Slave will acknowledge each byte received (shaded portion in the figure). The communication is terminated by a stop condition (P) generated by the Host. The additional PEC byte ensures data reliability.
Figure 2 Send Byte Packet without PEC
Figure 3 Send Byte Packet with PEC
1.3.2 Write Byte
Used by the Host to write a one-byte value to certain variables in Slave Device settings. For example, VOUT_MODE command can be used to change the voltage representation by writing a new variable value.
Figure 4 Write Byte Packet without PEC
Figure 5 Write Byte Packet with PEC
Application Guide 8 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Overview
1.3.3 Write Word
Used to write one word (2 bytes) of information into the Slave Device variable.
Figure 6 Write Word Packet without PEC
Figure 7 Write Word Packet with PEC
1.3.4 Read Byte
This is used by the Host to read one byte of information from the Slave Device. For example, the STATUS_BYTE command enables the Host to read the error status of the Slave Device. As shown in the figure, after the acknowledgement for command code from the Slave, the Host sends a repeated start (Sr) condition, followed by the 7-bit address with a read bit. The Slave will then acknowledge and send out one byte data.
Figure 8 Read Byte Packet without PEC
Figure 9 Read Byte Packet with PEC
Application Guide 9 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Overview
1.3.5 Read Word
Used for the Host to read one word of data from the PMBus Slave Device. For example, the READ_TEMPERATURE_1 command is used to read the temperature of the Slave Device.
Figure 10 Read Word Packet without PEC
Figure 11 Read Word Packet with PEC
1.3.6 Host Notify
When fault condition occurs in the Slave, the Slave needs to report the error back to the Host. In this case, the Slave Device becomes the bus master and initiates a communication session using the host notify protocol. The Slave Device address and two-byte status information are transmitted to the Host.
Figure 12 Host Notify Protocol
Application Guide 10 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Overview
1.4 PMBus Commands and Data Formats
The PMBus commands are one byte command codes. They consist of output voltage related commands, fault related commands, read status command and parametric write/read commands. With these commands the Host can configure the Slave Device peripherals and read the status. To support the write/read of the parametric data (except for output voltage), data is mainly represented in 2 types of format: LINEAR DIRECT For output voltage and output voltage related parameter, they are represented in three formats: LINEAR scale using 2 bytes unsigned binary integer with a scaling factor. VID codes used by INTEL microprocessor. DIRECT format that uses an equation and the supplied coefficients. Each Slave Device is required to support one type of data format for each command supported. Not all the commands are required to be supported by PMBus systems, the command supported list should be determined according to application needs.
Application Guide 11 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Implementation of PMBus Slave on XMC4500
2 Implementation of PMBus Slave on XMC4500
Implementation focuses on the robust communication functionality. Table 1 is a list of implemented commands that are important to PMBus functionality.
Table 1 Commands Supported in the Slave Device
Cmd Command Commands Name Data Format Description Code Packet Turn the Slave Device on/off R/W Specification defined 01h OPERATION with control signal, and set the data format Byte output voltage to margins. Send Clear any fault bits set in the 03h CLEAR_FAULTS No, write only Byte status registers. Copy the entire contents of the Send operating memory to the 11h STORE_DEFAULT_ALL No, write only Byte matching locations in the non- volatile Default Store memory. Copy the entire contents of the Send non-volatile Default Store 12h RESTORE_DEFAULT_ALL No, write only memory to the matching Byte locations in the operating memory.
Read Specification defined For Host system to determine 19h CAPABILITY some key capabilities of a Byte data format* PMBus Slave device. R/W Specification defined Set or read the format of the 20h VOUT_MODE Byte data format* output voltage data. LINEAR R/W Set the Slave Device output 21h VOUT_COMMAND (output voltage Word voltage. related)
R/W Specification defined Configure up to two fans 3Ah FAN_CONFIG_1_2 associated with one PMBus Byte data format* Slave Device. R/W 3Bh FAN_COMMAND_1 LINEAR Adjust the operation of the fan. Word Set the VIN overvoltage value R/W The VIN overvoltage fault is 55h VIN_OV_FAULT_LIMIT LINEAR Word reported if the input voltage is above this value. Instruct the Slave on the action VIN_OV_FAULT_RESPONS R/W Specification defined 56h to take in response to an input E Byte data format* overvoltage fault. R/W Set the VIN under voltage value 58h VIN_UV_WARN_LIMIT LINEAR Word warning limit. Instruct the device on what VIN_UV_FAULT_RESPONS R/W Specification defined 5Ah action to take in response to an E Byte data format* input under voltage fault.
Application Guide 12 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Implementation of PMBus Slave on XMC4500
Cmd Command Commands Name Data Format Description Code Packet Slave Device to return one byte R/W Specification defined 78h STATUS_BYTE of information with a summary of data format* Byte the most critical faults. Slave Device to return two bytes R/W Specification defined of information with a summary of 79h STATUS_WORD Word data format* the Slave Device’s fault condition. Slave Device to return one byte R/W Specification defined 7Ch STATUS_INPUT of information with input related data format* Byte faults. Slave Device to return one byte R/W Specification defined of information with 7Eh STATUS_CML Byte data format* communication, logic and memory related faults. Slave Device to report on the R/W Specification defined 81h STATUS_FAN_1_2 status of any fans installed in data format* Byte position 1 or position 2. Read Slave Device to return the input 88h READ_VIN LINEAR Word voltage. Slave Device to return the Read LINEAR (output 8Bh READ_VOUT actual, measured (not voltage related) Word commanded) output voltage.
Read Slave Device to return the 8Dh READ_TEMPERATURE_1 LINEAR measured temperature in degree Word Celsius. *Please refer to the PMBus Power System Management Protocol Specification, Part II, for the detailed data format defined. In this solution; The CONTROL line and the SMALERT# signal are not implemented The linear data format is used Linear 11 data format is used for general parameters Linear 16 data format is used for output voltage related parameters The data format should be chosen according to the application requirements. The functions for direct data format conversion are implemented as API functions. The user can call these functions to convert the data to/from direct format. A Packet error checking function is supported. This is enabled or disabled in the configuration file, config.h.
2.1 Hardware
2 2 The PMBus is operated with the I C clock and the I C data lines. The CPU board used is the XMC4500 General Purpose Hexagon board, CPU_45A-V2. The XMC4500 has the USIC module which can support I2C communication.
Application Guide 13 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Implementation of PMBus Slave on XMC4500
2 Table 2 Possible I C Clock/Data hardware pin assignments in XMC4500
Clock SCL Data SDA P0.8 P1.5 P0.11 P0.5 / P2.14 P1.1 P1.5 P2.4 P2.5 / P3.13 P3.0 P2.5 / P3.13 P5.8 P0.5 / P2.14 P6.2 P2.5 / P3.13 In this example; P5.8 is used for I2C SCL P2.14 is used for the I2C Data
2.2 Software
Here we describe the layers of functions in the software stack.
Figure 13 Software Layers
I2C Transport Layer TM Implemented using the existing DAVE Apps. Functions: writes the value into the transmit buffer reads the value from the receive buffer
Application Guide 14 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Implementation of PMBus Slave on XMC4500
PMBus Protocol Layer This layer configures the different protocols used by the PMBus commands. It configures the content and the sequence of the data for the communication, and performs the communication fault check.
Application Layer Here users can issue the command and configure the command data return. For example, to read the input voltage of the Slave Device, the user can issue the command READ_VIN in xSPY. This command is sent to the Host system: The application layer of the Host system translates the command into PMBus protocol. 2 The protocol is translated into I C communication in the PMBus protocol layer. 2 The command is transmitted to the PMBus Slave Device through the I C transport layer. On the Slave side, after receiving the command code from the Host: The command code is translated to PMBus protocols. In this example, input voltage information is required and the application layer will obtain the information in the system and pass the information to the PMBus protocol layer. 2 The PMBus protocol layer configures the information into appropriate forms and passes it to the I C transport layer.
2.2.1 Software Flow
Figure 14 PMBus Slave device, general software flow
Unlike the PMBus Host, the PMBus Slave is a passive device. It does not know when the Host will issue a command, and cannot predict how the Host will behave. Therefore the operation depends on interrupt events. The crucial interrupt events for the operation of the slave device are: receive repeated start stop The receive event of the command data starts the Slave operation.
Application Guide 15 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Implementation of PMBus Slave on XMC4500
The command received from the Host is decoded into protocols. The system will then go in to a wait state to wait for repeated start or stop conditions according to the protocol, read or write: For write protocols, the Slave device only needs to receive the data from the Host (i.e. it does not need to communicate back to the Host). Therefore the data is processed after the stop condition is received. For read protocols, the Slave device needs to receive bytes from Host but also needs to communicate back to the Host. Processing for the read protocol starts after the repeated start condition is received, which signals the start of the read operation. After sending the required information to the Host, the Slave device will wait for the Stop condition, which signals the end of communication session.
2.2.2 Software API Functions
2.2.2.1 PMBus Protocol Layer Interface API Functions The functions defined in PMBUS001_DEVICE.c are for the PMBus protocol layer.
Table 3 PMBus Protocol Layer Interface API
API Functions Name Description void PMBusDevice(void) Main function of PMBus device void PMBusDevice_Init(void) Initialization function for PMBus device before start operation
2.2.2.2 I2C Transport Layer Interface API Functions
2 Two API functions are required to link the PMBus Protocol layer to the I C transport layer. 2 TM The I C transport layer is covered by the DAVE App I2C001.
2 Table 4 I C Transport Layer Interface API
API Functions Name Description Input Parameter void IICSlaveTransmit(*data, Configures the data for writing in to *data: address pointer to the data SendCount) the USIC FIFO that is to be transmitted SendCount: number of data bytes to be transmitted void IICWriteData(*data) Writes out a Word to the USIC FIFO *data: address pointer to the data transmit buffer register without waiting for any previous data to be transmitted.
Application Guide 16 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Implementation of PMBus Slave on XMC4500
2.2.2.3 Data Storage API Functions
These API functions are used to store/retrieve PMBus data in the serial flash when memory access related commands are received; For example, STORE_DEFAULT_ALL and RESTORE_DEFAULT_ALL commands. The functions are defined in the MEMORYACCESS.c file. If different flash memory is used to store the data, users will have to write their own functions to execute the memory access commands.
Table 5 Data Storage API
API Functions Name Description Return Value void CmdRestoreDefaultAll(void) Restore all PMBus parameters from Flash None memory. void CmdStoreDefaultAll(void) Store all PMBus parameters to Flash None memory Result EraseSector(void) Erase the first sector of the SPI Serial Result = 1: Success Flash. Result = 2: Erase Failed Result ProgramPage(void) Program 256 bytes of data to the first Result = 1: Success sector of the SPI Serial Flash Result = 2: Program Failed
2.2.2.4 Interrupt Handlers The table lists the interrupt handlers used by the PMBus Slave device.
Table 6 Interrupt Handlers API
Handler Name Description Device_R_Start_stop_Handler() Interrupt handler for protocol specific interrupt generated by device I2C system. The event defined is repeated start condition, stop condition and slave read request event detected. Device_Receive_Data_Handler() Interrupt handler for FIFO standard receive buffer interrupt generated by device USIC module FIFO system. The event defined is that data is received from host system. Device_Transmit_Data_Handler() Interrupt handler for transmit shift interrupt generated by device USIC module. The event defined is that data is transmitted out.
2.2.3 Packet Error Checking (PEC)
The PEC byte is used to ensure the data reliability of the communication. It is calculated with all the data byte in the communication, including the Slave address and the read/write bit. The PEC uses an 8-bit cyclic 8 2 redundancy check (CRC-8). The polynomial used is C(x) = x + x + x + 1.
2.2.4 Fault Reporting Mechanism
When faults happen in the system, besides the default handling of the situation of the Slave, it will also use a fault reporting mechanism to notify the Host. Reporting is via either: SMBALERT Host notify protocol
Application Guide 17 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Implementation of PMBus Slave on XMC4500
SMBALERT requires an additional signal line connection between the Host and Slave Devices. In addition the Host will need to send read status command with Alert Response Address to determine which Slave Device pulled the alert line and the type of fault that has occurred. Host notify protocol is used to save on hardware connection, and also to ease reporting procedures.
2.3 Implementation Consideration
When customizing the software stack for the dedicated application, the user must decide on the appropriate adaptation to the code: Based on the capability of the device on packet error checking, the value of PEC defined in CONFIG.h must be changed accordingly: − PEC = 0 will compile and build the project without packet error checking functionality. − PEC = 1 will enable the function of packet error checking. The suported PMBus commands are defined in the PMBUS001_DEVICE.h file. Users can choose the relevant commands according to their application needs to form their own command set. The actions performed in response to the commands (as described in the PMBus Specification) are not fully implemented. Users need to alter the code according to their specific application. Users must provide the correct data to send to the Host when requested and take appropriate actions in response to commands. If new commands are required, the users will need to add the definition of the new commands to the PMBUS001_DEVICE.h file. An update on the command list (PMBusCommand[]) in PMBUS001_DEVICE.c file is also required. The Slave address can be changed in CONFIG.h, in the defined value SlaveAddress. Note that the Slave address is expressed in 7 bits.
2.3.1 How to modify a response for a command
All the commands defined in the system are editable. Users can add or change the actions according to their application needs. If changes are needed, use the following steps: 1. Find the bus protocol of the command that needs to be edited. 2. Go to the PMBusDevice() function in the PMBUS001_DEVICE.c file. Find the marked space for user code to be inserted. 3. Go to the space of the respective bus protocol (SendByte, WriteByte, etc) and the PMBus commands are there in the form of switch cases. The actions to be defined can be put inside the command switch case. If the command does not exist, a new switch case has to be added. switch(mode) { Case SendByte: … // USER CODE for SendByte case BEGIN … // USER CODE for SendByte case END Break; …
}
Application Guide 18 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Implementation of PMBus Slave on XMC4500
2.3.2 How to add a command
It is possible to add other commands defined in the specification, but the response of the Slave device then needs to be programmed by the user. 1. Find the number of the required command and determine the bus protocol of the new command. 2. Go to the PMBUS001_DEVICE.h file and add in the command definition for the new command 3. Go to the PMBUS001_DEVICE.c file and add the command number to the array PMBusCommand[], according to the bus protocol. 4. Go to the function Device_CommandProtocolIdentify(), change ‘x’ in the compare check ‘CmdIndex < x’ to the correct value. 5. Go to the function PMBusDevice() in the PMBUS001_DEVICE.c file, and add a new switch case inside the user code space. This defines the response of the device to the command.
Application Guide 19 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Application example
3 Application example
Our example project uses potentiometer values to simulate input voltage values. The input voltage is set by varying the potentiometer. If the input voltage exceeds the over-voltage limit, or falls below the under-voltage limit, there will be an error condition and the Slave device will notify the Host via the host notify protocol.
3.1 Getting started
The example project provided is a simple PMBus system with one Host and one Slave device.
Figure 15 PMBus hardware connection
3.1.1 Hardware setup
Slave Hardware required 1. XMC4500 Hexagon CPU General Purpose Board, CPU_45A-V2 2. Pin Extension Board, UNI_EXT01-V2 3. J-Link Lite Debugger
Master Hardware required 1. XMC4400 Hexagon CPU General Purpose Board, CPU_44A-V2 2. Pin Extension Board, UNI_EXT01-V2
Application Guide 20 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Application example
Figure 16 Slave Board – XMC4500 Connection Guide
The hardware setup for the PMBus Slave Device: 1. Connect a 5V power to the XMC4500 board. 2. Connect the J-link debugger to the XMC4500 board to download the PMBus Slave code. 3. Remove the J-link debugger. 4. Connect to the PMBus using the pin extension board on the COM side. There are two signal lines: SCL (clock) and SDA (data).
Figure 17 Master Board – XMC4400 Connection Guide
Application Guide 21 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Application example
The hardware setup for the PMBus Host (Master): 1. Connect a 5V power to the XMC4400 board. 2. Connect a mini USB cable to the XMC4400 board to download the PMBus Host code. The same connection is used for xSPY communication to the laptop. 3. Connect to the PMBus using the pin extension board on the COM side. There are two signal lines: SCL (clock) and SDA (data).
Note: Ensure that there is a common ground between the Host and Slave Device for this setup.
3.2 XMC4500 PMBus Software Package for Slave Device
TM Table 7 List of DAVE Apps used
Apps Version Description ADC002 1.0.12 Configure an ADC kernel for the VIN measurement CLK001 1.0.32 Configure the system and peripheral clocks TM DAVESupport 1.0.32 DAVE Apps initialization and configure the multiplexer registers 2 I2C001 1.0.22 Configure one of the USIC channels as I C NVIC002 1.0.16 Interrupt handler apps PWMSP001 1.0.24 Use as a timer to trigger ADC conversion RESET001 1.0.10 Provides API to assert/de-assert peripheral modules SPI001 1.0.16 Configure one of the USIC channels as SPI. This is used to communicate with the Serial Flash memory.
TM Table 8 List of source files (excluding DAVE generated files)
Filename Description Main.c The main tasks of this example project. MEMORYACCESS.c Functions that handle the PMBus memory access commands and trigger memory read, program or erase the PMBus parameter in the Serial Flash memory. PMBUS001_DEVICE.c PMBus protocol layer functions implementation. PMBUS001_GENERAL.c Functions related to data conversions and packet error checking. S25FL032P.c Handles the commands required to communicate to the Serial Flash memory CONFIG.h Configuration of the supported features. MEMORYACCESS.h Function declarations that are defined in MEMORYACCESS.c. PMBUS001_DEVICE.h PMBus command definitions and the PMBus protocol layer function declarations. PMBUS001_GENERAL.h Function declarations that are defined in PMBUS001_GENERAL.c. S25FL032P.h Function declarations that are defined in S25FL032P.c
Application Guide 22 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
Conclusion
4 Conclusion
Today we see a shift towards digital based solutions in power conversion technology and this requires a communication capability in the power system. The PMBus facilitates communication with power converters and other devices in the power system and therefore addresses this need. The XMC4000 microcontroller provides the PMBus protocol with its powerful USIC module, and the PMBus protocol software has been developed in accordance with the PMBus Standard. From the application example given, users are able to customize and configure the PMBus protocol software to their own power system.
Application Guide 23 V1.0, 2013-08 Power Management Bus (PMBus) Slave Device with XMC4000
References
5 References
[1] XMC4500 Reference Manual, version 1.2, December 2012 [2] PMBus Power System Management Protocol Specification, revision 1.2, September 2010
[3] Power Management Bus Implementer’s Forum, PMBus™: The Power System Standard
[4] System Management Interface Forum, System Management Interface Forum (SMIF)
Application Guide 24 V1.0, 2013-08
www.infineon.com
Published by Infineon Technologies AG