Promira eSPI Analysis User Manual v1.10.000

1 Revision History

Top

1.1 Changes in version 1.10

Added eSPI advanced/simple match triggers, hardware filters, and hardware statistics features.

Fixed Pin Description Table typo. IO1 signal is pin 5, and IO0 signal is pin 5.

Top

1.2 Changes in version 1.00

Initial revision.

2 General Overview

The Promira Serial Platform with eSPI Analysis Application non-intrusively monitors eSPI bus at up to 66 MHz bit rate in single, dual and quad IO modes. The Promira platform with eSPI analysis application supports two CS signals, two Reset signals, two Alert signals, and 11 Digital IO signals. The Promira platform connects to an analysis computer via Ethernet or Ethernet over USB. The application installed on the Promira platform is field-upgradeable and future-proof.

Top

2.1 eSPI Background

2.1.1 eSPI Overview

The Enhanced Serial Peripheral Interface (eSPI) bus interface is used for both client and server platforms. The devices that can be supported over the eSPI interface includes but not necessary limited to Embedded Controller (EC), Baseboard Management Controller (BMC), Super-I/O (SIO) and Port-80 debug card.

The eSPI has been specified by Intel as a replacement for the existing Intel Low Pin Count (LPC) interface on current server and client platforms. LPC bus is a legacy bus developed as the replacement for Industry Standard Architecture (ISA) bus. Some LPC bus limitations, which led to the development of eSPI, are:

• LPC requires up to 13 pins, of which 7 are required and 6 are optional.
• Current LPC implementations include a fabrication process cost burden as it is based on 3.3V IO signaling technology.
• The LPC bus clock frequency is fixed at 33 MHz that fixed the bandwidth at 133 Mbps.
• The LPC has a significant number of sideband signals.

The eSPI specification provides a path for migrating LPC devices over to the new eSPI interface. eSPI reuses the timing and electrical specification of Serial Peripheral Interface (SPI), but with a different protocol to meet a set of different requirements.

Top

Comparing eSPI and SPI

Figure 1 : Intel eSPI

Figure 2 : Motorola SPI

2.1.2 eSPI Architecture

Top

eSPI Topology

The Enhanced Serial Peripheral Interface (eSPI) operates in master/slave mode of operation where the eSPI master dictates the flow of command and data between itself and the eSPI slaves by controlling the Chip Select# pins for each of the eSPI slaves. At any one time, the eSPI master must ensure that only one of the Chip Select# pins is asserted based on source decode, thus allowing transactions to flow between the eSPI master and the corresponding eSPI slave associated with the Chip Select# pin. The eSPI master is the only component that is allowed to drive Chip Select# when eSPI Reset# is de-asserted. For an eSPI bus, there is only one eSPI master and one or more eSPI slaves.

In Single Master - Single Slave configuration, a single eSPI master will be connected to a single eSPI slave. In one configuration, the eSPI slave could be the device that generates the eSPI Reset#. In this case, the eSPI Reset# is driven from eSPI slave to eSPI master. In other configuration, the eSPI Reset# could be generated by the eSPI master and thus, it is driven from eSPI master to eSPI slave.

Multiple SPI and eSPI slaves could be connected to the same eSPI bus interface in a multi-drop Single Master - Multiple Slaves configuration. The number of devices that can be supported over a single eSPI bus interface is limited by bus loading and signals trace length. In this configuration, the clock and data pins are shared by multiple SPI and eSPI slaves. Each of the slaves has its dedicated Chip Select# and Alert# pins.

In an eSPI bus configuration with multiple slaves present, the eSPI master may support 2 eSPI Reset# pins, one from eSPI slave to eSPI master and another one from eSPI master to eSPI slaves. In this case, the master's eSPI interface will only be reset if all the slaves' eSPI interfaces are reset.

SPI slaves such as Flash and defined TPM are allowed to share the same set of clock and data pins with eSPI slaves. These non-eSPI slaves are selected using the dedicated Chip Select# pins and they communicate with the eSPI master through SPI specific protocols run over the eSPI bus.

Top

eSPI Architecture Description

In a Single Master - Single Slave configuration, there could be multiple eSPI host bridges within a single eSPI master and there could be multiple eSPI endpoints within a single eSPI slave. When Chip Select# corresponding to the eSPI slave is asserted, command and data transfer happens between the eSPI master and eSPI slave, which could be a result of the eSPI host bridge and eSPI endpoint communications. Each of the eSPI host bridges communicates with its corresponding eSPI endpoint through dedicated channel. The use of channels allows multiple independent flows of command and data to be transferred over the same bus between the eSPI master and eSPI slave with no ordering requirement.

In Single Master - Multiple Slaves configuration multiple discrete eSPI slaves can be dropped onto the eSPI bus. Each of the eSPI slaves should have a dedicated Chip Select# pin. On the master side, there are eSPI host bridges corresponding to each of the discrete slaves respectively, each driving the Chip Select# pin of the corresponding discrete slave. At any one time, only one of the Chip Select# pins can be asserted. Command and data transfer can then happen between the eSPI host bridge and the corresponding eSPI slave.

Figure 3 : Single Master - Single Slave

Figure 4 : Single Master - Multi Slave

2.1.3 eSPI Operations Theory

The Serial Clock must be low at the assertion edge of the Chip Select# (CS#) while eSPI Reset# has been de-asserted. The first data is launched from master while the serial clock is still low and sampled on the first rising edge of the clock by slave. Subsequent data is launched on the falling edge of the clock from master and sampled on the rising edge of the clock by slave. The data is launched from slave on the falling edge of the clock. The master could implement a more flexible sampling scheme since it controls the clock. All transactions on eSPI must be in multiple of 8-bits (one Byte).

eSPI master and eSPI slaves must tri-state the interface pins when their respective eSPI Reset# is asserted. The Chip Select#, I/O[n:0] and Alert# pins require weak pull-up to be enabled on these pins whereas the Serial Clock requires a weak pull-down. The weak pull-up/pull-down should be implemented either as an integral part of the eSPI master buffer or on the board.

After eSPI Reset# is deasserted on the eSPI master, the eSPI master begins driving Chip Select# and Serial Clock pins to their idle state appropriately. The weak pull-up on the Chip Select# and the weak pull-down on the Serial Clock are allowed to be disabled after the eSPI Reset# deassertion. However, I/O[n:0] and Alert# pins continue to have the weak pull-up enabled for the proper operation of the eSPI bus.

Figure 5 : eSPI Operation

An eSPI transaction consists of a Command phase driven by master, a Turn-Around (TAR) phase, and a Response phase driven by the slave. CRC generation is mandatory for all eSPI transactions where CRC byte is always transmitted on the bus. A transaction is initiated by the master by asserting the Chip Select#, starting the clock and driving the command onto the data bus. The clock remains toggling until the complete response phase has been received from the slaves.

