Microcontroller Series for Industrial Applications

Transcription

1 XMC4000 Microcontroller Series for Industrial Applications Power Management Bus ( PMBus) Host with XMC4000 Application Guide V Microcontrollers

2 Edition Published by Infineon Technologies AG, Munich, Germany 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 ( 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.

3 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 Application Guide 3 V1.1,

4 Revision History Date Version Change Description July Initial Release March Update Table 3 List of DAVE TM Apps used 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.1,

5 Table of Contents Revision History... 4 Table of Contents Overview System Overview PMBus Features PMBus Protocols Send Byte Write Byte Write Word Read Byte Read Word Host Notify PMBus Commands and Data Formats Implementation of PMBus Host on XMC Hardware Software Software Flow Packet Error Checking (PEC) Fault Reporting Mechanism xspy Setup Examples of sending commands Software Package for PMBus Host Conclusion References Application Guide 5 V1.1,

6 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 Host Device using the Infineon XMC4400 microcontroller. The XMC4400 microcontroller belongs to the XMC4000 industrial family, which is 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 system can function with the two serial bus lines (I 2 C). Application Guide 6 V1.1,

7 Overview I 2 C Serial Bus line The Serial Bus Data and Serial Bus Clock line perform I 2 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. 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 XMC4000 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.1,

8 Overview 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 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.1,

9 Overview 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 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.1,

10 Overview 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 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.1,

11 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.1,

12 Implementation of PMBus Host on XMC Implementation of PMBus Host on XMC4400 Implementation focuses on the robust communication functionality. 0 is a list of implemented commands that are important to PMBus functionality. Commands Supported in the XMC4400 PMBus Host Code Name Packet Data Format Description 01h 03h 11h 12h 19h 20h 21h 3Ah 3Bh 55h 56h 58h 5Ah OPERATION CLEAR_FAULTS STORE_DEFAULT_ALL RESTORE_DEFAULT_ALL CAPABILITY VOUT_MODE VOUT_COMMAND FAN_CONFIG_1_2 FAN_COMMAND_1 VIN_OV_FAULT_LIMIT VIN_OV_FAULT_RESPONSE VIN_UV_WARN_LIMIT VIN_UV_FAULT_RESPONSE R/W Byte Send Byte Send Byte Send Byte Read Byte R/W Byte R/W Word R/W Byte R/W Word R/W Word R/W Byte R/W Word R/W Byte Specification defined data format No, write only No, write only No, write only Specification defined data format* Specification defined data format* LINEAR (output voltage related) Specification defined data format* LINEAR LINEAR Specification defined data format* LINEAR Specification defined data format* Turn the Slave Device on/off with control signal, and set the output voltage to margins. Clear any fault bits set in the status registers. Copy the entire contents of the operating memory to the matching locations in the nonvolatile Default Store memory. Copy the entire contents of the non-volatile Default Store memory to the matching locations in the operating memory. For Host system to determine some key capabilities of a PMBus Slave device. Set or read the format of the output voltage data. Set the Slave Device output voltage. Configure up to two fans associated with one PMBus Slave Device. Set the operation of the fan. Set the VIN overvoltage value The VIN overvoltage fault is reported if the input voltage is above this value. Instruct the Slave on the action to take in response to an input overvoltage fault. Set the VIN under voltage value warning limit. Instruct the Slave on the action to take in response to an input under voltage fault. 78h STATUS_BYTE R/W Specification defined Slave Device to return one byte Application Guide 12 V1.1,

13 Implementation of PMBus Host on XMC4400 Code Name Packet Data Format Description 79h 7Ch 7Eh 81h 88h 8Bh 8Dh STATUS_WORD STATUS_INPUT STATUS_CML STATUS_FAN_1_2 READ_VIN READ_VOUT READ_TEMPERATURE_1 Byte data format* of information with a summary of the most critical faults. R/W Word R/W Byte R/W Byte R/W Byte Read Word Read Word Read Word Specification defined data format* Specification defined data format* Specification defined data format* Specification defined data format* LINEAR LINEAR (output voltage related) LINEAR Slave Device to return two bytes of information with a summary of the Slave Device s fault condition. Slave Device to return one byte of information with input related faults. Slave Device to return one byte of information with communication, logic and memory related faults. Slave Device to report on the status of any fans installed in position 1 or position 2. Slave Device to return the input voltage. Slave Device to return the actual, measured (not commanded) output voltage. Slave Device to return the measured temperature in degree 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. Application Guide 13 V1.1,

14 Implementation of PMBus Host on XMC Hardware The PMBus is operated with the I 2 C clock and the I 2 C data lines. The CPU board used is the XMC4400 General Purpose Hexagon board, CPU_44A-V2. The XMC4400 has the USIC module which can support I 2 C communication. Possible I 2 C Clock/Data hardware pin assignments in XMC4400 Clock SCL Data SDA P0.11 P0.5 / P2.14 P2.4 P2.5 P3.0 P2.5 In this example; P0.11 is used for I 2 C SCL P2.14 is used for the I 2 C Data 2.2 Software Here we describe the layers of functions in the software stack. Figure 13 Software Layers I2C Transport Layer Implemented using the existing DAVE TM Apps. Functions: writes the value into the transmit buffer reads the value from the receive buffer Application Guide 14 V1.1,

15 Implementation of PMBus Host on XMC4400 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. The protocol is translated into I 2 C communication in the PMBus protocol layer. The command is transmitted to the PMBus Slave Device through the I 2 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. The PMBus protocol layer configures the information into appropriate forms and passes it to the I 2 C transport layer Software Flow Figure 14 PMBus Host general software flow Application Guide 15 V1.1,

16 Implementation of PMBus Host on XMC4400 When a user enters a command in the xspy, the system will decode the command into the PMBus protocol. The respective data is written into the I 2 C transmit buffer according to the protocol packet format. If the command is a write action, the system will go back to IDLE because all the actions are finished. If the command is a read action, the system will go into a wait state to wait for the data to be received from the Slave. After the system receives the data and finishes the required actions, the system will go back to IDLE state and wait for other commands Packet Error Checking (PEC) The PEC byte is used to ensure the data reliability of the communication. It is calculated with all the data bytes in the communication, including the Slave address and the read/write bit. The PEC uses an 8-bit cyclic redundancy check (CRC-8). The polynomial used is C(x) = x 8 + x 2 + x 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 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. Application Guide 16 V1.1,

17 Implementation of PMBus Host on XMC xspy xspy is a plug-in for DAVE TM. Together with the DAVE TM App DBG002, it provides a means to modify and read variables on demand from a PC dashboard. xspy allows the user to set the PMBus command and for data to be sent to the Slave Device Setup For the installation of the xspy plug-in, please refer to xspy Getting Started document [5]. Setting the DBG002 App Open the GUI of the DBG002 App. In the UART Configuration tab, set the baud rate to 1MBit/s. In the manual pin assignment, assign the: transmit pin to Port 1.7 receive pin to Port1.5 Code Modification in Main.c Declare the variables for tracing in the Variable Table, AppVarTable[]. DBG002_VariableDescriptionType AppVarTable[20] = { XSPY_ADD_UINT8("xSPYCmdReady", bxspycmdready), XSPY_ADD_UINT8("Slave Address:1:hex",SlaveAddress), XSPY_ADD_UINT8("CmdRead:1:hex:",bCmdRead), XSPY_ADD_UINT8("ubCommandRx:1:hex:",ubCommandRx), XSPY_ADD_UINT8("CommandData0",ubCommandData[0]), XSPY_ADD_UINT8("CommandData1",ubCommandData[1]), XSPY_ADD_UINT8("Error Address:1:hex",ubErrorAddress), XSPY_ADD_UINT8("Error Condition0:1:hex ",uberrorcondition[0]), XSPY_ADD_UINT8("Error Condition1:1:hex ",uberrorcondition[1]), XSPY_ADD_UINT16("Status:1:hex:",uwStatus), XSPY_ADD_FLOAT("input",input), XSPY_ADD_FLOAT("Fan Speed",fFanSpeed), XSPY_ADD_FLOAT("Vout Setting",fVoutSetting), XSPY_ADD_FLOAT("Vin OV Fault",fVinOVFault), XSPY_ADD_FLOAT("Vin UV Warning",fVinUVWarn), XSPY_ADD_FLOAT("Temperature",fTemperature), XSPY_ADD_FLOAT("Vout Actual",fVoutActual), XSPY_ADD_FLOAT("Vin",fVin), XSPY_ADD_UINT8("readrxbyte0",ubRxData[0]), XSPY_ADD_UINT8("readrxbyte1",ubRxData[1]) Application Guide 17 V1.1,

18 }; Initialize the xspy instance before the main loop function: DBG002_XspyInit(&XpyApp,AppVarTable,20,DBG002_GID_XSPY1); Implementation of PMBus Host on XMC4400 In the main loop function, the DBG002_XspyProcessCommand(&XpyApp) function is called to process the xspy command: While(1) { } Control Page DBG002_XspyProcessCommand(&XpyApp); An xspy control page is added to the project, PMBus_Host.xini. Figure 15 xspy Control Page Examples of sending commands Examples of sending a read, write and status command. Read Command The READ_VIN command is used to read the VIN values of the Slave Device. 1. Set PMBus Slave Device Address 2. In the Command field, enter the command code 0x88 for Read Vin command 3. Set the Read? to 1 for read operation. Application Guide 18 V1.1,

19 Implementation of PMBus Host on XMC Click on the Set button to transmit the settings to the PMBus Host. 5. Click on the Send Cmd button, to start the sending of the PMBus command to the PMBus Slave Device. 6. To update the VIN value on xspy, click on the Get button in the Slave Device Data frame. 7. The updated VIN value is displayed. Figure 16 READ_VIN Command Application Guide 19 V1.1,

20 Implementation of PMBus Host on XMC4400 Write Command The FAN_COMMAND_1 is used to set the FAN speed. 1. Set PMBus Slave Device Address 2. In the Command field, enter the command code 0x3B for FAN_COMMAND_1. 3. Set the Read? field to 0 for write operation. 4. Set the Input to 50.0, to set the fan speed to 50rpm. 5. Click on the Set button to transmit the settings to the PMBus Host. 6. Click on the Send Cmd button, to start the sending of the PMBus command to the PMBus Slave Device. 7. To check the Slave Device fan setting, send the FAN_COMMAND_1 command again with read operation. The Fan Speed in the Slave Device Data frame will be updated with new fan speed value. Figure 17 FAN_COMMAND_1 Command Figure 18 Read back the setting of the FAN Speed. Application Guide 20 V1.1,

21 Implementation of PMBus Host on XMC4400 Status Command This STATUS_WORD command is sent to the Slave Device to monitor its status. The two data bytes of information returned give the Host a summary of the Slave fault condition. In this example, the returned information indicates that the Slave is powered off. 1. Set PMBus Slave Device Address 2. In the Command field, enter the command code 0x79 for Status Word command 3. Set the Read? to 1 for read operation. 4. Click on the Set button to transmit the xspy settings to the PMBus Host. 5. Click on the Send Cmd button, to start the sending of the PMBus command to the PMBus Slave Device. 6. To update the status information on xspy, click on the Get button in the Slave Device Data frame. 7. The updated status is displayed in the Slave Device Status frame. It showed the PMBus Slave Device is powered off. Figure 19 Status Word Command Application Guide 21 V1.1,

22 Implementation of PMBus Host on XMC4400 Host Notify Protocol If the PMBus Slave Device has a failure, it sends out a notice to the Host. The data bytes received from the Slave contain the same information as the STATUS_WORD command. In this example, the Slave has an input voltage fault. 1. Click on the Get button in the Slave Device Data frame. 2. The error information is updated and displayed in the Slave Device Data frame and Slave Device Status frame. Figure 20 Host Notify Status Application Guide 22 V1.1,

23 Software Package for PMBus Host 3 Software Package for PMBus Host List of DAVE TM Apps used Apps CLK001 DAVESupport DBG001 I2C001 NVIC002 RESET001 Description Configure system and peripheral clock DAVE TM Apps initialization and configure the multiplexer registers Debug log app required for xspy Configure one of the USIC channel as I 2 C Interrupt handler apps Provides API to assert/de-assert peripheral modules List of source files, excluding DAVE TM generated files Filename Main.c PMBUS001_HOST.c PMBUS001_GENERAL.c CONFIG.h PMBUS001_HOST.h PMBUS001_GENERAL.h Description The main tasks of this example project PMBus protocol layer functions implementation Functions related to data conversions and packet error checking Configuration of the supported features PMBus commands definition and the PMBus protocol layer function declarations Function declarations defined in PMBUS001_GENERAL.c Application Guide 23 V1.1,

24 Conclusion 4 Conclusion The Infineon XMC4000 family of microcontrollers provide a great deal of flexibility for the creation of a wide variety of robust user applications for the users. This application guide demonstrates the ease of creating a PMBus Host Device, using the general purpose port module and the USIC modules in the XMC4400 microcontroller. With the use of DAVE TM xspy plug-in, it is possible to easily monitor and control the PMBus Slave Devices. Application Guide 24 V1.1,

25 References 5 References [1] XMC4400 Reference Manual, version 1.1, November 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) [5] xspy Getting Started, version 1.0, Application Guide 25 V1.1,

26 w w w. i n f i n e o n. c o m Published by Infineon Technologies AG