PMBus™ Stack User’s Guide - Microchip Technologyww1.microchip.com/downloads/en/DeviceDoc/41361A.pdf · • Microchip products meet the specification cont ained in their particular

© 2008 Microchip Technology Inc. DS41361A

PMBus™ StackUser’s Guide

Note the following details of the code protection feature on Microchip devices:• Microchip products meet the specification contained in their particular Microchip Data Sheet.

• Microchip believes that its family of products is one of the most secure families of its kind on the market today, when used in the intended manner and under normal conditions.

• There are dishonest and possibly illegal methods used to breach the code protection feature. All of these methods, to our knowledge, require using the Microchip products in a manner outside the operating specifications contained in Microchip’s Data Sheets. Most likely, the person doing so is engaged in theft of intellectual property.

• Microchip is willing to work with the customer who is concerned about the integrity of their code.

• Neither Microchip nor any other semiconductor manufacturer can guarantee the security of their code. Code protection does not mean that we are guaranteeing the product as “unbreakable.”

Code protection is constantly evolving. We at Microchip are committed to continuously improving the code protection features of ourproducts. Attempts to break Microchip’s code protection feature may be a violation of the Digital Millennium Copyright Act. If such actsallow unauthorized access to your software or other copyrighted work, you may have a right to sue for relief under that Act.

Information contained in this publication regarding deviceapplications and the like is provided only for your convenienceand may be superseded by updates. It is your responsibility toensure that your application meets with your specifications.MICROCHIP MAKES NO REPRESENTATIONS ORWARRANTIES OF ANY KIND WHETHER EXPRESS ORIMPLIED, WRITTEN OR ORAL, STATUTORY OROTHERWISE, RELATED TO THE INFORMATION,INCLUDING BUT NOT LIMITED TO ITS CONDITION,QUALITY, PERFORMANCE, MERCHANTABILITY ORFITNESS FOR PURPOSE. Microchip disclaims all liabilityarising from this information and its use. Use of Microchipdevices in life support and/or safety applications is entirely atthe buyer’s risk, and the buyer agrees to defend, indemnify andhold harmless Microchip from any and all damages, claims,suits, or expenses resulting from such use. No licenses areconveyed, implicitly or otherwise, under any Microchipintellectual property rights.

DS41361A-page ii

Trademarks

The Microchip name and logo, the Microchip logo, Accuron, dsPIC, KEELOQ, KEELOQ logo, MPLAB, PIC, PICmicro, PICSTART, rfPIC, SmartShunt and UNI/O are registered trademarks of Microchip Technology Incorporated in the U.S.A. and other countries.

FilterLab, Linear Active Thermistor, MXDEV, MXLAB, SEEVAL, SmartSensor and The Embedded Control Solutions Company are registered trademarks of Microchip Technology Incorporated in the U.S.A.

Analog-for-the-Digital Age, Application Maestro, CodeGuard, dsPICDEM, dsPICDEM.net, dsPICworks, dsSPEAK, ECAN, ECONOMONITOR, FanSense, In-Circuit Serial Programming, ICSP, ICEPIC, Mindi, MiWi, MPASM, MPLAB Certified logo, MPLIB, MPLINK, mTouch, PICkit, PICDEM, PICDEM.net, PICtail, PIC32 logo, PowerCal, PowerInfo, PowerMate, PowerTool, REAL ICE, rfLAB, Select Mode, Total Endurance, WiperLock and ZENA are trademarks of Microchip Technology Incorporated in the U.S.A. and other countries.

SQTP is a service mark of Microchip Technology Incorporated in the U.S.A.

All other trademarks mentioned herein are property of their respective companies.

© 2008, Microchip Technology Incorporated, Printed in the U.S.A., All Rights Reserved.

Printed on recycled paper.

© 2008 Microchip Technology Inc.

Microchip received ISO/TS-16949:2002 certification for its worldwide headquarters, design and wafer fabrication facilities in Chandler and Tempe, Arizona; Gresham, Oregon and design centers in California and India. The Company’s quality system processes and procedures are for its PIC® MCUs and dsPIC® DSCs, KEELOQ® code hopping devices, Serial EEPROMs, microperipherals, nonvolatile memory and analog products. In addition, Microchip’s quality system for the design and manufacture of development systems is ISO 9001:2000 certified.

PMBus™ Stack USER’S GUIDE

Preface

INTRODUCTIONThis chapter contains general information that will be useful to know before using the PMBus™ Stack User’s Guide. Items discussed in this chapter include:• Document Layout• Conventions Used in this Guide• Recommended Reading• The Microchip Web Site• Development Systems Customer Change Notification Service• Customer Support• Document Revision History

DOCUMENT LAYOUTThis document describes how to use the PMBus™ Stack User’s Guide as a develop-ment tool to emulate and debug firmware on a target board. The manual layout is as follows: • Chapter 1. “General Aspects” – Introduces the PMBus Stack and provides a

brief description of the needed microcontroller resources and the bus protocols that the stack recognizes and processes.

• Chapter 2. “Stack Limitations” – Describes the limitations of the PMBus Stack with respect to Fault management, addressing, detection, control line and paging.

• Chapter 3. “PMBus Protocols – How Are They Handled by the Stack” – Details the three types of transactions that a host can initiate on the bus (write, read, write-read).

• Chapter 4. “Data Into/Out of Variables” – Describes how data can be trans-ferred from the host to the slave devices and vice-versa by means of PMBus commands.

NOTICE TO CUSTOMERS

All documentation becomes dated, and this manual is no exception. Microchip tools and documentation are constantly evolving to meet customer needs, so some actual dialogs and/or tool descriptions may differ from those in this document. Please refer to our web site (www.microchip.com) to obtain the latest documentation available.

Documents are identified with a “DS” number. This number is located on the bottom of each page, in front of the page number. The numbering convention for the DS number is “DSXXXXXA”, where “XXXXX” is the document number and “A” is the revision level of the document.

For the most up-to-date information on development tools, see the MPLAB® IDE on-line help. Select the Help menu, and then Topics to open a list of available on-line help files.

© 2008 Microchip Technology Inc. DS41361A-page 1

PMBus™ Stack User’s Guide

• Chapter 5. “Stack Functionality” – Describes the states that are recognized and handled by the I2C™ module as sources of interrupt.

• Chapter 6. “Device Fault Management” – Provides information which will help the user implement a consistent mechanism of handling warnings and faults in PMBus systems.

• Chapter 7. “User Data Needed for the Stack’s Functionality” – Presents a set of variables and commands that the user can define for the stack to follow.

• Appendix A. “List of Labels to Be Defined by the User” – Provides a list of labels and variables that need to be defined by the user.

• Appendix B. “Testing the Stack” – Illustrates how the stack has been tested for this implementation.

• Appendix C. “Defining Functions for Warning and Fault Responses” – Provides a list of functions that need to be defined for warnings and faults.

• Appendix D. “PEC Byte Calculation” – Illustrates how the PEC byte is calcu-lated for each type of transaction.

• Appendix E. “Parsing the Commands Table” – Discusses how big the array of structures can be for the stack to parse it in a reasonable amount of time.

• Appendix F. “Buffer Construction” – Provides information as to what data the buffer will contain and handle.

DS41361A-page 2 © 2008 Microchip Technology Inc.

Preface

CONVENTIONS USED IN THIS GUIDEThis manual uses the following documentation conventions:

DOCUMENTATION CONVENTIONSDescription Represents Examples

Arial font:Italic characters Referenced books MPLAB® IDE User’s Guide

Emphasized text ...is the only compiler...Initial caps A window the Output window

A dialog the Settings dialogA menu selection select Enable Programmer

Quotes A field name in a window or dialog

“Save project before build”

Underlined, italic text with right angle bracket

A menu path File>Save

Bold characters A dialog button Click OKA tab Click the Power tab

N‘Rnnnn A number in verilog format, where N is the total number of digits, R is the radix and n is a digit.

4‘b0010, 2‘hF1

Text in angle brackets < > A key on the keyboard Press <Enter>, <F1>Courier New font:Plain Courier New Sample source code #define START

Filenames autoexec.bat

File paths c:\mcc18\h

Keywords _asm, _endasm, static

Command-line options -Opa+, -Opa-

Bit values 0, 1

Constants 0xFF, ‘A’

Italic Courier New A variable argument file.o, where file can be any valid filename

Square brackets [ ] Optional arguments mcc18 [options] file [options]

Curly brackets and pipe character: { | }

Choice of mutually exclusive arguments; an OR selection

errorlevel {0|1}

Ellipses... Replaces repeated text var_name [, var_name...]

Represents code supplied by user

void main (void){ ...}