Top

Command Phase

The Command phase is used by the eSPI master to initiate a transaction to the slave or in response to an Alert event by the slave. It consists of a CMD, an optional header (HDR), optional DATA and a CRC. The Command Opcode is 8-bits wide.

Top

Turn-Around (TAR) Phase

After the last bit of the Command Phase has been sent out on the data lines, the data lines enter the Turn-Around window. The eSPI master is required to drive all the data lines to logic '1' for the first clock of the Turn-Around window and tri-state the data lines thereafter. The number of clocks for the Turn-Around window is a fixed 2 serial clocks independent of the eSPI I/O Mode (single, dual or quad I/O).

Top

Response Phase

The Response phase is driven by the eSPI slave in response to command initiated by an eSPI master. It consists of a RSP opcode, an optional header (HDR), optional data, STATUS (STS) and CRC. The RSP opcode is a 8-bit field consists of a Response Code and a Response Modifier.

Top

Slave-initiated transactions

A transaction can be initiated by the slave by first signaling an Alert event to the master. The Alert event can be signaled in two ways. In the Single Master - Single Slave configuration, the I/O[1] pin could be used by the slave to indicate an Alert event. In the Single Master - Multiple Slaves configuration, a dedicated Alert# pin is required.

The Alert event can only be signaled by the slave when the Chip Select# is high. The pin, either IO[1] or Alert# is toggled from tri-state to pulled low by the slave when it decides to request for service. The slave then holds the state of the pin until the Chip Select# is asserted by the master. Once the Chip Select# is asserted, the eSPI slave must release the ownership of the pin by tri-stating the pin and the pin will be pulled high by the weak pull-up. The master then continues to issue command to figure out the cause of the Alert event from the device and then service the request.

At the last falling edge of the serial clock after CRC is sent, the eSPI slave must drive I/O[n:0] and Alert# pins to high until Chip Select# is deasserted. After Chip Select# deassertion, these pins are tri-stated by the slave, where the weak pull-ups maintain these pins at high.

Figure 6 : Slave Triggered Transaction (Single Slave)

Figure 7 : Slave Triggered Transaction (Multiple Slaves)

Top

Channels

