XMC 400 0 Microcontroller Series for Industrial Applications Po wer Ma nage m ent Bus ( P M Bus ) Sla ve D e vice wi th X M C40 00 Applic atio n Guid e V1.1 2014-03 Mic rocon t rolle rs Edition 2014-03 Published by Infineon Technologies AG, 81726 Munich, Germany. © 2014 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.1, 2014-03 Power Management Bus (PMBus) Slave Device with XMC4000 Revision History Date Version Change Description July 2013 1.0 Initial release March 2014 1.1 − I2C001 app replaced by I2C003 app − Update Table 7 ’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, 2014-03 Power Management Bus (PMBus) Slave Device with XMC4000 Table of Contents Revision History .................................................................................................................................................... 4 Table of Contents .................................................................................................................................................. 5 1 1.1 1.2 1.3 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 1.3.6 1.4 Overview ............................................................................................................................................ 6 System Overview ................................................................................................................................ 6 PMBus Features.................................................................................................................................. 7 PMBus Protocols ................................................................................................................................. 7 Send Byte ............................................................................................................................................ 8 Write Byte ............................................................................................................................................ 8 Write Word .......................................................................................................................................... 9 Read Byte ............................................................................................................................................ 9 Read Word ........................................................................................................................................ 10 Host Notify ......................................................................................................................................... 10 PMBus Commands and Data Formats ............................................................................................. 11 2 2.1 2.2 2.2.1 2.2.2 2.2.2.1 2.2.2.2 2.2.2.3 2.2.2.4 2.2.3 2.2.4 2.3 2.3.1 2.3.2 Implementation of PMBus Slave on XMC4500 ............................................................................. 12 Hardware ........................................................................................................................................... 13 Software ............................................................................................................................................ 14 Software Flow.................................................................................................................................... 15 Software API Functions ..................................................................................................................... 16 PMBus Protocol Layer Interface API Functions ................................................................................ 16 2 I C Transport Layer Interface API Functions .................................................................................... 16 Data Storage API Functions .............................................................................................................. 17 Interrupt Handlers.............................................................................................................................. 17 Packet Error Checking (PEC) ........................................................................................................... 17 Fault Reporting Mechanism .............................................................................................................. 17 Implementation Consideration .......................................................................................................... 18 How to modify a response for a command ....................................................................................... 18 How to add a command .................................................................................................................... 19 3 3.1 3.1.1 3.2 Application Example ....................................................................................................................... 20 Getting Started .................................................................................................................................. 20 Hardware Setup ................................................................................................................................ 20 XMC4500 PMBus Software Package for Slave Device .................................................................... 22 4 Conclusion ....................................................................................................................................... 23 5 References ....................................................................................................................................... 24 Application Guide 5 V1.1, 2014-03 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.1, 2014-03 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.1, 2014-03 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.1, 2014-03 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.1, 2014-03 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.1, 2014-03 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.1, 2014-03 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 Code Name 01h OPERATION 03h CLEAR_FAULTS 11h 12h 19h 20h 21h 3Ah 3Bh STORE_DEFAULT_ALL RESTORE_DEFAULT_ALL CAPABILITY VOUT_MODE VOUT_COMMAND FAN_CONFIG_1_2 FAN_COMMAND_1 55h VIN_OV_FAULT_LIMIT 56h VIN_OV_FAULT_RESPONSE 58h VIN_UV_WARN_LIMIT 5Ah VIN_UV_FAULT_RESPONSE Application Guide Packet R/W Byte Data Format Description Specification defined data format Turn the Slave Device on/off with control signal, and set the output voltage to margins. No, write only Clear any fault bits set in the status registers. No, write only Copy the entire contents of the operating memory to the matching locations in the nonvolatile Default Store memory. No, write only Copy the entire contents of the non-volatile Default Store memory to the matching locations in the operating memory. Send Byte Send Byte Send Byte Specification defined Read Byte data format* Specification defined R/W Byte data format* LINEAR R/W Word (output voltage related) R/W Specification defined Byte data format* R/W Word R/W Word Byte Word R/W Byte 12 Set the Slave Device output voltage. Configure up to two fans associated with one PMBus Slave Device. Adjust the operation of the fan. LINEAR Set the VIN overvoltage value The VIN overvoltage fault is reported if the input voltage is above this value. data format* R/W Set or read the format of the output voltage data. LINEAR Specification defined R/W For Host system to determine some key capabilities of a PMBus Slave device. Instruct the Slave on the action to take in response to an input overvoltage fault. LINEAR Set the VIN under voltage value warning limit. Specification defined Instruct the device on what action to take in response to an V1.1, 2014-03 Power Management Bus (PMBus) Slave Device with XMC4000 Implementation of PMBus Slave on XMC4500 Code Name Packet Data Format data format* 78h R/W STATUS_BYTE 79h STATUS_WORD 7Ch STATUS_INPUT Byte R/W Word R/W Byte R/W 7Eh STATUS_CML 81h STATUS_FAN_1_2 88h READ_VIN 8Bh READ_VOUT 8Dh READ_TEMPERATURE_1 Byte R/W Byte Specification defined data format* Slave Device to return one byte of information with a summary of the most critical faults. Specification defined data format* Slave Device to return two bytes of information with a summary of the Slave Device’s fault condition. Specification defined data format* Slave Device to return one byte of information with input related faults. Specification defined data format* Slave Device to return one byte of information with communication, logic and memory related faults. Specification defined data format* Slave Device to report on the status of any fans installed in position 1 or position 2. LINEAR Slave Device to return the input voltage. LINEAR (output voltage related) Slave Device to return the actual, measured (not commanded) output voltage. LINEAR Slave Device to return the measured temperature in degree Celsius. Read Word Read Word Description input under voltage fault. Read Word *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 2 USIC module which can support I C communication. Application Guide 13 V1.1, 2014-03 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 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, 2014-03 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. The protocol is translated into I C communication in the PMBus protocol layer. The command is transmitted to the PMBus Slave Device through the I C transport layer. 2 2 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 C transport layer. 2 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.1, 2014-03 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 2 I C 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 Table 4 App I2C003. 2 I C Transport Layer Interface API API Functions Name Description Input Parameter void IICSlaveTransmit(*data, SendCount) Configures the data for writing in to the USIC FIFO *data: address pointer to the data that is to be transmitted SendCount: number of data bytes to be transmitted void IICWriteData(*data) Application Guide Writes out a Word to the USIC FIFO transmit buffer register without waiting for any previous data to be transmitted. 16 *data: address pointer to the data V1.1, 2014-03 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 void CmdRestoreDefaultAll(void) Restore all PMBus parameters from Flash None memory. void CmdStoreDefaultAll(void) Store all PMBus parameters to Flash memory None Result EraseSector(void) Erase the first sector of the SPI Serial Flash. Result = 1: Success Program 256 bytes of data to the first sector of the SPI Serial Flash Result = 1: Success Result ProgramPage(void) 2.2.2.4 Return Value Result = 2: Erase Failed Result = 2: Program Failed 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 I C 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 2 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.1, 2014-03 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.1, 2014-03 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.1, 2014-03 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.1, 2014-03 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.1, 2014-03 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 Table 7 List of DAVE TM Apps used Apps Description ADC002 Configure an ADC kernel for the VIN measurement CLK001 Configure the system and peripheral clocks DAVESupport DAVE I2C003 Configure one of the USIC channels as I C Slave NVIC002 Interrupt handler apps PWMSP001 Use as a timer to trigger ADC conversion RESET001 Provides API to assert/de-assert peripheral modules SPI001 Configure one of the USIC channels as SPI. TM Apps initialization and configure the multiplexer registers 2 This is used to communicate with the Serial Flash memory. Table 8 List of source files (excluding DAVE TM 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.1, 2014-03 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.1, 2014-03 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.1, 2014-03 w w w . i n f i n e o n . c o m Published by Infineon Technologies AG