RECOMMENDED READINGThis user’s guide describes how to use the PMBus Stack. Other useful documents are listed below. The following documents are available and recommended as supplemen-tal reference resources.PMBus™ Power System Management Protocol Specification – Part I – Revision 1.1 (http://pmbus.org/).This document describes the general requirements, transport and electrical layer of the PMBus protocol.PMBus™ Power System Management Protocol Specification – Part II – Revision 1.1 (http://pmbus.org/).This document describes the command language of the PMBus protocol.System Management Bus (SMBus™) Specification Version 2.0 (http://smbus.org/specs/).This document is the official specification of the SMBus interface.Using the PIC® Devices’ SSP and MSSP Modules for Slave I2C™ Communication (AN734) – http://www.microchip.comThis application note summarizes the usage of the SSP module as a slave in I2C communications.

THE MICROCHIP WEB SITEMicrochip provides online support via our web site at www.microchip.com. This web site is used as a means to make files and information easily available to customers. Accessible by using your favorite Internet browser, the web site contains the following information:• Product Support – Data sheets and errata, application notes and sample

programs, design resources, user’s guides and hardware support documents, latest software releases and archived software

• General Technical Support – Frequently Asked Questions (FAQs), technical support requests, online discussion groups, Microchip consultant program member listing

• Business of Microchip – Product selector and ordering guides, latest Microchip press releases, listing of seminars and events, listings of Microchip sales offices, distributors and factory representatives


http://pmbus.org/

http://pmbus.org/

http://smbus.org/specs/

http://www.microchip.com

Preface

DEVELOPMENT SYSTEMS CUSTOMER CHANGE NOTIFICATION SERVICEMicrochip’s customer notification service helps keep customers current on Microchip products. Subscribers will receive e-mail notification whenever there are changes, updates, revisions or errata related to a specified product family or development tool of interest.To register, access the Microchip web site at www.microchip.com, click on Customer Change Notification and follow the registration instructions.The Development Systems product group categories are:• Compilers – The latest information on Microchip C compilers and other language

tools. These include the MPLAB C18 and MPLAB C30 C compilers; MPASM™ and MPLAB ASM30 assemblers; MPLINK™ and MPLAB LINK30 object linkers; and MPLIB™ and MPLAB LIB30 object librarians.

• Emulators – The latest information on Microchip in-circuit emulators. This includes the MPLAB ICE 2000 and MPLAB ICE 4000.

• In-Circuit Debuggers – The latest information on the Microchip in-circuit debugger, MPLAB ICD 2.

• MPLAB® IDE – The latest information on Microchip MPLAB IDE, the Windows® Integrated Development Environment for development systems tools. This list is focused on the MPLAB IDE, MPLAB SIM simulator, MPLAB IDE Project Manager and general editing and debugging features.

• Programmers – The latest information on Microchip programmers. These include the MPLAB PM3 and PRO MATE® II device programmers and the PICSTART® Plus and PICkit™ 1 development programmers.

CUSTOMER SUPPORTUsers of Microchip products can receive assistance through several channels:• Distributor or Representative• Local Sales Office• Field Application Engineer (FAE)• Technical SupportCustomers should contact their distributor, representative or field application engineer (FAE) for support. Local sales offices are also available to help customers. A listing of sales offices and locations is included in the back of this document.Technical support is available through the web site at: http://support.microchip.com

DOCUMENT REVISION HISTORY

Revision A (December 2008)• Initial Release of this Document.



NOTES:



Table of Contents

Preface ........................................................................................................................... 1Chapter 1. General Aspects

1.1 PMBus Overview ............................................................................................ 91.2 What is the Stack? ......................................................................................... 9

Chapter 2. Stack Limitations2.1 Fault Management ....................................................................................... 112.2 Addressing ................................................................................................... 112.3 Time-out Detection ....................................................................................... 112.4 Control Line .................................................................................................. 112.5 Paging .......................................................................................................... 11

Chapter 3. PMBus Protocols – How Are They Handled by the Stack3.1 Transaction Types ........................................................................................ 133.2 Write Transactions ....................................................................................... 13

3.2.1 SEND BYTE .............................................................................................. 133.2.2 WRITE BYTE ............................................................................................ 133.2.3 WRITE WORD .......................................................................................... 133.2.4 BLOCK WRITE .......................................................................................... 143.2.5 GROUP_COMMAND_PROTOCOL .......................................................... 14

3.3 Read Transactions ....................................................................................... 143.3.1 READ BYTE .............................................................................................. 143.3.2 READ WORD ............................................................................................ 153.3.3 BLOCK READ ........................................................................................... 15

3.4 Write/Read Transactions .............................................................................. 15Chapter 4. Data Into/Out of Variables

4.1 Writing to the Device .................................................................................... 184.2 Reading from the Device .............................................................................. 18

Chapter 5. Stack Functionality5.1 STATE 1 – START ....................................................................................... 195.2 STATE 2 – MWA (Master Writes Address) .................................................. 195.3 STATE 3 – MWD (Master Writes Data) ........................................................ 195.4 STATE 4 – MRA (Master Reads Address) ................................................... 205.5 STATE 5 – MRD (Master Reads Data) ........................................................ 205.6 STATE 6 – STOP ......................................................................................... 20

Chapter 6. Device Fault Management6.1 STATUS Registers Tree ............................................................................... 226.2 What Warnings Does the Stack Cover? ....................................................... 23

6.2.1 Data Transmission Faults ......................................................................... 236.2.2 Data Content Faults .................................................................................. 25


6.2.3 Data Content Faults Covered by the Main Application .............................. 256.2.4 Warning and Fault Reporting by the Main Application ............................. 266.2.5 Setting the Warning Thresholds – Reacting to Warnings .......................... 266.2.6 Setting the Warning Thresholds – Reacting to Faults ............................... 27

Chapter 7. User Data Needed for the Stack’s Functionality7.1 Stack’s List of Labels and Variables Defined by the User ............................ 297.2 Building the Command Table ...................................................................... 297.3 Application Function Called by the Stack .................................................... 31

Appendix A. List of Labels to Be Defined by the UserA.1 Labels 35

A.1.1 General Purpose Labels ........................................................................... 35A.1.2 PMBus Protocol Labels ............................................................................. 35A.1.3 Command Code Labels ............................................................................ 35

A.2 Variables ...................................................................................................... 35A.2.1 General Purpose Labels .......................................................................... 35A.2.2 Declaration of Commands-Related Data (Example of Two Commands) .. 36

A.3 Array of Structures (Example of 5 Elements) ............................................... 36A.4 Array of Indices ............................................................................................ 36

Appendix B. Testing the StackAppendix C. Defining Functions for Warning and Fault Responses

C.1 Warnings ...................................................................................................... 41C.2 Faults ........................................................................................................... 41

Appendix D. PEC Byte CalculationD.1 Write Transaction ......................................................................................... 43D.2 Read Transaction ........................................................................................ 43D.3 Write/Read Transactions ............................................................................. 43

Appendix E. Parsing the Commands TableAppendix F. Buffer ConstructionWorldwide Sales and Service .................................................................................... 48



Chapter 1. General Aspects

1.1 PMBus OVERVIEWPMBus is an open standard protocol that was defined as a means of communication with power conversion and other devices, thus creating the first open communications standard in the world of digital control over power devices and systems.PMBus is a superset of the System Management Bus (SMBus™), an industry standard serial communication interface. It uses some of the SMBus protocols, but not all, while adding a significant amount of new functions.

1.2 WHAT IS THE STACK?Microchip PMBus stack version 1.0 implements the PMBus protocol over the traditional I2C™ communication interface for mid-range PIC® microcontrollers from the PIC16F88X family. The stack was written for the PMBus version 1.1, released on 5 February 2007. At the low level, the stack is actually the Interrupt Service Routine (ISR) handler for the I2C interrupts in a microcontroller acting as a slave device in a PMBus environment. It represents a block of code meant to implement the protocol’s transport link layer. Necessary microcontroller resources:

- The MSSP (SSP module) module is configured for Slave mode in 7-bit Address mode with Start/Stop bit interrupts running in standard Speed mode (100 kHz).

- Timer0 with T0CS clock source incremented on every low-to-high transition for counting bus clock pulses. Thus, the corresponding PIC device’s T0CKI pin (e.g., RA4 for PIC16F886) should always be tied externally to the SCL pin (e.g., RC3 for PIC16F886).

- Internal oscillator configured for 8 MHz.- The stack and a set of 42 defined PMBus commands occupy 123 bytes of

data memory and 1.5 KB of program memory.The stack recognizes and processes the following PMBus protocols: SEND_BYTE, READ_BYTE, WRITE_BYTE, READ_WORD, WRITE_WORD, READ_BLOCK, WRITE_BLOCK, and the following extension protocols: BLOCK_WRITE_BLOCK_READ_PROCESS_CALL and GROUP_COMMAND_PROTOCOL. The stack considers the PEC byte as implicit for any of these protocols. The PEC is a CRC-8 error-checking byte, calculated on all message bytes (including address and read/write bits). The PEC is appended to the message by the device that supplied the last data byte. Information is passed to and from the main application in a very simple manner. Any command to be sent to the device uses one of the PMBus protocols mentioned before. The stack handles this transaction and passes or retrieves information to and from the main application. Thus, we may conclude that the stack works in strict coordination with the main application, passing the latter data to be processed or requiring it to prepare data for the host.



NOTES:



Chapter 2. Stack Limitations

2.1 FAULT MANAGEMENTFollowing a warning or a Fault event, a PMBus device may notify the host about its state by setting the warning/Fault condition bits in the STATUS registers and wait for the host to pool them. The other methods of direct notifying the host through the SMBAlert line or the “host notify protocol” are not implemented in this version. Also, the stack does not detect a Fault generated by the following conditions:

- data out of range- invalid or unsupported data

The main application is responsible for modifying the appropriate STATUS registers so that this kind of Fault shall be visible to the host. Code examples related to this aspect are included in this manual, as well as in the demo application delivered with the stack.

2.2 ADDRESSINGDue to the restrictive nature of the I2C™ addressing capability of the PIC16F886/887, this stack version allows the device to respond only to its 7-bit slave address sent on the bus.

2.3 TIME-OUT DETECTIONThe stack does not offer support for time-out detection.

2.4 CONTROL LINEThe functionality of this additional PMBus line is supported by a user-supplied routine.

2.5 PAGINGThe stack does not offer support for the PAGE command.



NOTES:



Chapter 3. PMBus Protocols – How Are They Handled by the Stack

3.1 TRANSACTION TYPESThere are 3 types of transactions that a host can initiate on the bus: write, read and combined write-read protocols. Because the protocols supported by the stack share much of the manner in which they are handled, we will describe each of the 3 types of transactions and mention which protocols subscribe to this category.

3.2 WRITE TRANSACTIONSThis is a type of transaction that implies that the host can send all the data and the slave can ACK/NACK the received packets. All write protocols start with an address being sent to the slave, which has the RW(bit[0]) with a value of ‘0’. If the hardware has ACKed the slave defined address, then the Master Writes Address (MWA) state is entered and execution continues as described there. A Master Writes Data (MWD) state, containing the command code, must follow. All write protocols start with an address being sent to the slave, which has the RW(bit[0]) with a value of ‘0’, causing the stack to enter the MWA state. The following bytes, sent only by the host are the command code, the number of bytes to be sent (where applicable), data bytes (where applicable) and the optional PEC byte. The stack ACKs each byte, but checks for the validity of the communication or the data content.The way each supported write protocol looks like is described next (note that the PEC byte is optional):

3.2.1 SEND BYTE

Only the address of the slave and one data byte, which is the command code, are sent.Example of command using this protocol: CLEAR_FAULTS.

3.2.2 WRITE BYTE

The host sends one data byte besides the address and the command code. Example of command using this protocol: VOUT_MODE.

3.2.3 WRITE WORD

With this protocol, the host sends two data bytes. Example of command using this protocol: VOUT_COMMAND.



3.2.4 BLOCK WRITE

Besides the address and the command code, the host is responsible for sending a byte representing the actual number of data bytes that are going to be sent and the data bytes themselves. Example of command using this protocol: MFR_ID.

3.2.5 GROUP_COMMAND_PROTOCOL

This extension PMBus protocol is used by the host to send commands to more than one PMBus device. The commands are sent in one continuous transmission. When the devices detect the Stop condition that ends the sending of commands, they all begin executing the command they received. From the stack’s point of view, this is nothing more than a simple WRITE_BYTE/WORD/BLOCK protocol. The only difference is that the Stop condition will be received after all devices in the host’s queue have been written to; thus, only then can an application function be called to handle the data.

3.3 READ TRANSACTIONSIn this kind of PMBus transaction, both the host and the slave put data on the bus, each being responsible for ACK/NACKing the bytes received. The first part of a read transaction resembles a write transaction, meaning that the host has to send the slave address with the RW bit with a value of ‘0’ and, after that, the code of the command being issued. In order for the transaction to be a read, the host has to generate a Restart condition, and then send the slave address with the RW bit set. Thus, the stack recognizes that the master wants to read data from the slave and, therefore, puts the data bytes on the bus, calculating at the same time the PEC byte for the entire transaction and then adding this byte at the end of the transfer.

3.3.1 READ BYTE

Protocol used by the host to retrieve one data byte. Example of commands using this protocol: STATUS_VOUT, STATUS_IOUT.


PMBus Protocols – How Are They Handled by the Stack

3.3.2 READ WORD

Protocol used by the host to retrieve two data bytes. Example of command using this protocol: STATUS_WORD.

3.3.3 BLOCK READ

Using this protocol, the host tries to retrieve a block of data that belongs to a command. Before putting the data bytes on the bus, the stack has to send first the number of bytes. Example of command using this protocol: MFR_MODEL.

3.4 WRITE/READ TRANSACTIONSThe PMBus protocol, as mentioned in revision 1.1, introduces an extension protocol, process call. This extension was named Block Write/Block Read Process Call.

This is a combined block-write/block-read protocol. Both the host and the slave are required to participate in the transaction and put data on the bus. This kind of protocol is used when the host needs information from the slave, but the information has to be processed based on the input data bytes sent by the host. For a command that is issued using this protocol, an equivalent transfer function can be defined in the form of Y=F(X), where X represents the data sent by the host and Y represents the slave output data calculated with the respective command’s function F. Note that, in the read portion of the protocol, the slave address and the command code are missing. Example of command using this protocol: QUERY. This command is used to ask a PMBus device if it supports a given command and, if so, what data formats it supports for that command. This command uses the above described Block Write-Block Read Process Call. For the write portion of the process call, the one data byte is an unsigned binary integer, the value of which is equal to the command code of the command being investigated. For the read portion of the process call, the one data byte is an unsigned binary integer that encrypts the slave device answer to the host’s enquiry. Please note that the number of bytes sent by the host during the write portion may differ from the number of bytes sent by the slave during the read



portion. This difference is command dependant, a good example being the COEFFICIENTS command, for which the host sends two data bytes and expects five bytes in return from the slave.



Chapter 4. Data Into/Out of Variables

PMBus commands are presumed to transfer data from the host to the slave device or vice-versa. The stack is the firmwire interface between the host and the device and is supposed to handle the communication and deliver the data bytes of the command to the corresponding locations in the device’s RAM or to get the data out of the RAM and onto the bus. The block diagram of the host-device communication is shown in Figure 4-1:

FIGURE 4-1: HOST-DEVICE COMMUNICATION

Two memory spaces are mentioned in the diagram above: the buffer and ordinary RAM space. The stack needs both these chunks of memory in order to accomplish the communication with the host. To put it simply, almost all commands that form the language set, which the application decides to support, need space for the data bytes. Exceptions are commands using the PMBus SEND_BYTE protocol.For a better filtering of faults that lead to erroneous data sent by the host, a buffer has been constructed in the RAM data memory of the device. Any Write command will have its data bytes temporarily stored in this buffer. Applications functions may be called when a Stop is received and these data bytes can be processed and later copied in the RAM GPR locations of the command.Almost all commands in the PMBus command language have data bytes available for writing or reading correspondent information. The user should check for data memory availability on the device in the process of deciding upon the set of commands that the application will support. The application must reserve a number of memory locations equal to the number of data bytes written or read for that command. Each command must have space reserved in the form of an array with the dimension equal to the number of bytes of that command. For example, for the STATUS_WORD command, an array has to be defined like this: unsigned char STATUS_WORD[2]. Please note that the dimension of the array equals the number of bytes of this command. Details about how space can be reserved for supported commands can be found in Appendix A. “List of Labels to Be Defined by the User”.

HOST FirmwarePMBus StackI2CTM BusData

Buffer 0x0 0x1 … … … buf_limit

RAM



4.1 WRITING TO THE DEVICEThe stack checks the validity of the transaction sequentially. This means that every transaction is presumed valid until a data content/communication Fault occurs. Every data byte received by the stack in a write transaction is passed to the buffer and stored there. When a Stop is received, if there were no content/communication Faults, the stack calls an application function associated with the command, if available. To obtain information about the relevance of having an application function associated with the command, please check the section 7.3 “Application Function Called by the Stack ”.The called application function may process the command’s data bytes from the buffer and may decide if these bytes should be transferred or not to the correspondent RAM locations, by setting/resetting the flag ready_to_copy. This flag is a member of the structure global_flags. In the main loop of the program, the flag ready_to_copy is checked and, if it is set, then the copy_buf_to_ram() function is called. This function uses the information from the buffer’s overhead data and transfers the data bytes to the respective RAM section of the command.At this point, the application has the command’s data sent from the host to the designated memory area, which has the form of an array. The main application can use the data as it finds fit. The stack does not need to be aware of any modifications brought to a command’s data.

4.2 READING FROM THE DEVICEReading the data bytes of the command in course is quite simple. The stack will retrieve the command’s data bytes from its RAM memory space. The only interrupt in this flow occurs in the case of a Block Write/Block Read Process Call command. The main application is required to process the data byte sent by the host during the write portion, therefore before starting to put data on the bus, the stack calls an application function which will do this job and deliver the data bytes meant to be read by the host in the correspondent RAM locations.



Chapter 5. Stack Functionality

2
Below are the states that are recognized and handled by the I C™ module as sources of interrupt.Because no byte acknowledgement is present on the mid-range PIC16F886 microcontrollers, all bytes received from the host, that are acknowledged by the slave, trigger the setting of the SSPIF bit in the PIR1 register, and thus an I2C interrupt.
5.1 STATE 1 – STARTThis state is entered each time a Start or Restart condition is present on the bus. Checking the i2c_busy flag within this state ensures whether a PMBus transfer is already in progress. Furthermore, the TMR0 register’s content is checked to ensure that this is not a Start that has interrupted the transmission/reception of a byte. If the master has sent a Start/Stop condition that has interrupted the transmission/reception of a byte, the content of the TMR0 register will show this. If the value inside the latter mentioned register is below 9 and above 1, this means that an error has occurred and the proper flags in the STATUS registers are set (STATUS_BYTE and STATUS_CML).

5.2 STATE 2 – MWA (MASTER WRITES ADDRESS)This state is entered when the slave’s hardware detects a match between the address sent by the host on the bus and the internal SSPADD register. This is the first state in any PMBus transaction. Here, all the flags and counters are cleared and the slave sets itself in expectation for data to be received or requested. The CRC-8 calculation for this PMBus transaction starts with the slave address being sent to the basic_crc function, which then calculates the current PEC byte.

5.3 STATE 3 – MWD (MASTER WRITES DATA)This state is handled in strict coordination with the value of the MWD_counter, which encodes how many times this state has been entered in the current PMBus transaction. There are several branches for this state, each handling a value of the MWD_counter counter. A ‘0’ value of the counter signifies that the command code has just been received and the lookup table can be consulted to check the validity of this command code. If true, then the command index in the structured array is returned and the attributes associated with this command can be retrieved from there. If false, then this command is treated as unsupported, and data read or written by the bus will be discarded, as well as the corresponding STATUS register’s flags being set.The following values of the counter represent the number of data bytes sent by the host. There are two kinds of verifications being made each time a branch is entered:• The validity of the network link protocol

Only valid protocols for the current time stamp in the transaction are handled, otherwise a Fault is detected.

• The validity of the number of bytes sent by the hostThe bytes sent by the master are processed up to the defined maximum number of bytes for the respective command, otherwise a Fault is detected.



5.4 STATE 4 – MRA (MASTER READS ADDRESS)This state is entered each time the slave ACKs its address on the bus with the R\W bit set as an indication that the master wishes to read data bytes from the slave. To continue operation as expected, the stack will check for the following conditions:• The slave has already ACKed its address with the RW bit reset and the command

code has already been received• The current command is valid and supported

5.5 STATE 5 – MRD (MASTER READS DATA)This state is entered each time a data byte has been transmitted by the slave and a response from the master has been received. If no communication errors were present up to that moment, and the SDA line is still low, meaning that the host is still expecting data bytes, the stack prepares data to be sent to the host according to the protocol used in the current transaction and the number of bytes allowed to be sent.

5.6 STATE 6 – STOPEach time the host puts a Stop condition on the bus, the stack verifies whether this happens inside a transaction and if this condition interrupts, by accident, the transmission/reception of a byte.The stack has to make a final check whether a command has been transmitted through a write transaction with no errors. If this transaction was successful and the command indicates that it must be handled through a user-defined function (in this case the corresponding structure member func_support must equal the command's code), the stack will call this user-defined function.



Chapter 6. Device Fault Management

This section provides information that is meant to help the user implement a consistent mechanism of handling warnings and Faults in PMBus systems. However, it is not to be considered a replacement of the PMBus Specification version 1.1, but merely information with an explanatory focus.PMBus protocol provides the user with an extensive set of tools for monitoring the operation and managing the Faults or warnings in a PMBus device. The nature of a warning or a Fault can have various origins. It can be a temperature warning, a voltage Fault or just as well a communication or data content related Fault. The host can use READ commands to ask a PMBus device about its current state. Furthermore, there is one READ command for each operating parameter, such as output voltage, device temperature or output current. The PMBus protocol also includes the ability to program Fault or warning levels for every important aspect of a power conversion device.Because the stack accomplishes the communication between the host and the slave device, it is responsible for covering the transmission Faults and some of the content Faults. The latter category, content Faults, relate to the content of bytes in a transaction that ensures the delivering of data from the host to the slave: address and command code. However, the stack cannot make any assumptions on the content of the data bytes of a command. As a consequence, these actions are left on the side of the main application. Figure 6-1 illustrates how the Faults management system is covered by the stack and main application:

FIGURE 6-1: FAULTS MANAGEMENT SYSTEM

Device Faults Management

Communication Faults

Data Transmission

Data Content

Operation Faults

STACK

STACK

Application

Application



The PMBus protocol supports setting two types of threshold for nearly any possible event:

- A. Warning threshold as a minor alarmA warning condition is an indicator that a problem occurred on the device’s side, which does not affect the normal operation of the device.

- B. Fault threshold as a major alarmA Fault is an event more serious than a warning, and may cause the device to disable the output stage and stop transferring energy to the output. An important aspect worth mentioning here is that the PMBus protocol provides commands to set the automatic response to each Fault condition. These com-mands have one data byte that instructs the device how to respond to a Fault. Each of these Fault response commands requires the user to make one of three choices about how the device will respond to the Fault condition.

Following a warning or a Fault event, a PMBus device may notify the host about its state by setting the warning/Fault condition bits in the STATUS registers and wait for the host to pool them.

6.1 STATUS REGISTERS TREEThe PMBus protocol provides three levels of STATUS registers. This allows the host to retrieve the most important information related to a device in a fast transaction. Based on this information, the host can act or request more detailed information. Figure 6-2 below shows the relationship between the STATUS_BYTE register, the STATUS_WORD register and the more detailed STATUS registers. As we can see, the STATUS_BYTE register contains the most important Fault and warnings. This allows the most basic PMBus devices to provide the most critical information about their current state. The STATUS_WORD includes the STATUS_BYTE as its lower byte. Modifying a bit in the STATUS_BYTE triggers the modification of the STATUS_WORD register. That is why the stack only operates upon the STATUS_WORD and not upon both the STATUS_BYTE and STATUS_WORD.In the higher byte of the STATUS_WORD, there are additional bits providing more infor-mation about the status of the PMBus device.Advanced PMBus devices may implement seven additional registers with even more detailed information about the status of the unit. The host or power system manager knows which of these to read based on which bits are set in the STATUS_BYTE or STATUS_WORD.When the STATUS registers are cleared, all bits in all registers are cleared simultaneously. More detailed information about the STATUS registers can be found in the PMBus Specification, version 1.1.


Device Fault Management

FIGURE 6-2: STATUS REGISTER MAP

6.2 WHAT WARNINGS DOES THE STACK COVER?The stack acts only as a communication interface between the PMBus slave device and the host master. Therefore, only warnings and Faults that might be encountered during the transmitting/receiving process can be detected and handled by the stack. Because all the errors associated with data transmission and data content are classified as Faults, we can consider that the stack handles Faults related to the communication process.

6.2.1 Data Transmission Faults

6.2.1.1 CORRUPTED DATA

This Fault is generated by a mismatch between the received PEC byte from the host and the PEC byte calculated by the stack. The latter will:

- Ignore the data bytes of the received command- Not call any application function associated with this command (the command

is not recognized by the host, so the main application will not be notified)- Set the CML bit in the STATUS_BYTE- Set the Packet Error Check Failed bit in the STATUS_CML register

Thus, when the host tries to send a command to the slave in a write transaction, and the PEC byte at the end of the protocol does not match the PEC byte calculated by the stack, the actions mentioned above take place. Please note that a command sent by the host through a write protocol, that does not include the PEC byte at the end, is considered valid from this point of view. This Fault will affect the content of the STATUS_BYTE and STATUS_CML registers, these being logically ORed with the masked formed by the respective flags to be set.



6.2.1.2 SENDING/READING TOO FEW BITS

If, while the host is writing to/reading from a PMBus device the transmission/reception is interrupted by a Start or Stop condition before a complete byte has been sent/read, the stack will:

- Ignore the received command code and any received data- Not call any application function associated with this command- Set the CML bit in the STATUS_BYTE- Set bit 1 (Other fault) in the STATUS_CML register

6.2.1.3 HOST SENDS OR READS TOO FEW BYTES

If the host ends a PMBus packet with a Stop condition before the host has written/read all the bytes (PEC byte included) the PMBus device expected to receive/send, the stack will not treat this as an error and will process the command consequently. It is presumed that the host knows what it is doing and that it intentionally ended the transaction.

6.2.1.4 HOST SENDS TOO MANY BYTES

If, while writing to the PMBus device, the host sends more bytes than the device is expecting, the stack treats this as a Fault and will:

- Ignore the received command code and any received data- Set the CML bit in the STATUS_BYTE, Set the Invalid Or Unsupported Data

Received bit in the STATUS_CML register

6.2.1.5 READING TOO MANY BYTES

If, while reading from the device, the host tries to read more bytes than the device is expected to send, the stack will:

- Send all ones (FFh) as long as the host keeps clocking and acknowledging - Set the CML bit in the STATUS_BYTE- Set bit 1 (Other fault) in the STATUS_CML register

6.2.1.6 DEVICE BUSY

A data transmission Fault can occur if the device is too busy to respond to the communication on the bus. The user has the bit variable, device_busy, at his disposal and he can set this variable if it is too busy to handle a transaction. The stack will act as follows when it detects this bit set and a PMBus transaction takes place:

- ACK the slave address as this is a must- ACK the command and data bytes, but ignore them- Send all ones (FFh) as long as the host keeps clocking and acknowledging- Set the BUSY flag in the STATUS_BYTE

Although the user may sometimes reset the device_busy variable during the transfer, meaning it is now ready to respond to the communication, the stack will continue to ignore the command in progress and resets this state only after a Stop has been received.



6.2.2 Data Content Faults

6.2.2.1 IMPROPERLY SET BIT IN THE ADDRESS BYTE

A device’s address byte following a Start condition (not the Restart condition) must always have bit [0] with a value of ‘0’ (indicating a write). If the stack receives the device’s address directly after a Start Condition (not a Repeated Start Condition) with bit [0] equal to ‘1’, then it will:

- ACK the address byte as all PMBus devices must ACK their own address- Send all ones (FFh) as long as the host keeps clocking and acknowledging- Set the CML bit in the STATUS_BYTE- Set bit 1 (Other fault) in the STATUS_CML register

6.2.2.2 UNSUPPORTED COMMAND CODE

If the device receives a command that it does not support, including those command codes identified as Reserved, the stack will respond as follows:

- Ignore the received command code and any received data - Set the CML bit in the STATUS_BYTE register - Set the Invalid Or Unsupported Command Received bit in the STATUS_CML

register

6.2.3 Data Content Faults Covered by the Main ApplicationAs mentioned before, the stack cannot check the content of a command’s data bytes in a transaction. That is why the following Data Content Faults are left on the side of the main application for handling:

6.2.3.1 INVALID OR UNSUPPORTED DATA

If the device receives unsupported data, the preferred response, as mentioned in the PMBus literature, is that the device can call the Content_Fault2() function, which shall:

- Set the CML bit in the STATUS_BYTE - Set the Invalid Or Unsupported Data Received bit in the STATUS_CML regis-

terThis function is already declared and defined for the user. Note that the stack makes no assumptions about the content of the data bytes of a command and, thus, it will process such a command that triggers this kind of Fault, leaving the responsibility of checking the data bytes to the user.

6.2.3.2 DATA OUT OF RANGE FAULT

The PMBus literature specifies that it is optional for a device to detect an attempt to set a parameter to a value that the device cannot realize. How a device knows that a value is out of range is left to the discretion of the device manufacturer. If the device does support detecting data that is out of the range of the device, it can call the Content_Fault2() function, which shall:

- Set the CML bit in the STATUS_BYTE- Set the Invalid Or Unsupported Data Received bit in the STATUS_CML regis-

terThis function is already declared and defined for the user. Note that the stack makes no assumptions about the content of the data bytes of a command and thus, it will process such a command that triggers this kind of Fault, leaving the responsibility of checking the data bytes to the user.



6.2.4 Warning and Fault Reporting by the Main Application The procedure of detecting and reporting warnings and Faults related to the operation of the device is split into two parts:

- setting the Fault and warning thresholds - setting the response to a detected Fault condition

Thus, we can say that the slave can detect warnings or Faults through a set of commands that define the thresholds and can take an action based on other commands received from the host that define the automatic response to these warnings/Faults. An interesting aspect worth mentioning here is that PMBus defines a group of three commands for almost all important operating parameters. These commands define, separately:• the warning threshold and the actions taken in this case• the Fault threshold (just the threshold with no other actions)• the response to a Fault conditionAn example is the VIN_UV parameter. The protocol defines these three commands just for this parameter: • VIN_UV_WARN_LIMIT

• VIN_UV_FAULT_LIMIT

• VIN_UV_FAULT_RESPONSE

Because warnings and Faults related to operation parameters are to be treated distinctively by the main application, they are going to be presented one at a time.

6.2.5 Setting the Warning Thresholds – Reacting to WarningsWhen a warning condition related to the operation of the device is detected, the device must react, meaning that it has to take measures regarding the respective parameter and it has to notify the host. Because of its communication interface with the host, the PMBus stack allows only the polling method, the device must set the appropriate STATUS registers bits.This means that notifying the host through the pooling method is executed by calling functions or routines that do the job of modifying the STATUS registers. In Appendix D. “PEC Byte Calculation” there are examples of how to compose such functions, that are defined by the user and are called from the main application. Let us now refer to the operation parameter mentioned before, the VIN_UV. This is a notion associated with the undervoltage threshold for the input voltage. As we’ve seen, the PMBus protocol defines three commands for this parameter. From this pack of three commands, only one is strictly related to the warning condition, thus, to the warning threshold for the undervoltage parameter. This would be the VIN_UV_WARN_LIMIT command. This PMBus command sets the value of the input voltage that causes an input voltage low warning. This value is typically greater than the input undervoltage Fault threshold, set by the command, VIN_UV_FAULT_LIMIT. In response to the VIN_UV_WARN_LIMIT being exceeded, the device shall perform the following actions:

- Set the OTHER bit in the STATUS_BYTE- Set the INPUT bit in the upper byte of the STATUS_WORD - Set the VIN undervoltage warning bit in the STATUS_INPUT register- Notify the host



Due to the polling nature of the process of notifying the host, the action number 4 is implied by the previous 1-3 actions, which set the bits in the corresponding STATUS registers, thus, accomplishing the task of reporting the Fault to the host by the polling method.The VIN_UV_WARN_LIMIT defines the input low-voltage threshold, thus when this is crossed, the main application must call a user-defined function that performs the above-described actions.As we have seen in this example for this parameter, the input voltage low, the protocol has defined a command that sets the threshold and mentions actions to be taken in case this threshold is crossed. Examples about coding functions that deal with warning conditions for the operating parameters can be found in Appendix D. “PEC Byte Calculation”.

6.2.6 Setting the Warning Thresholds – Reacting to FaultsAs mentioned before, the PMBus groups together packs of three commands for each cooperating parameter. From this pack, two commands deal with the Fault conditions related to the respective parameter.Taking the example above, the input voltage low parameter, the PMBus protocol comes with two functions that are meant to cover any Fault condition in case of an undervolt-age for the input voltage:- VIN_UV_FAULT_LIMIT

- VIN_UV_FAULT_RESPONSE

First of all, the user is required to code functions for each of these commands. Appendix D. “PEC Byte Calculation” contains examples about this. The meaning of the first command is actually pretty straightforward. It allows the host to instruct the slave device about the value of the threshold for which a Fault related to the input low voltage is detected. The main application gets this value which is passed by the stack and sets the threshold. The second command brings up a facility of the PMBus protocol regarding the response to a Fault condition related to an operating parameter. The PMBus defines the automatic response to Faults related to voltage, current, temperature and ton_max. These automatic responses are also set through commands. An example regarding such commands is the following: VIN_UV_FAULT_RESPONSE, IIN_OC_FAULT_RESPONSE, POUT_OP_FAULT_RESPONSE, etc. The full list of such commands can be found in the PMBus Specification, Chapter 15.As we can see, the second command, VIN_UV_FAULT_RESPONSE, is a member of this group of commands that set the response to such Faults. The host utilizes this command to instruct the slave device about the action it should take if a Fault is detected. The slave’s firmwire must have the means to decode what the host is trying to instruct the device through this command. The tables containing the data bytes that specify the response to Faults related to voltage, current, temperature and ton_max can be found in the PMBus Specification, Chapter 10.5.1.The user must come up with a function/routine that does the decoding of the data byte received from the host, so that the main application can be aware of what it is supposed to do in case the Fault threshold for the input low voltage is crossed.Also, in this case, the PMBus specifies that the slave device must perform some additional actions, similar to those when the warning threshold is crossed. These actions imply modifying several bits in the STATUS registers and notifying the host. As with the warning condition, notifying the host is already performed by modifying the STATUS registers, as the stack permits only the “polling” method. The actions specified by the protocol in case of a Fault condition related to the input low voltage parameter, given here as an example, can be found in the PMBus Specification, Chapter 15.28.



To summarize, the way in which the input low-voltage parameter is handled by the application is shown in Figure 6-3:

FIGURE 6-3: VIN_UV THRESHOLDS RESPONSES

VIN_UV

t

Warning threshold

Fault threshold

VIN_UV_WARN_LIMIT command and modifies the STATUS registers

Application detects the warning threshold set by the

App detects the fault limit set by the FAULT_LIMIT command.The application reacts according to the VIN_UV_FAULT_RESPONSE

command and, in addition, modifies the STATUS registers.



Chapter 7. User Data Needed for the Stack’s Functionality

The stack works in strict coordination with the main user application. Due to the fact that the set of commands supported by the main application can vary a lot, and that several commands need special handling, the user must define in advance a set of guiding traces for the stack to follow. Most of these guidelines are represented by labels defined by the user, but there are several other modes of functionality of the stack that need more action from the user. The user is required to declare a set of labels and to define a set of variables needed for the stack’s functionality. The next paragraphs will cover the aspects of the stack Functional mode that come in direct contact with information provided by the user. Appendix A contains the entire set of variables and labels that the user is required to be aware of and possibly modify. To have a starting point, the stack comes with a pre-defined set of commands and proper labels. All the user is required to do is extend this set of commands and add code to the application’s functions.Below is a list of steps the user is required to do in order to create the data needed for the stack’s functionality:

- define/modify the list of labels and variables enumerated in Appendix A. “List of Labels to Be Defined by the User”

- build the table of commands- define a list of functions that can be called from the stack

Next, we will go through this list of steps one at a time.

7.1 STACK’S LIST OF LABELS AND VARIABLES DEFINED BY THE USERThis list contains information such as: the slave address, the maximum size of the buffer, the PMBus communication protocols and so on. The complete enumeration can be found in Appendix A. “List of Labels to Be Defined by the User”. Please note that the stack comes with a pre-defined set of labels and variables, which the user may modify according to his needs.

7.2 BUILDING THE COMMAND TABLE This section describes how the set of commands is built and encoded in the applica-tion. The stack acts as a communication interface between the host and the slave device, thus, it has to be aware of the set of commands supported by the slave. Each command is characterized by a number of five attributes. These attributes are grouped together as members of a structure. Thus, each command has a structure associated with it and all the structures derived from the set of supported commands are grouped in an array. The size of this array of constant structures will be equal to the maximum number of commands supported by the application. Example 7-1 illustrates how a command’s structure is defined:



EXAMPLE 7-1: A COMMAND’S STRUCTURE

A new type of data has been created and each command in the list will be of this type. We don’t have to declare and initialize such a structure for each command supported, because all commands will be defined in the array of structures anyway. How to initialize a structure for VOUT_MAX command in the array is shown in Example 7-2.

EXAMPLE 7-2: VOUT_MAX COMMAND INITIALIZED

The stack will use the values of the members of this structure to check the PMBus transaction related to this command. Here is how each member is used by the stack in a transaction:

- The RW_Word PMBUS protocol has to be respected for any PMBus transac-tion related to this command, otherwise the stack will declare a Fault.

- The stack will declare a Fault if the number of bytes the host sends to the device exceeds the maximum specified value, which is 2 bytes in this case.

- The stack will declare a Fault if the number of bytes the host reads from the device exceeds the maximum specified value, which is 2 bytes in this case.

- *ptrCommandData is a pointer to the command’s data (another array).- func_support: the host checks this constant variable to see if it is supposed

to call an application function that can handle this command. The user must initialize this variable with a value equal to the command code if the main application handles this command, and with the value 0x0 if otherwise. In this case, the VOUT_MAX command is supported by the stack, thus, the value is VOUT_MAX_COMMAND (label associated with the command code).

This is how a command can be initialized in the big array of structures associated with the set of commands. Please note that the array can have any size the user wants, depending on the number of commands supported by the application. From the stack point of view, this detail has relevance only from the access to the array point of view, as we will see next. Some examples and explanations about how the table of commands is built can be found in Appendix A. “List of Labels to Be Defined by the User”.

struct command{

char protocol; //PMBus protocol

unsigned char nr_bytes_wr; //max nr of bytes written

unsigned char nr_bytes_rd; //max nr of bytes read

unsigned char * ptrCommandData; //pointer to command’s data

unsigned char func_support; //application function support

} ;

{RW_Word,0x2,0x2, VOUT_MAX, VOUT_MAX_COMMAND }


User Data Needed for the Stack’s Functionality

7.3 APPLICATION FUNCTION CALLED BY THE STACK The stack must interact with the main application in the process of passing data from and to the host. This interaction happens with a write transaction when a Stop condition is received, and with the Block Write/Block Read Process Call protocol.When a write protocol has reached the Stop condition and no errors were discovered along the transaction, the stack checks the array of structures for the value of the func_support member. If this member has a value equal to the current command code, then the stack acknowledges the fact that this is a command that the main application chose to process. Therefore, the stack calls a user-defined application, APP_FUNC, with the code of the command as parameter.This application function will then handle the command by doing a specific action or by processing its data bytes that are in the buffer. If these data bytes are correct and their content does not trigger a Fault, APP_FUNC will otherwise set the stack flag, ready_to_copy. If, for example, the invalid or unsupported data Fault is detected, APP_FUNC resets the stack flag, ready_to_copy. Why is this important? Because in the main loop of the program there is an “if” condition which checks this stack flag and may or may not call a function, which copies the content of the buffer into the command’s RAM locations. Below is a simplified flowchart of how the stack may or may not call the APP_FUNC when a Stop condition is present.

FIGURE 7-1: STOP STATE FLOWCHART

Example 7-3 shows an application function that the main application could call when the CLEAR_FAULTS command is received and the application decides it should process this command.

Stop

Errors found?

Cmd supportedby APP?

CallAPP_FUNC (Cmd_Code)

Set/ResetReady_to_copy flag

End

YESNO

NO YES



EXAMPLE 7-3: CLEAR FAULTS COMMANDS

Another case in which the stack calls an application function takes place when a Block Write/Block Read Process Call protocol reaches STATE 4, Master Reads Address (MRA), in the stacks flow. Because the stack is required at this particular moment to put data on the bus, it must call first the same user-defined command_handler function. The latter will process the data bytes from the buffer and put them in the RAM locations of the current command.This case’s flows resembles the previous one, except for the fact that the stack does not check anymore if an application function may be called for this command. This is due to the presumption that, if the command was processed up to this point, then the main application must offer support for processing the data bytes received so far and for preparing the bytes that the host is expecting.A simplified flowchart about the manner in which the stack handles a Block Write/Block Read Process Call in the MRA state is shown in Figure 7-2. This protocol is used by commands like COEFFICIENTS and QUERY.

void Clear_faults(void){

STATUS_WORD[0]=0;//STATUS_BYTE is here

STATUS_WORD[1]=0;

STATUS_VOUT[0]=0;

STATUS_IOUT[0]=0;

STATUS_INPUT[0]=0;

STATUS_TEMP[0]=0;

STATUS_CML[0]=0;

STATUS_OTHER[0]=0;

STATUS_FAN_1_2[0]=0;

STATUS_FAN_3_4[0]=0;

}


User Data Needed for the Stack’s Functionality

FIGURE 7-2: BLOCK WRITE/BLOCK READ PROCESS CALL HANDLING FLOWCHART

Note in the above flowchart that the stack checks first whether there were errors in the write portion of this PMBus protocol. If so, then the read portion is very much simplified, the stack just sending bytes with the 0FFh value back to the host.However, if there no errors encountered before or during this transaction, the stack calls a APP_FUNC that is required to handle the bytes received so far and put the new values to be sent back into the command’s RAM. Again, the command code is the parameter of this called function.A common sense question would be whether the stack might just call the same application function in both cases described above (when a Stop condition is received and the main application supports handling the command whose transaction has just finished, or when a Block Write/Block Read Process Call PMBus protocol reaches a state that requires an action from the main application). The answer depends on the user’s choice of implementation of the application. The application may use the same function or two different ones. The only thing that needs to be modified is the name of the function that the stack calls in the stack implementation. By default, the stack calls only one function, APP_FUNC, to trigger an action from the main application in the cases previously described.

Protocol = BW_BR_Proc_al?

NO

YES

NO YESErrors in writeportion?

Send 0FFhCallAPP_uc (cmd_code)

Get data from RAM

End

Continueprocessig



NOTES:



Appendix A. List of Labels to Be Defined by the User

Please note that this information is already defined in the example of the set of commands that comes with the stack. The user may change the values as he sees fit for his application. Bear in mind that the names of the labels and variables are specific to for the stack and any modifications in this aspect must also be extended to the stack.

A.1 LABELS

A.1.1 General Purpose LabelsSLAVE_ADDR – slave’s unique I2C™ addressSLAVE_ADDR_WRITE – slave’s I2C address used for writing protocolsSLAVE_ADDR_READ – slave’s I2C address used for reading protocolsNR_COMMANDS – maximum number of commands in the tableUNSUPPORTED_CMD_CODE – the unsupported command code MAX_BYTES – maximum number of bytes for the bufferMSSP_SSP – select the type of PIC device’s module used by the stack. Value ‘1’ for MSSP, ‘0’ for SSP. Any other value generates a Fault at compile time.

A.1.2 PMBus Protocol LabelsSEND_BYTE

READ_BYTE

WRITE_BYTE

RW_BYTE

READ_WORD

RW_WORD

RW_BLOCK

BW_BR_PROC_CALL

A.1.3 Command Code LabelsOPERATION_COMMAND

ON_OFF_CONFIG_COMMAND

CLEAR_FAULTS_COMMAND

Etc.The list can go on with the whole set of commands supported.

A.2 VARIABLES

A.2.1 General Purpose Labels unsigned char buffer[MAX_BYTES + 1]; – buffer declaration. Uses the label MAX_BYTES.



A.2.2 Declaration of Commands-Related Data (Example of Two Commands)

The data for a command consists of an array with the dimension equal to the maximum number of bytes for that command, read or written. bank1 unsigned char OPERATION[1]; – array defined for the OPERATION com-mand. It is placed in memory Bank 1.bank1 unsigned char ON_OFF_CONFIG[1]; – array defined for the ON_OFF_CONFIG command. It is placed in memory Bank 1.The two examples above are commands that have a maximum number of bytes of 1. Example A-1 illustrates a command that utilizes the BW_BR_PROC_CALL protocol:

EXAMPLE A-1: COEFFICIENTS COMMANDS

This command has 2 bytes to be written to and 5 bytes to be read. Please note that the array size is equal to the number of bytes to be read as this value is greater than that of the bytes written.The list can contain the whole set of commands the user decided to implement. There is no need to declare an array for commands that use the SEND_BYTE protocol, because there are no bytes to be sent, only the command code.

A.3 ARRAY OF STRUCTURES (EXAMPLE OF 5 ELEMENTS)

EXAMPLE A-2: DEFINING AN ARRAY OF FIVE STRUCTURES

The const qualifier is used for this array of structures, as the data will never be modified. Please note that the CLEAR_FAULTS command, which utilizes the SEND_BYTE protocol, does not have a data space reserved (an array associated) because there are no data bytes. The array of structures can be expanded to contain the full set of commands the user needs.

A.4 ARRAY OF INDICESIf the set of commands is not big, meaning the number of commands is equal to or less than 35, then the stack utilizes a function to check in the array of commands for the code that it just received.However, if the number of commands is greater than 35, then another array is needed. This will contain the index of a command in the big array of structures. It has the size 255, meaning it can be used for the whole set of 255 commands, considering that no paging is used. What a portion of this array of indices looks like is shown in Example A-3:

bank1 unsigned char COEFFICIENTS[5];

const command matrix[5] = {

{RW_BYTE, 0x1, 0x1, OPERATION, OPERATION_COMMAND},

{RW_BYTE, 0x1, 0x1, ON_OFF_CONFIG, ON_OFF_CONFIG_COMMAND},

{SEND_BYTE, 0x0, 0x0, 0x0, CLEAR_FAULTS_COMMAND},

{BW_BR_PROC_CALL, 0x1, 0x1, QUERRY, QUERRY_COMMAND},

{RW_BYTE, 0x1, 0x1, VOUT_MODE, VOUT_MODE_COMMAND}

};


List of Labels to Be Defined by the User

EXAMPLE A-3: PORTION OF THE ARRAY OF INDICES

Each member in the array has an index, from 0 to 255, which is the maximum size of the array. Each member corresponds to a PMBus command that is supported or not. The indices of the member of the array are the command codes, supported or not, while the values of the members represent the index in the array of structures for that command.For example, the 0x0 command code (PAGE command) is not supported. This means that the associated member in the array of indices has the value equal to the UNSUPPORTED_CMD_CODE label. The stack, upon receiving this code, 0x0, will check this array of indices and will see that the command is not supported. A member associated with the command code can be found in the array of indices at position ‘1’ which is equal to the command code of the OPERATION command. The value of the member is ‘0’, which is the index in the array of structures where the OPERATION command can be found. When the stack receives the command code ‘1’, it will check the array of indices and retrieve the index in the big array of structures, which is ‘0’ for the OPERATION command.Please note that this array is added at compile time only if the number of commands is less than or equal to 35. The user is supplied with a code that does this automatic check. The declaration of the NR_COMMANDS label is quite useful. Its absence will generate an error message at compile time.

const unsigned char ArrayOfIndices[255] = {

UNSUPPORTED_CMD_CODE,//0x0 cmd code

0, //OPERATION

1, //ON_OFF_CONFIG

2, //CLEAR_FAULTS



};



NOTES:



Appendix B. Testing the Stack

A PMBus master slave combination is required in order to test the stack’s functionality. For this implementation, the stack was tested using the Microchip’s 28-pin Demo Board with the PIC16F886 microcontroller, a PKSA (PICkit™ Serial Analyzer) as a master and a PICkit 2 as a power-up source for the board.The board setup requires pin RA4 (T0CKI) to be tied to pin RC3 (I2C™ SCK line). Figure B-1 illustrates what the system looks like:

FIGURE B-1: TEST SYSTEM FOR THE STACK

The user is required to consult the “PICkit™ Serial Analyzer User's Guide (DS51647)” document in order to familiarize himself with the GUI of the master PKSA. This docu-ment can be found at the following address:http://ww1.microchip.com/downloads/en/DeviceDoc/51647B.pdf


http://ww1.microchip.com/downloads/en/DeviceDoc/51647B.pdf


NOTES:



Appendix C. Defining Functions for Warning and Fault Responses

C.1 WARNINGSThe user has to define functions that can be called from the main application when a warning threshold is crossed, in order to modify the STATUS registers and thus notify the host./********************************************************************

* Function: VOUT_UV_WARN_LIMIT

*

* PreCondition: A warning generated by an undervoltage condition

* for the output voltage

*

* Input: None

*

* Output: None

*

* Side Effects: None

*

* Overview: This function is called by the main application

* to modify the

* corresponding STATUS in case of the precondition

* mentioned above

* Note: None

*******************************************************************/

void VOUT_UV_WARN_LIMIT (void){

STATUS_WORD[0] |= 0x1; //set the “OTHER” bit. Be careful, in //the PMBus

//literature, this bit is mentioned as //“NONE OF THE ABOVE”

STATUS_WORD[1] |= 0x80; // set the “VOUT” bit

STATUS_VOUT[0] |= 0x20; //set the “VOUT Undervoltage Warning bit”

}

Please remember that STATUS_BYTE is identical in terms of content and location to the STATUS_WORD low byte, so it makes no sense in declaring another array just for this command. The command, however, is declared and defined in the array of structures, so the host can read it just like any other Status command.

C.2 FAULTSIn case an operating parameter goes wild and the Fault threshold for it is crossed, the slave must respond to this condition. It has already been instructed by the host through a PARAMETER_NAME_FAULT_RESPONSE, like for example IOUT_OC_FAULT_RESPONSE. But, in addition to the physical response, the slave device must also modify the STATUS registers.



Here is an example of such a function that the main application must use as a response for an overcurrent Fault related to the output current.

EXAMPLE C-1: APPLICATION FUNCTION EXAMPLE

/********************************************************************

* Function: IOUT_OC_FAULT_RESPONSE

*

* PreCondition: A fault generated by an overcurrent condition

* for the output current

*

* Input: None

*

* Output: None

*

* Side Effects: None

*

* Overview: This function is called by the main application to

* modify the corresponding STATUS in case of the

* precondition mentioned above

* Note: None

*******************************************************************/

void IOUT_OC_FAULT_RESPONSE (void){

STATUS_WORD[0] |= 0x1; //set the “OTHER” bit. Be careful, in the PMBus

//literature, this bit is mentioned as “NONE OF //THE ABOVE”

STATUS_WORD[1] |= 0x80; // set the “VOUT” bit

STATUS_VOUT[0] |= 0x20; //set the “VOUT Undervoltage Warning bit”

}

Please remember that STATUS_BYTE is identical in terms of content and location to the STATUS_WORD low byte, therefore it makes no sense in declaring another array just for this command. The command, however, is declared and defined in the array of struc-tures, so the host can read it just like any other Status command.



Appendix D. PEC Byte Calculation

The calculation of the PEC byte depends on the command being issued, and thus on the type of protocol employed. As a rule of thumb, the device that put the last data byte on the bus is also responsible for calculating and appending the PEC byte to the mes-sage. Below is described how this byte is calculated for each type of transaction:

D.1 WRITE TRANSACTIONAs we have found out before, the host is responsible for sending all the bytes in the protocol that qualifies as a write transaction. This means that the host must also calcu-late and send the PEC byte. On the slave side, the stack calculates its own PEC byte for the current protocol. At the end of the transaction, if it receives the PEC byte from the master, the stack checks for a mismatch, a case which triggers a data transmission Fault. Please note that the absence of the PEC byte in a write transaction, which trans-lates into “host sending too few bytes”, does not represent a Fault. Therefore, the data that has been received by the slave without a PEC byte appended is considered valid.

D.2 READ TRANSACTIONBoth the host and the slave have to put data on the bus in a protocol that subscribes to a read transaction. But only the slave must calculate the PEC byte for the entire trans-action and put it on the bus at the end of the transaction. Please note that the host may choose to terminate the transfer without reading the PEC byte. Although this translates into “host reading too few bytes”, this case is not treated as a Fault, presuming that the host knows what it is doing.

D.3 WRITE/READ TRANSACTIONSIn this combined protocol, the slave is required to calculate the PEC byte for the entire message. As mentioned above, the host may choose not to read the CRC-8 error-checking byte and the stack does not treat this as a Fault.



NOTES:



Appendix E. Parsing the Commands Table

Each time a new command code is received, the stack must prepare to get the information related to the current command from the command table. For this to happen, the stack must parse the array of structures and find out what the index of the structure associated to the command in the array is. Because the stack is actually looking for a member of the structure from the big array of structures, this consumes badly the execution time of the microcontroller and might cause the slave device to lose the next packets sent by the host.The most time efficient method is the introducing of a second array. This will be an array of indices of the supported commands in the big array of structures. The size of this array will be equal to the highest value of any supported command code.Here is an example about how this array of indices can be constructed. For this example, it is considered that 0xD0 will be the highest value for any supported command code, so this will be the size of the array. The first column is the list of command codes, while the second column represents the actual definition of the array, which will be filled with the corresponding indices to the array of structures for any supported command code (left column), or with a label that specifies that this is not supported.The user is responsible for defining this array of indices and the label unsupported_cmd_code. This label will replace the index to the array of structures if the command code in the left column is not supported.

As can be observed, the command with the code 0xD0 can be found in the big array of structures at index 0x9A.

TABLE E-1: CONSTRUCTING THE ARRAY OF INDICESCommand code

(list of supported commands)

Index in the array of structures(value of array’s elements) Array[N]

0x0 0x0 Array[0]0x1 Label unsupported_cmd_code Array[1]0x2 0x1 Array[2]0x3 0x2 Array[3]... ... ...... ... ...

0x0 Label unsupported_cmd_code Array[0x9F]... ... ...

0x0 0x9A Array[0xD0]



NOTES:



Appendix F. Buffer Construction

The buffer will contain the data bytes of the Write command being processed, plus some overhead data needed for copying the data bytes to the correspondent RAM locations.

Any write transaction, even group command protocols, is meant to send one command from a host to a device from Start to Stop. Therefore, the buffer will contain data regard-ing a single command at a time. Each time a new transaction begins, the buffer is over-written. It may happen that, due to a Fault, the current transaction might end up interrupted. The buffer will contain unrelated data for the device, but the stack will disregard this information and the main application will not be notified.

TABLE F-1: BUFFER CONSTRUCTIONNumber of data bytes

Data byte 1Data byte 2

………

Data byte N



AMERICASCorporate Office2355 West Chandler Blvd.Chandler, AZ 85224-6199Tel: 480-792-7200 Fax: 480-792-7277Technical Support: http://support.microchip.comWeb Address: www.microchip.comAtlantaDuluth, GA Tel: 678-957-9614 Fax: 678-957-1455BostonWestborough, MA Tel: 774-760-0087 Fax: 774-760-0088ChicagoItasca, IL Tel: 630-285-0071 Fax: 630-285-0075DallasAddison, TX Tel: 972-818-7423 Fax: 972-818-2924DetroitFarmington Hills, MI Tel: 248-538-2250Fax: 248-538-2260KokomoKokomo, IN Tel: 765-864-8360Fax: 765-864-8387Los AngelesMission Viejo, CA Tel: 949-462-9523 Fax: 949-462-9608Santa ClaraSanta Clara, CA Tel: 408-961-6444Fax: 408-961-6445TorontoMississauga, Ontario, CanadaTel: 905-673-0699 Fax: 905-673-6509

ASIA/PACIFICAsia Pacific OfficeSuites 3707-14, 37th FloorTower 6, The GatewayHarbour City, KowloonHong KongTel: 852-2401-1200Fax: 852-2401-3431Australia - SydneyTel: 61-2-9868-6733Fax: 61-2-9868-6755China - BeijingTel: 86-10-8528-2100 Fax: 86-10-8528-2104China - ChengduTel: 86-28-8665-5511Fax: 86-28-8665-7889China - Hong Kong SARTel: 852-2401-1200 Fax: 852-2401-3431China - NanjingTel: 86-25-8473-2460Fax: 86-25-8473-2470China - QingdaoTel: 86-532-8502-7355Fax: 86-532-8502-7205China - ShanghaiTel: 86-21-5407-5533 Fax: 86-21-5407-5066China - ShenyangTel: 86-24-2334-2829Fax: 86-24-2334-2393China - ShenzhenTel: 86-755-8203-2660 Fax: 86-755-8203-1760China - WuhanTel: 86-27-5980-5300Fax: 86-27-5980-5118China - XiamenTel: 86-592-2388138 Fax: 86-592-2388130China - XianTel: 86-29-8833-7252Fax: 86-29-8833-7256China - ZhuhaiTel: 86-756-3210040 Fax: 86-756-3210049

ASIA/PACIFICIndia - BangaloreTel: 91-80-4182-8400 Fax: 91-80-4182-8422India - New DelhiTel: 91-11-4160-8631Fax: 91-11-4160-8632India - PuneTel: 91-20-2566-1512Fax: 91-20-2566-1513Japan - YokohamaTel: 81-45-471- 6166 Fax: 81-45-471-6122Korea - DaeguTel: 82-53-744-4301Fax: 82-53-744-4302Korea - SeoulTel: 82-2-554-7200Fax: 82-2-558-5932 or 82-2-558-5934Malaysia - Kuala LumpurTel: 60-3-6201-9857Fax: 60-3-6201-9859Malaysia - PenangTel: 60-4-227-8870Fax: 60-4-227-4068Philippines - ManilaTel: 63-2-634-9065Fax: 63-2-634-9069SingaporeTel: 65-6334-8870Fax: 65-6334-8850Taiwan - Hsin ChuTel: 886-3-572-9526Fax: 886-3-572-6459Taiwan - KaohsiungTel: 886-7-536-4818Fax: 886-7-536-4803Taiwan - TaipeiTel: 886-2-2500-6610 Fax: 886-2-2508-0102Thailand - BangkokTel: 66-2-694-1351Fax: 66-2-694-1350

EUROPEAustria - WelsTel: 43-7242-2244-39Fax: 43-7242-2244-393Denmark - CopenhagenTel: 45-4450-2828 Fax: 45-4485-2829France - ParisTel: 33-1-69-53-63-20 Fax: 33-1-69-30-90-79Germany - MunichTel: 49-89-627-144-0 Fax: 49-89-627-144-44Italy - Milan Tel: 39-0331-742611 Fax: 39-0331-466781Netherlands - DrunenTel: 31-416-690399 Fax: 31-416-690340Spain - MadridTel: 34-91-708-08-90Fax: 34-91-708-08-91UK - WokinghamTel: 44-118-921-5869Fax: 44-118-921-5820

WORLDWIDE SALES AND SERVICE

01/02/08