A channel provides a means to allow multiple independent flows of traffic to share the same physical bus. Each set of the put_*/get_*/*_avail/*_free associates with the command and response of a corresponding channel. Each of the channels has its dedicated resources such as queue and flow control. There is no ordering requirement between traffic from different channels.

The number and types of channels supported by a particular eSPI slave is discovered through the GET_CONFIGURATION command issued by the eSPI master to the eSPI slave during initialization. The assignment of the channel type to the channel number is fixed. The eSPI slave can only advertise which of the channels are supported.

There are four different channels types.

• Peripheral Channel: eSPI Peripheral channel is used for communication between eSPI host bridge located on the master side and eSPI endpoints located on the slave side. LPC Host and LPC Peripherals are an example of eSPI host bridge and eSPI endpoints respectively.
• Virtual Wire Channel: The Virtual Wire channel is used to communicate the state of sideband pins or GPIO tunneled through eSPI as in-band messages. Serial IRQ interrupts are communicated through this channel as in-band messages.
• OOB Channel: The SMBus packets are tunneled through eSPI as Out-Of-Band (OOB) messages. The whole SMBus packet is embedded inside the eSPI OOB message as data.
• Flash Access Channel: The Flash Access channel provides a path allowing the flash components to be shared run-time between chipset and the eSPI slaves that require flash accesses such as EC and BMC.

Top

Link Layer

All masters and slaves support Single I/O mode of operation. Support for Dual I/O and Quad I/O mode of operation is advertised by the slave through the General Capabilities and Configurations register.

By default coming out of eSPI Reset#, both master and slave operate in Single I/O mode. The mode of operation can be changed by the master using the SET_CONFIGURATION command. The SET_CONFIGURATION is completed with the current mode of operation. The new mode of operation will only take effect at the deassertion edge of the Chip Select#.

Each of the fields for an eSPI transaction is shifted out accordingly in a defined order. For fields that contain multiple bytes, the order of the bytes being shifted out on the eSPI bus is as follows (LSB = Least Significant Byte, MSB = Most Significant Byte):

• Header:
• Length: From MSB (with Tag field) to LSB
• Address: From MSB to LSB. This applies to eSPI transactions with address including GET_CONFIGURATION and SET_CONFIGURATION.
• Data: From LSB to MSB
• Status: From LSB to MSB

Each of the bytes is shifted from the most significant bit (bit[7]) to the least significant bit (bit[0]). An example of a master initiated peripheral channel memory read is as shown below.

Single IO mode

In Single I/O mode, I/O[1:0] pins are uni-directional. eSPI master drives the I/O[0] during command phase, and response from slave is driven on the I/O[1].

Figure 8 : Single I/O Mode

Dual IO mode

In Dual I/O mode, I/O[1:0] pins become bi-directional to form the bi-directional data bus and all the command and response phases are transferred over the two bi-directional pins at the same time, effectively doubling the transfer rate of the Single I/O mode.

Figure 9 : Dual I/O Mode

Quad IO mode

In Quad I/O mode, I/O[3:0] pins are bi-directional data bus and all the command and response phases are transferred over the four bi-directional pins at the same time, effectively doubling the transfer rate of the Dual I/O mode.

Figure 10 : Quad I/O Mode

2.1.4 eSPI References

• eSPI – Intel Enhanced Serial Peripheral Interface Specification
• LPC – Intel Low Pin Count Specification
• SPI – Wikipedia Serial Peripheral Interface Description

3 Hardware Specification

Top

3.1 Pinout

3.1.1 Connector Specification

The Promira Serial Platform with eSPI Analysis Application target connector is a standard 2x17 IDC male type connector 0.079x0.0792″ (2x2 mm). The Promira platform target connector allows for up to a 34-pin ribbon cable and connector.

One 34-34 cable is provided with the Promira platform: A standard ribbon cable 0.0392″ (1 mm) pitch that is 5.122″ (130mm) long with two 2x17 IDC female 2x2mm (0.079x0.079) connectors. This provided target ribbon cable will mate with a standard keyed boxed header.

3.1.2 Orientation

The pin order of the 2x17 IDC female connector in the provided target ribbon 34-34 cable is described in figure 11. When looking at the Promira platform front position with the 34-34 ribbon cable (figure 11), pin 1 is in the top left corner and pin 34 is in the bottom right corner.

Figure 11 : Promira platform front position with 34-34 cable

3.1.3 Pin Description

Note:

(1) When the Promira platform monitors a system that does not use any or all of the following signals: Pin 3 - Alert1, Pin 14 - CS1, and Pin 31 Reset1, it is strongly recommended that these signals are left as No Connect (NC). If that is not possible, any connected unused pins are required to have a logic level of 1 at all times.

Top

3.2 LEDs

LED2 (the middle LED in the Promira platform upper side) is blinking red, when the Promira platform data capture is active.

Top

3.3 Speeds

The Promira platform with eSPI analysis application is capable of monitoring the eSPI bus at bit rates 20, 25, 33, 50 and 66 MHz in single, dual, quad IO modes.

Top

3.4 Digital I/O

Promira platform digital inputs allow users to synchronize external logic with the analyzed eSPI data stream. When the state of an enabled digital input changes, an event is sent to the analysis PC. Digital input may not oscillate at a rate faster than 10 MHz. If digital input oscillates at a rate faster 10 MHz, then the events may not be passed to the PC. Digital inputs are rated for 1.8 V.

Promira platform digital outputs allow users to output events to external devices, such as an oscilloscope or logic analyzer, especially to trigger the oscilloscope to capture data. The digital outputs are rated to 1.8 V and 10 mA.

Top

3.5 On-board Buffer

The Promira platform with eSPI analysis application contains a 64 MB on-board buffer. The memory provides a temporary FIFO storage buffer for capture data. This buffer serves two capture when the analysis computer can not stream the data off the analyzer fast enough. It is also used during a delayed-download capture to store all of the captured data.

4 Device Operation

Promira platform monitors the eSPI signals including: four IO signals, one SCK signal, two CS signals, two Alert signals, and two Reset signals.

eSPI specification requires that the master and slaves start communicating in single IO mode at 20 MHz on power-up and later on, the master configures the operating mode based on the slaves capabilities. This is done by sending a SET_CONFIGURATION command to the slaves 'General Capabilities Register' (offset 0x0008) with the desired IO mode/Alert pin mode/frequency setting. Promira platform captures and remembers the IO mode and Alert pin mode when it recognizes a SET_CONFIGURATION command in offset 0x0008 to a slave. This is automatic as long as the Promira platform captures all traffic from the beginning which is the recommended usage mode. Alternately, eSPI IO mode can also be configured by the user to Single/Dual/Quad. eSPI Alert mode can be configured by the user to IO1 signal or Alert0 signal.

Top

4.1 Capture Mode

Promira platform has two main capture modes: standard capture mode and delayed-download capture mode.

• In standard capture mode the capture data is streamed out from the Promira platform to the analysis computer immediately.
• In delayed-download capture mode, the capture data is not streamed out from the Promira platform to the analysis computer until after the analyzer has stopped monitoring the bus. When the captured is stopped, all the captured data is streamed from the analyzer to the analysis computer.

Top

4.2 General Device Features

Promira platform supports multiple monitoring, decoding, and reporting capabilities including:

• Monitors and decodes packets at eSPI protocol level and distinguish between command phase and response phase while reporting the packet to the user.
• Monitors SET_CONFIGURATION command to 'General Capabilities Register' and automatically remember the frequency of operation and IO mode configured by the master and reports it for every packet seen on the bus.
• Monitors SET_CONFIGURATION command to 'General Capabilities Register' and automatically remember Alert mode setting and appropriately monitors IO1 signal or Alert-0/Alert-1 signals (which is applicable only in a single master - single slave setting).
• Monitors SET_CONFIGURATION command to 'Channel Capabilities Registers' and automatically remember the master configurable fields (for example maximum payload request and maximum payload size for peripheral channel transactions).
• Monitors the status field returned in every response and remember the queues' availability status for all channels.
• Decodes commands based on channels and reports the information to the user for every packet.
• Reports correct/incorrect command phase and response phase CRC errors for every packet to the user.
• Reports Master side errors and Slave side errors.
• Resets the captured IO mode and frequency of operation on a reset toggle on the signal.

Top

4.3 Digital IO

The Promira platform has 11 digital IO signals that can be configured by the user to input or output. Digital inputs provide a means to users to insert events into the data stream. Digital outputs provide a means for users to match certain events and to send output to other devices, such as oscilloscopes. In this way, users can synchronize events on the bus with other signals they may be measuring. Digital input event (failing edge or rising edge) can trigger a capture. Digital output behavior can be configured to: set low, set high, toggle (initially low), and toggle (initially high).

Digital input event can trigger a capture, and capture event can toggle digital output on the following scenarios:

• Packet with a command field that matches an 8-bit value set by the user.
• Packet with a command field that does not match an 8-bit value set by the user.
• Peripheral channel transaction.
• Virtual wire channel transaction.
• OOB channel transaction.
• Flash channel transaction.
• Get Configuration command.
• Set Configuration command.
• Get Status command.
• Platform Reset command.
• Alert event on the eSPI bus.
• Reset event on the eSPI bus.

Top

4.4 Match/Action System

The Promira platform features a multi-tiered matching/action system that can perform one or more actions in response to a match/action.

The first level is simple matching which can match the occurrence of packet types by channel, user selected command value and events and trigger a capture and/or assert an external output pin in response.

The second level is advanced matching which provides three different options that are explained below. On a match the system can trigger a capture and/or assert an external output pin in response.

The third level is hardware filters which provides mechanism to filter out packets.

Simple match and advanced match are separates features. The user can select simple match feature or advanced match feature but not both features at the same time.

4.4.1 eSPI Simple Match

Simple match can trigger a capture, and capture event can toggle a digital output pin on the following scenarios:

• Packet with a command field that matches an 8-bit value set by the user.
• Packet with a command field that does not match an 8-bit value set by the user.
• Peripheral channel transaction.
• Virtual wire channel transaction.
• OOB channel transaction.
• Flash channel transaction.
• Independent Channel Transaction
• Alert event on the eSPI bus.
• Reset event on the eSPI bus.

It is possible to select multiple events to match the simple trigger. However, since a capture can only be triggered once, in the case of multiple selected events, the first of any of the selected events will trigger the capture.

When an ouput pin is selcted to be asserted on a match, the pin will be asserted only once, when the trigger occurs.

4.4.2 eSPI Advanced Match

The Promira eSPI advanced trigger is a complex pattern/sequence match engine that provides triggering on specific condition/sequence of events on the eSPI bus with multiple options and a high level of configurability specifically tailored around the eSPI protocol.

Using the advanced match feature, the user can specify and configure the analyzer to match and trigger on three different types of conditions/sequences based on eSPI packets.

Match/Trigger Option 1 - Multiple Packets

Configure the analyzer to match and trigger on a sequence of up to four eSPI packets (each packet is defined as a level). The match condition can be different for each level. An output trigger pin can be configured to be drive logic high or low (selectable) for each level when an eSPI packet satisfies that level's match condition.

Match/Trigger Option 2 - Non-Posted Transactions

Configure the analyzer to match and trigger on a specific non-posted transaction and corresponding completion(s). A non-posted transaction has two distinct phases, a request phase and one or more completion phases. Completions can be successful/unsuccessful, and connected or split across multiple completion packets. In the case of split completions the analyzer will track first, middle, last (only) completions as defined in the eSPI specification. An output trigger pin can be configured to be drive logic high or low (selectable) at different stages of the request/completion sequence as they occur on the wire. The four distinct stages are 1- Request, 2-First completion, 3-Middle completion (the first packet in case there are multiple middle completion packets), and 4-Last (Only) completion. Please note that the user only needs to configure the analyzer to match a specific non-posted request and the type of completion to look for (successful/unsuccessful); the analyzer tracks the completion(s) for the request automatically.

Match/Trigger Option 3 - Errors

Configure the analyzer to match and trigger on a packet that has an error code in its status as defined in Table 30

4.4.3 eSPI Hardware filters

The eSPI hardware filter feature provides mechanism to filter out packets (which are listed below) in order to discard unwanted data, and reduce the amount of captured data that is sent back to the analysis computer. The settings can be configured independently for each slave.

• Packet with a command field that matches an 8-bit value set by the user.
• Packet with a command field that does not match an 8-bit value set by the user.
• Peripheral channel transaction.
• Virtual wire channel transaction.
• OOB channel transaction.
• Flash channel transaction.
• Independent Channel Transaction

Top

4.5 Hardware Statistics

The Promira platform features hardware statistics which provides a count of packets / events for each slave. The following counters are available:

• Packets with command CRC error.
• Packets with response CRC error.
• Peripheral channel packets.
• Virtual wire channel packets.
• OOB channel packets.
• Flash channel packets.
• Get Configuration packets.
• Set Configuration packets.
• Get Status packets.
• Platform Resets.
• All packets that were filtered out
• All packets that were filtered out based on command

5 Software

Top

5.1 Rosetta Language Bindings: API Integration into Custom Applications

5.1.1 Overview

The Promira Rosetta language bindings make integration of the Promira API into custom applications simple. Accessing Promira functionality simply requires function calls to the Promira API. This API is easy to understand, much like the ANSI C library functions, (e.g., there is no unnecessary entanglement with the Windows messaging subsystem like development kits for some other embedded tools).

First, choose the Rosetta bindings appropriate for the programming language. Different Rosetta bindings are included in the software download package available on the Total Phase website. Currently the following languages are supported: C/C++, C#, VB, Python. Next, follow the instructions for each language binding on how to integrate the bindings with your application build setup. As an example, the integration for the C language bindings is described below. (For information on how to integrate the bindings for other languages, please see the example code available for download on the Total Phase website.)

1. Include the promira.h and promana.h files in any C or C++ source module. The module may now use any API call listed in promira.h and promana.h.
2. Compile and link promira.c and promana.c with your application. Ensure that the include path for compilation also lists the directory in which promira.h and promana.h is located if the two files are not placed in the same directory.
3. Place the Promira DLL (promira.dll), included with the API software package, in the same directory as the application executable or in another directory such that it will be found by the previously described search rules.

5.1.2 Versioning

Since a new Promira DLL can be made available to an already compiled application, it is essential to ensure the compatibility of the Rosetta binding used by the application against the DLL loaded by the system. A system similar to the one employed for the DLL-Firmware cross-validation is used for the binding and DLL compatibility check.

Here is an example.

      DLL v1.20: compatible with Binding >= v1.10       Binding v1.15: compatible with DLL >= v1.15     

The above situation will pass the appropriate version checks. The compatibility check is performed within the binding. If there is a version mismatch, the API function will return an error code, PA_APP_INCOMPATIBLE_LIBRARY.

5.1.3 Customizations

While provided language bindings stubs are fully functional, it is possible to modify the code found within this file according to specific requirements imposed by the application designer.

For example, in the C bindings one can modify the DLL search and loading behavior to conform to a specific paradigm. See the comments in promira.c for more details.

6 API Documentation

Top

6.1 Introduction

The Promira API documentation that follows is oriented toward the Promira Rosetta C bindings. The set of Promira API functions and their functionality is identical regardless of which Rosetta language binding is utilized. The only differences will be found in the calling convention of the functions. For further information on such differences please refer to the documentation that accompanies each language bindings in the Promira API Software distribution

Top

6.2 General Data Types

The following definitions are provided for convenience. All Promira data types are unsigned.

      typedef unsigned char       u08;       typedef unsigned short      u16;       typedef unsigned int        u32;       typedef unsigned long long  u64;       typedef signed   char       s08;       typedef signed   short      s16;       typedef signed   int        s32;       typedef signed   long long  s64;       typedef float               f32;     

Top

6.3 Notes on Status Codes

Most of the Promira API functions can return a status or error code back to the caller. The complete list of status codes is provided at the end of this chapter. All of the error codes are assigned values less than 0, separating these responses from any numerical values returned by certain API functions.

Each API function can return one of two error codes with regard to the loading of the underlying Promira DLL, PA_APP_UNABLE_TO_LOAD_LIBRARY and PA_APP_INCOMPATIBLE_LIBRARY. If these status codes are received, refer to the previous sections in this manual that discuss the DLL and API integration of the Promira software. Furthermore, all API calls can potentially return the error PA_APP_UNABLE_TO_LOAD_FUNCTION. If this error is encountered, there is likely a serious version incompatibility that was not caught by the automatic version checking system. Where appropriate, compare the language binding versions (e.g., PM_HEADER_VERSION found in promira.h and PM_CFILE_VERSION found in promira.c or PA_APP_HEADER_VERSION found in promana.h and PA_APP_CFILE_VERSION found in promana.c) to verify that there are no mismatches. Next, ensure that the Rosetta language binding (e.g., promira.c and promira.h or promana.c and promana.h) are from the same release as the Promira DLL. If all of these versions are synchronized and there are still problems, please contact Total Phase support for assistance.

Any API function that accepts any type of handle can return the error PA_APP_INVALID_HANDLE if the handle does not correspond to a valid instance that has already been opened or created. If this error is received, check the application code to ensure that the open or create command returned a valid handle and that this handle is not corrupted before being passed to the offending API function.

Finally, any function call that communicates with an Promira device can return the error PA_APP_COMMUNICATION_ERROR. This means that while the handle is valid and the communication channel is open, there was an error receiving the acknowledgment response from the Promira application. The error signifies that it was not possible to guarantee that the connected Promira device has processed the host PC request, though it is likely that the requested action has been communicated to the Promira device and the response was lost.

These common status responses are not reiterated for each function. Only the error codes that are specific to each API function are described below.

All of the possible error codes, along with their values and status strings, are listed following the API documentation.

Top

6.4 Application Management Interface

All functions starting with pm_ are for Application Management. Please refer to the Promira Serial general user manual for the details.

Top

6.5 General Application Interface

6.5.1 General Application

Top

Overview

After opening the device with pm_open and starting an application with pm_load, a connection needs to be established with pa_app_connect. See the language specific sample programs for examples of this connection process.

Top

Software Operational Overview

There are a series of steps required for a successful capture. These steps are handled by the Data Center software automatically, but must be explicitly followed by an application programmer wishing to write custom software. The following is meant to provide a high-level overview of the operation of the Promira platform.

1. Determine the IP address of the Promira platform. The function pm_find_devices returns a list of IP addresses for all Promira platforms that are attached to the analysis computer.
2. Obtain a Promira connection handle by calling the function pa_app_connect on the appropriate IP addresses. All other software operations are based on this handle.
3. Configure the Promira platform as necessary. The API documentation provides complete details about the different configurations.
4. Start the capture by calling the function pa_capture_start.
5. Retrieve monitored data by using the read functions that are appropriate for the monitored bus type. There are different functions available for retrieving additional data such as byte- and bit-level timing.
6. End the capture by calling the function pa_capture_stop. At this point the capture is stopped, and no new data can be obtained. Captured data may still be read from the on-board buffer after calling this function.
7. Close the Promira platform handle with the function pa_app_disconnect.

If the Promira platform is disabled and then re-enabled it does not need to be re-configured. However, upon closing the handle, all configuration settings will be lost.

Example code is available for download from the Total Phase website. These examples demonstrate how to perform the steps outline above for each of the serial bus protocols supported.

Top

Connect to the Application (pa_app_connect)

      PromiraConnectionHandle pa_app_connect (const char * net_addr)     

Connect to the application launched by pm_load.

Top

Disconnect to the Application (pa_app_disconnect)

      int pa_app_disconnect (PromiraConnectionHandle conn)     

Disconnect to the application.

Top

Version (pa_app_version)

      int pa_app_version (PromiraConnectionHandle conn,                           PromiraAppVersion *     version);     

Return the version matrix for the application connected to the given handle.

  struct PromiraAppVersion {     /* Software, firmware, and hardware versions. */     u16 software;     u16 firmware;     u16 hardware;     /* FW requires that SW must be >= this version. */     u16 sw_req_by_fw;     /* SW requires that FW must be >= this version. */     u16 fw_req_by_sw;     /* API requires that SW must be >= this version. */     u16 api_req_by_sw;   };           

Top

Status String (pa_app_status_string)

      const char *pa_app_status_string (int status);     

Return the status string for the given status code.

Top

Get Features (pa_app_features)

      int pa_app_features (PromiraConnectionHandle conn);     

Return the device features as a bit-mask of values, or an error code if the handle is not valid.

            #define PA_FEATURE_NONE     (0)             #define PA_FEATURE_ESPI     (1<<0)           

6.5.2 Configuration

Top

Target Power (pa_phy_target_power)

      int pa_phy_target_power (PromiraConnectionHandle conn,                                u08                     power_mask);     

Activate/deactivate target power pins 4, 6 and/or 22, 24.

Top

Level Shift (pa_phy_level_shift)

      f32 pa_phy_level_shift (PromiraConnectionHandle conn,                               f32                     level);     

Shift the logic level for all signal pins including target power pin 22 and 24.

6.5.3 Monitoring API

Top

Start Capture (pa_capture_start)

      int pa_capture_start (PromiraConnectionHandle conn,                             PromiraProtocol         protocol,                             PromiraTriggerMode      trig_mode);     

Start monitoring packets on the selected interface.

Top

Trigger Capture (pa_capture_trigger)

      int pa_capture_trigger (PromiraConnectionHandle conn);     

Trigger the capture.

Top

Wait for Capture to Trigger (pa_capture_trigger_wait)

      int pa_capture_trigger_wait (PromiraConnectionHandle conn,                                    int                     timeout_ms,                                    PromiraCaptureStatus *  status);     

Wait for the capture to trigger.

Top

Stop Capture (pa_capture_stop)

      int pa_capture_stop (PromiraConnectionHandle conn);     

Stop capturing data.

Top

Query Capture Status (pa_capture_status)

      int pa_capture_status (PromiraConnectionHandle      conn,                              PromiraCaptureStatus *       status,                              PromiraCaptureBufferStatus * buf_status);     

Query the status of capture.

  struct PromiraCaptureBufferStatus {     u32 pretrig_remaining_kb;     u32 pretrig_total_kb;     u32 capture_remaining_kb;     u32 capture_total_kb;   };           

Top

Configure Capture Buffer (pa_capture_buffer_config)

      int pa_capture_buffer_config (PromiraConnectionHandle conn,                                     u32                     pretrig_kb,                                     u32                     capture_kb);     

Configure on-board capture buffer.

Top

Query Capture Buffer Config (pa_capture_buffer_config_query)

      int pa_capture_buffer_config_query (                     PromiraConnectionHandle conn,                     u32 *                   pretrig_kb,                     u32 *                   capture_kb);     

Query the current on-board capture buffer configuration.

6.5.4 Digital I/O Functions

Top

Configure Digital I/O (pa_digital_io_config)

      int pa_digital_io_config (PromiraConnectionHandle conn,                                 u32                     enable,                                 u32                     direction,                                 u32                     polarity);     

Configure digital I/O.

Top

Query Digital I/O Config (pa_digital_io_config_query)

      int pa_digital_io_config_query (PromiraConnectionHandle conn,                                       u32 *                   enable,                                       u32 *                   direction,                                       u32 *                   polarity);     

Query the current digital IOs configuration.

6.5.5 Notes on Protocol-Specific Read Functions

All read functions return a timestamp, a duration, a status, and an event value through the PromiraReadInfo parameter.

  struct PromiraReadInfo {     u64 timestamp;     u64 duration;     u32 status;     u32 events;   };       

Each match parameter is represented by two separate fields: type and value. The PromiraMatchType enumerated type is used to determine whether a connection value field should be disabled, match on equal, or match on not equal. The different enumerated values are listed below. Restrictions on usage are indicated by footnotes.

Top

6.6 eSPI API

6.6.1 Notes

The eSPI API functions are only available for the Promira platform with eSPI Analysis Application.

6.6.2 eSPI Monitor Interface

Top

Set Operating Configuration (pa_espi_operating_config)

      int pa_espi_operating_config                     (PromiraConnectionHandle         conn,                      u08                             slave_id,                      const PromiraEspiOperatingCfg * cfg);     

Set the operating configuration of eSPI system.

Top

Read Operating Configuration (pa_espi_operating_config_read)

      int pa_espi_operating_config_read (                     PromiraConnectionHandle   conn,                     u08                       slave_id,                     PromiraEspiOperatingCfg * cfg);     

Read the operating configuration that eSPI system is using.

Top

Read eSPI (pa_espi_read)

      int pa_espi_read (PromiraConnectionHandle conn,                         PromiraReadInfo *       info,                         PromiraEspiPacketInfo * pkt_info,                         u32                     max_bytes,                         u08 *                   packet);     

Read eSPI data from the analyzer.

Top

Configure Simple Trigger (pa_espi_simple_trigger_config)

      int pa_espi_simple_trigger_config                     (PromiraConnectionHandle        conn,                      u32                            act_on,                      const PromiraEspiPacketMatch * pkt_match,                      u32                            actions);     

Configure the eSPI simple matching system for triggering.

Top

Configure Hardware Filter (pa_espi_hw_filter_config)

      int pa_espi_hw_filter_config                     (PromiraConnectionHandle        conn,                      u08                            slave_id,                      const PromiraEspiPacketMatch * pkt_match);     

Configure the eSPI hardware filter.

Top

Read eSPI statistics (pa_espi_stats_read)

      int pa_espi_stats_read (PromiraConnectionHandle conn,                               u08                     slave_id,                               PromiraEspiStats *      stats);     

Read eSPI hardware statistics from the analyzer.

Details

Read ESPI hardware statistics

struct PromiraEspiStats {     u32                       ch_perif     u32                       ch_vw     u32                       ch_oob     u32                       ch_flash     u32                       get_cfg     u32                       set_cfg     u32                       get_sts     u32                       pltf_reset     u32                       alert     u32                       reset     u32                       cmd_crc     u32                       resp_crc     u32                       fltr_out_pkts     u32                       fltr_out_cmds };        

Table 26 : description of statistical counters stats

ch_perif	A count of all peripheral channel packets seen on the bus
ch_vw	A count of all virtual wire channel packets seen on the bus
ch_oob	A count of all OOB channel packets seen on the bus
ch_flash	A count of all flash channel packets seen on the bus
get_cfg	A count of all GET_CONFIGURATION packets seen on the bus
set_cfg	A count of all SET_CONFIGURATION packets seen on the bus
get_sts	A count of all GET_STATUS packets seen on the bus
pltf_reset	A count of platform reset commands (inband reset) seen on the bus
alert	A count of alert events seen on bus
reset	A count of reset events seen on bus
cmd_crc	A count of all packets with command crc error seen on the bus
resp_crc	A count of all packets with response crc error seen on the bus
fltr_out_pkts	A count of all packets that were filtered out (based on HW filter configuration)
fltr_out_cmds	A count of all packets with a specific command that were filtered out (based on HW filter configuration)

 

Top

Configure Advanced Trigger (pa_espi_adv_trig_config)

      int pa_espi_adv_trig_config                  (PromiraConnectionHandle        conn,                   u08                            salve_id,                   const PromiraEspiAdvancedTrig1 * pkt_adv_trig1_level1,                   const PromiraEspiAdvancedTrig1 * pkt_adv_trig1_level2,                   const PromiraEspiAdvancedTrig1 * pkt_adv_trig1_level3,                                                             const PromiraEspiAdvancedTrig1 * pkt_adv_trig1_level4,                                        const PromiraEspiAdvancedTrig2 * pkt_adv_trig2,                                        const PromiraEspiAdvancedTrigError * pkt_adv_trig_error);     

Configure the eSPI advanced triggering system.

Arguments

conn	handle of the connection
slave_id	slave number: 0 for first slave, 1 for second slave
pkt_adv_trig1_level1	Advanced trigger match conditions for option 1, level1
pkt_adv_trig1_level2	Advanced trigger match conditions for option 1, level2
pkt_adv_trig1_level3	Advanced trigger match conditions for option 1, level3
pkt_adv_trig1_level4	Advanced trigger match conditions for option 1, level4
pkt_adv_trig2	Advanced trigger conditions for option 2
pkt_adv_trig_error	Advanced trigger conditions for trigger on error

Return Value

A status code is returned with PA_APP_OK on success.

Specific Error Codes

None.

Details

This function is to trigger and/or activate digital outputs on complex packet matching

Digital output will not activate on digital input.

struct PromiraEspiAdvancedTrigBytes16{     u08                      byte0     u08                      byte1     u08                      byte2     u08                      byte3     u08                      byte4     u08                      byte5     u08                      byte6     u08                      byte7     u08                      byte8     u08                      byte9     u08                      byteA     u08                      byteB     u08                      byteC     u08                      byteD     u08                      byteE     u08                      byteF };        

struct PromiraEspiAdvancedTrigBytes2{     u08                      byte0     u08                      byte1 };        

struct PromiraEspiAdvancedTrig1 {     u08                            cmd_byte     u08                            cmd_cyc     u08                            cmd_tag     u16                            cmd_len     u64                            cmd_addr     PromiraEspiAdvancedTrigBytes16 cmd_data     PromiraEspiAdvancedTrigBytes16 cmd_data_mask     u08                            rsp_byte     u08                            rsp_cyc     u08                            rsp_tag     u16                            rsp_len     u64                            rsp_addr     PromiraEspiAdvancedTrigBytes16 rsp_data     PromiraEspiAdvancedTrigBytes16 rsp_data_mask     PromiraEspiAdvancedTrigBytes2  sts_byte     PromiraEspiAdvancedTrigBytes2  sts_mask     u08                            trg_pin     u08                            trg_pin_polarity     u08                            trg_pin_direction     u08                            cmd_byte_enable     u08                            cmd_cyc_enable     u08                            cmd_tag_enable     u08                            cmd_len_enable     u08                            cmd_addr_enable     u08                            cmd_data_enable     u08                            rsp_byte_enable     u08                            rsp_cyc_enable     u08                            rsp_tag_enable     u08                            rsp_len_enable     u08                            rsp_addr_enable     u08                            rsp_data_enable     u08                            sts_byte_enable     u08                            trg_pin_enable     u08                            lvl_select_enable     u08                            lvl_select_immediate };       

Table 27 : PromiraEspiAdvancedTrig1 field descriptions

cmd_byte	Command value
cmd_cyc	Command header cycle type value
cmd_tag	Command header tag value
cmd_len	Command header espi length value
cmd_addr	Command header address value
cmd_data	Command phase data
cmd_data_mask	Command phase bitwise enables for data match
rsp_byte	Response value
rsp_cyc	Response header cycle type value
rsp_tag	Response header tag value
rsp_len	Response header espi length value
rsp_addr	Response header address value
rsp_data	Response phase data
rsp_data_mask	Response phase bitwise enables for data match
sts_byte	Status field
sts_mask	Bitwise enables for status match
trg_pin	Select a digital pin number (0 - 10) to be driven on a condition match
trg_pin_polarity	Polarity of the digital pin
trg_pin_direction	Direction of the digital pin
cmd_byte_enable	Enable match on a command
cmd_cyc_enable	Enable match on cycle type in command header
cmd_tag_enable	Enable match on tag in command header
cmd_len_enable	Enable match on espi length in command header
cmd_addr_enable	Enable match on address in command header
cmd_data_enable	Enable match on data in command phase
rsp_byte_enable	Enable match on a response
rsp_cyc_enable	Enable match on cycle type in response header
rsp_tag_enable	Enable match on tag in response header
rsp_len_enable	Enable match on espi length in response header
rsp_addr_enable	Enable match on address in response header
rsp_data_enable	Enable match on data in response phase
sts_byte_enable	Enable match on status in response phase
trg_pin_enable	Enable a digital pin for trigger
lvl_select_enable	Enable this level for matching
lvl_select_immediate	Set in cases where the packet that matches this conditions should immediately follow the packet that matched the previous level's conditions

 

struct PromiraEspiAdvancedTrig2 {     u08                            cmd_byte2     u08                            cmd_cyc2     u08                            cmd_tag2     u16                            cmd_len2     u64                            cmd_addr2     PromiraEspiAdvancedTrigBytes16 cmd_data2     PromiraEspiAdvancedTrigBytes16 cmd_data_mask2     u08                            trg_pin_req     u08                            trg_pin_req_polarity     u08                            trg_pin_req_direction     u08                            trg_pin_cmpl0     u08                            trg_pin_cmpl0_polarity     u08                            trg_pin_cmpl0_direction     u08                            trg_pin_cmpl1     u08                            trg_pin_cmpl1_polarity     u08                            trg_pin_cmpl1_direction     u08                            trg_pin_cmpl2     u08                            trg_pin_cmpl2_polarity     u08                            trg_pin_cmpl2_direction     u08                            cmd_byte2_enable     u08                            cmd_cyc2_enable     u08                            cmd_tag2_enable     u08                            cmd_len2_enable     u08                            cmd_addr2_enable     u08                            cmd_data2_enable     u08                            succ_cmpl_enable     u08                            unsucc_cmpl_enable     u08                            trg_pin_req_enable     u08                            trg_pin_cmpl0_enable     u08                            trg_pin_cmpl1_enable     u08                            trg_pin_cmpl2_enable };        

Table 28 : PromiraEspiAdvancedTrig2 field descriptions

cmd_byte2	Non-posted request command value
cmd_cyc2	Non-posted request cycle type value
cmd_tag2	Non-posted request tag value
cmd_len2	Non-posted request espi length
cmd_addr2	Non-posted request address
cmd_data2	Non-posted request completion data
cmd_data_mask2	Non-posted request completion bitwise enables for data match
trg_pin_req	Select a digital pin number (0 - 10) to be driven on a request packet condition match
trg_pin_req_polarity	Polarity of the digital pin
trg_pin_req_direction	Direction of the digital pin
trg_pin_cmpl0	Select a digital pin number (0 - 10) to be driven on a 'first' completion packet match (if the request has a completion type 'FIRST')
trg_pin_cmpl0_polarity	Polarity of the digital pin
trg_pin_cmpl0_direction	Direction of the digital pin
trg_pin_cmpl1	Select a digital pin number (0 - 10) to be driven on the first 'middle' completion packet match (if the request has a completion type 'MIDDLE')
trg_pin_cmpl1_polarity	Polarity of the digital pin
trg_pin_cmpl1_direction	Direction of the digital pin
trg_pin_cmpl2	Select a digital pin number (0 - 10) to be driven on a 'last' or 'only' completion packet condition match (the the request has a completion type 'LAST/ONLY')
trg_pin_cmpl2_polarity	Polarity of the digital pin
trg_pin_cmpl2_direction	Direction of the digital pin
cmd_byte2_enable	Enable match on request command
cmd_cyc2_enable	Enable match on request cycle type
cmd_tag2_enable	Enable match on request tag value
cmd_len2_enable	Enable match on request length value
cmd_addr2_enable	Enable match on request address value
cmd_data2_enable	Enable match on request completion data pattern
succ_cmpl_enable	Enable match on successful completion
unsucc_cmpl_enable	Enable match n ran unsuccessful condition
trg_pin_req_enable	Enable a digital pin for trigger on request
trg_pin_cmpl0_enable	Enable a digital pin for trigger on 'first' completion
trg_pin_cmpl1_enable	Enable a digital pin for trigger on the first 'middle' completion
trg_pin_cmpl2_enable	Enable a digital pin for trigger on 'last' or 'only' completion

 

struct PromiraEspiAdvancedTrigError {     u08                      err_code     u08                      err_code_enable };        

Table 29 : PromiraEspiAdvancedTrigError field descriptions

err_code	Error code value for match
err_code_enable	Enable match on packet error status

 

 

Top

6.7 Error Codes

Table 30 : eSPI Analysis Application Error Codes

Literal Name	Value	pa_app_status_string() return value
PA_APP_OK	0	ok
PA_APP_UNABLE_TO_LOAD_LIBRARY	-1	unable to load library
PA_APP_UNABLE_TO_LOAD_DRIVER	-2	unable to load USB driver
PA_APP_UNABLE_TO_LOAD_FUNCTION	-3	unable to load binding function
PA_APP_INCOMPATIBLE_LIBRARY	-4	incompatible library version
PA_APP_INCOMPATIBLE_DEVICE	-5	incompatible device version
PA_APP_COMMUNICATION_ERROR	-6	communication error
PA_APP_UNABLE_TO_OPEN	-7	unable to open device
PA_APP_UNABLE_TO_CLOSE	-8	unable to close device
PA_APP_INVALID_HANDLE	-9	invalid device handle
PA_APP_CONFIG_ERROR	-10	configuration error
PA_APP_MEMORY_ALLOC_ERROR	-11	unable to allocate memory
PA_APP_UNABLE_TO_INIT_SUBSYSTEM	-12	unable to initialize subsystem
PA_APP_INVALID_LICENSE	-13	invalid license
PA_APP_UNKNOWN_PROTOCOL	-14	unknown promira protocol
PA_APP_STILL_ACTIVE	-15	promira still active
PA_APP_INACTIVE	-16	promira inactive
PA_APP_FUNCTION_NOT_AVAILABLE	-17	promira function not available
PA_APP_READ_EMPTY	-18	nothing to read
PA_APP_TIMEOUT	-31	timeout to collect a response
PA_APP_CONNECTION_LOST	-32	connection lost
PA_APP_QUEUE_FULL	-50	queue is full
PA_APP_UNKNOWN_CMD	-83	unknown command sent

7 Electrical Specifications

Top

7.1 DC Characteristics

Table 31 : Absolute Maximum Rating

Symbol	Parameter	Conditions and Notes	Min	Max	Units
VIO	Input voltage (1, 3, 9, 14, 15, 17, 19, 20, 26, 31, 32, 33 pins)		-0.5	5.5	V
VIO	Input voltage (5, 7, 8, 11, 13, 21, 23, 25, 27, 29 pins)		-0.5	4.6	V

 

Table 32 : Operating Conditions

Symbol	Parameter	Conditions and Notes	Min	Max	Units
Ta	Ambient Operating Temperature		10 (50)	35 (95)	C (F)
ICore	Core Current Consumption	(1)		500	mA

Note:

(1) The core current consumption includes the current consumption for the entire internal Promira platform. Typical current consumption example at 5 V with 66 MHz single eSPI master read operation is 340 mA using USB connection. Add 70 mA for operation with gigabit Ethernet connection.

 

Table 33 : DC Characteristics (1)

Symbol	Parameter	Conditions and Notes	Min	Max	Units
VVTGT	Target power voltage (4 and 6 pins)		3.3	5.0	V
VVIO	IO power voltage (22 and 24 pins)		1.8	1.8	V
VIL	Input low voltage (1, 3 pins)		-0.5	0.45	V
VIH	Input high voltage (1, 3 pins)		1.26	5.5	V
VOL	Output low voltage (1, 3 pins)			0.2	V
VOH	Output high voltage (1, 3 pins)	(1)			V
VIL	Input low voltage (5, 7, 8, 11, 13, 21, 23, 25, 27, 29 pins)			0.63	V
VIH	Input high voltage (5, 7, 8, 11, 13, 21, 23, 25, 27, 29 pins)		1.17		V
VOL	Output low voltage (5, 7, 8, 11, 13, 21, 23, 25, 27, 29 pins)			0.5	V
VOH	Output high voltage (5, 7, 8, 11, 13, 21, 23, 25, 27, 29 pins)		1.25		V
VIL	Input low voltage (9, 14, 15, 17, 19, 20, 26, 31, 32, 33 pins)		0.18		V
VIH	Input high voltage (9, 14, 15, 17, 19, 20, 26, 31, 32, 33 pins)		1.62		V
VOL	Output low voltage (9, 14, 15, 17, 19, 20, 26, 31, 32, 33 pins)			0.18	V
VOH	Output high voltage (9, 14, 15, 17, 19, 20, 26, 31, 32, 33 pins)		1.62		V
IVTGT	Target power current (4 and 6 pins)	(2)		50	mA
IVIO	IO power current (22 and 24 pins)	(2)		50	mA
II	Input/output current (eSPI pins)			10	mA
IL	Input/output leakage current (eSPI pins)			100	uA
CIN	Input/output capacitance (eSPI pins)	1 MHz	2	12	pF

Notes:

(1) Outputs are open collector, and therefor they are set by their pull-ups values and pull-ups voltage rail.

(2) Option 1: Two pins have 50 mA each. Option 2: One pin has 100 mA, and one pin has 0 mA, etc. Total current consumption on both pins should not exceed 100 mA.

 

Table 34 : Current Consumption Calculation Example

Pin	Symbol	Description	Conditions & Notes	Max all pins	Units
NA	ICore	Core Current Consumption	(1)	500	mA
4, 6	VTGT	Target Power	(2)	100	mA
22, 24	VIO	IOPower	(2)	100	mA
15, 31, 17, 19, 21, 23, 20, 25, 27, 29, 33, 26, 32	Reset[0:1], DIO[0:10]	eSPI Reset and Digital IO Signals	(3)	60	mA
	Total Current Consumption For Promira Core and Outputs		(4)	760	mA

Notes:

(1) The core current consumption includes the current consumption for the entire internal Promira platform, but does not include the output signals current consumption.

(2) Option 1: Two pins have 50 mA each. Option 2: One pin has 100 mA, and one pin has 0 mA. Etc. Total current consumption on both pins should not exceed 100 mA.

(3) Option 1: Six pins have 10 mA each. Option 2: One pin has 60 mA, and the other pins have 0 mA. Etc. Total current consumption on all pins should not exceed 60 mA.

(4) If the total current consumption for the Promira platform core and outputs is over 500 mA, then a USB 3.0 port and USB 2.0 cable or Total Phase external AC adapter should be used. A USB 3.0 port supplies up to 900 mA. A USB 2.0 port supplies up to 500 mA. Total Phase external AC adapter supplies up to 1.2 A. In this example the total current consumption for the Promira platform core and outputs is 760 mA, therefor USB 3.0 port and USB 2.0 cable or Total Phase external AC adapter should be used.

Top

7.2 Signal Ratings

7.2.1 Logic high Levels

All input / outputs signal levels are nominally 1.8V (+/-10%) logic high.

7.2.2 ESD protection

The Promira Serial Platform has built-in electrostatic discharge protection to prevent damage to the unit from high voltage static electricity.

 

8 Legal / Contact

Top

8.1 Disclaimer

All of the software and documentation provided in this manual, is copyright Total Phase, Inc. ("Total Phase"). License is granted to the user to freely use and distribute the software and documentation in complete and unaltered form, provided that the purpose is to use or evaluate Total Phase products. Distribution rights do not include public posting or mirroring on Internet websites. Only a link to the Total Phase download area can be provided on such public websites.

Total Phase shall in no event be liable to any party for direct, indirect, special, general, incidental, or consequential damages arising from the use of its site, the software or documentation downloaded from its site, or any derivative works thereof, even if Total Phase or distributors have been advised of the possibility of such damage. The software, its documentation, and any derivative works is provided on an "as-is" basis, and thus comes with absolutely no warranty, either express or implied. This disclaimer includes, but is not limited to, implied warranties of merchantability, fitness for any particular purpose, and non-infringement. Total Phase and distributors have no obligation to provide maintenance, support, or updates.

Information in this document is subject to change without notice and should not be construed as a commitment by Total Phase. While the information contained herein is believed to be accurate, Total Phase assumes no responsibility for any errors and/or omissions that may appear in this document.

Top

8.2 Life Support Equipment Policy

Total Phase products are not authorized for use in life support devices or systems. Life support devices or systems include, but are not limited to, surgical implants, medical systems, and other safety-critical systems in which failure of a Total Phase product could cause personal injury or loss of life. Should a Total Phase product be used in such an unauthorized manner, Buyer agrees to indemnify and hold harmless Total Phase, its officers, employees, affiliates, and distributors from any and all claims arising from such use, even if such claim alleges that Total Phase was negligent in the design or manufacture of its product.

Top

8.3 Contact Information

Total Phase can be found on the Internet at http://www.totalphase.com/. If you have support-related questions, please go to the Total Phase support page at http://www.totalphase.com/support/. For sales inquiries, please contact sales@totalphase.com.

©2003-2016 Total Phase, Inc.
All rights reserved.