Question from the Customer:

For my setup, the internal pull-ups of the Aardvark I2C/SPI Host Adapter will be disabled and 2.2k pull-ups will be connected from the SCL and SDA lines to a 2.7V voltage source. Here is a diagram:

Diagram of 2.2k ohm resistors : SCK and SDA lines to 2.7V .

My question – will this setup work? I am working on a system where signal voltage levels could vary more than normal.
Response from Technical Support:

Thanks for your question! Setting up pull-up resistors correctly can make a big improvement for signal integrity and bus tolerance. However, the Aardvark adapter is only compatible with 3.3V and 5V level signals. Operating with signal levels outside of that range would not work with the Aardvark adapter, and could possibly void the warranty should any damage occur.

To successfully communicate with 2.7V and other signal levels, we recommend using our Level Shifter Board. If you want to simplify the setup – avoiding adding a second device to your setup, we recommend the Promira Serial Platform, which provides an internal Level Shifter and many other capabilities.

To understand signal level performance, we will describe how and why the internal resistors work and when external pull-up resistors are needed. Then we will talk about the recommendations we provided.

Internal Pull-up Resistors and Signal Integrity

In the Aardvark adapter, there is a 2.2K internal resistor on each I2C line: SCL (clock) and SDA (data). The lines are pulled up to 3.3V, which results in approximately 1.5 mA of pull-up current. If the Aardvark adapter is connected to an I2C bus that also includes pull-up resistors, the total pull-up current could be larger.

I2C Current Specifications and Bitrates

The I2C specification allows a maximum of 3 mA pull-up current on each I2C line.

The Aardvark adapter has two internal pull-up resistors on each line: 2.2k ohm and 100k ohm resistors in parallel.

The 2.2k ohm resistor can be turned on and off. You can disable these pull-up resistors using Control Center Serial Software or the Aardvark Software API. For information about using API commands, please refer to the API Documentation section of the Aardvark I2C/SPI Host Adapter User Manual.

The 100k ohm resistor, which is extremely weak, cannot be turned off. This ensures the lines will be in the logic high state if nothing is connected on the other side of connector. This feature supports data integrity: it prevents data errors occurring from voltage level fluctuations.

Here is a good rule of thumb: if a downstream I2C device can sink more than 5 mA of
current, the protocol should operate properly. Stronger pull-up resistors and larger sink
currents may be required for fast bitrates, especially if there is a large amount of
capacitance on the bus.

Recommendations for Flexible Voltage Levels

As previously mentioned, we suggested two solutions to successfully run your setup. We will provide an overview of those options here.

Level Shifter Board

Here is a summary of the features of the Level Shifter Board:

Level shifting for I2C, SPI, and MDIO signals
Supports voltage levels of 1.2V, 1.5V, 1.8V, 2.5V, 3.0V, and 3.3V
Supply power to downstream devices
I2C speeds of 800 kHz, which supports the maximum speed of the Aardvark adapter.

When used, the Level Shifter Board is placed between the Aardvark adapter and the target device. The Level Shifter Board can also be used with the Cheetah SPI Host Adapter and the Beagle I2C/SPI Protocol Analyzer.

Promira Serial Platform for Maximum Support

To deploy level shifting without additional hardware, consider using the Promira Serial Platform licensed with the appropriate I2C Active Level application: Level 1, or Level 2. Note:, Active Level 1 is required before installing Active Level 2.

Here are the basic features of the Promira Serial Platform:

Integrated level shifting, ranging from 0.9 to 5.0 volts
High-speed USB connectivity to the host system for high performance support
for benchtop programming, testing, and emulation
Ethernet connectivity for remote control and automation
Provide 200 mA of power to target devices

Here is a visual summary of all the features, as well as a quick overview of other Total Phase devices for working with I2C and SPI protocols:

Promira Applications Comparison Chart

For an Introduction to using the Promira Serial Platform, take a look at this video:

We hope this answers your questions. Additional resources that you may find helpful include the following:

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

The Data Center Software is Total Phase’s free bus monitoring software that is used in conjunction with our protocol analyzers and offers a variety of ways to monitor and debug data in real time. One of the most useful features of the Data Center Software is the LiveFilter feature, which allows users to refine large streams of data and focus on data of interest. In this blog post, we will discuss what the LiveFilter feature is, which parameters it can filter, and how it can be used. First, we will provide a brief introduction into the Data Center Software.

About the Data Center Software

We at Total Phase provide a variety of debugging and development tools to assist engineers with testing and analyzing I2C, SPI, USB, CAN, eSPI, and A2B applications. Our protocol analyzers in particular allow users to monitor and capture bus data in real time, providing insight into low-level bus events and errors.

These protocol analyzers, including the line of Beagle Protocol Analyzers, USB Power Delivery Analyzer, Promira Serial Platform, and Komodo CAN Interfaces, are used in conjunction with the Data Center Software, which provides an interface to capture and display USB, I2C, SPI, USB Type-C Power Delivery, eSPI, and CAN bus data. The Data Center Software is the only protocol analysis software in the industry with true, real-time performance and cross-platform support for Windows, Linux, and Mac OS X.

The software is packed with useful and time-saving features. One of the features that users find most beneficial is the LiveFilter feature.

LiveFilter Feature in the Data Center Software

Before we discuss what can be filtered and how to use the LiveFilter feature, we will briefly explain why this feature is critical in protocol analysis.

LiveFilter Applications

When working on projects, engineers will often run into system errors or bugs. Whether it be integration issues, programing or software bugs, or erratic system behavior, having a hardware analyzer tool to help identify the root cause of the problem can be crucial. One of the best ways to fix a problem is to replicate the problem, capture and study it, and then implement the appropriate hardware or software fix. The Data Center Software allows developers to perform the capture and analysis step when identifying the problem.

Beagle USB 12 Protocol Analyzer with a USB mouse

To utilize the Data Center Software, developers can hook their Total Phase protocol analysis tools to their embedded system and run live tests. By connecting their system and replicating their setup, the Data Center Software will record every transaction occurring on the bus in true, real time, taking the guesswork out of the debugging and development phase. To drill down even further into specific data and bus errors, the Data Center Software has LiveFilter technology that allows developers to easily see, filter, and search bus data as it is being captured. So, what exactly can users filter for and against using this functionality?

What Parameters Can Be Filtered Using LiveFilter?

Depending on the tool being used, the LiveFilter feature will allow users to filter for or against various bus data patterns, packets, errors, and more for I2C, SPI, CAN, USB, and eSPI protocols. Users can seamlessly switch between filtered and non-filtered views with a single click, and when disabling the filter, users can see all the transactions that occurred before and after the event for easier debugging.

General Filtering

For all protocols, the LiveFilter feature will provide options for general filtering. Here, data can be filtered in both Hex and ASCII. Specific data patterns, text, and errors can be typed into the “Data”, “Text” and, “Errors” boxes. Users can also filter data based on Index, Length, and Duration.

Data Center general filtering options

USB Filters

When the Beagle USB Protocol Analyzer is used with the Data Center Software, users can filter for different USB parameters, including Class, Protocol, and Packet specific data. Depending on the Beagle USB Protocol Analyzer being used, data can be filtered for both USB 2.0 and USB 3.0 protocols.

Packet data on the USB 2.0 bus can be filtered for: Tokens, Data, Handshake, Special, and PIDs. Packet data on the USB 3.0 bus can be filtered for: Link Flow, Link Power, Link Status, Transactions, Data Headers, and Data Payloads. The filters for this criteria can be toggled on and off at any point of the USB capture/trace.

Filter options for USB 2.0 and 3.0 applications

When filtering for Class and Protocol data, additional filter options are presented. Class filtering enables users to filter based on Device Requests Direction, Type, Recipient, and Class Transfers. Protocol filtering enables users to filter both Token and Handshake transactions on the USB bus. The filters for this criteria can also be toggled on and off at any point of the USB capture/trace.

USB Class and Protocol filtering options

I2C/SPI Filters

When the Beagle I2C/SPI Protocol Analyzer is used with the Data Center Software, users can filter for specific I2C or SPI bus parameters, including 7- and 10-bit addresses, and can also specify for ACKed, NACKed, read, and write data transactions. These filters can easily be toggled on and off at any point in the data capture.

Filter options for the I2C and SPI bus in Data Center

CAN Filters

When the Komodo CAN Interface is used with the Data Center Software, users can filter for various CAN bus parameters, including Device ID, Extended ID, and Data Length Code. Filters can also be applied for Traffic, Channel, Error States, and Records.

CAN bus filters in Data Center

eSPI Filters

When using the eSPI Analysis Application on the Promira Serial Platform, users can also filter for a variety of eSPI bus parameters using LiveFilter. Users can filter based on Packet data and also by Channel.

eSPI bus filters in Data Center

How to Use LiveFilter

Filters are created and applied to the capture through the LiveFilter tab of the Navigator pane in the Data Center Software. Simply click on the “LiveFilter” tab at the bottom of the Navigator pane to reveal the LiveFilter options.

LiveFiltering tab in the navigator pane

To apply a filter for these parameters, click on the "Apply" button in the LiveFilter tab. Upon applying the filter, all filter parameters will be applied at the same time. A transaction must meet all the filter requirements and only those meeting such requirements will appear in the Transaction window.

Filter Apply button in the navigator pane

Instant Filters

Once filters are enabled, it is possible to instantly apply filters to provide immediate feedback to ensure that the correct filter parameters have been set. For data captures larger than 1 GB, there may be a small delay when applying a filter.

Instant filters are controlled by the instant filter toggle button next to the "Apply" button. To activate or deactivate this feature, click on the “lightning” button.

Lighting button in LiveFilter feature

Enabling/Disabling Filters

If a filter is enabled, the enabled button at the bottom of the LiveFilter tab will be active. To enable/disable the filter, click on the “checkmark” button. Any hidden transactions will immediately become visible.

Checkmark button in LiveFilter feature

Editing Filters

You may edit filter settings without applying them by editing the fields of the LiveFilter tab. Clicking the "Revert" button will update the LiveFilter fields with the options from the last filter that was applied, regardless of whether it is currently enabled or disabled.

Revert button in LiveFilter feature

Restoring LiveFilter Defaults

The default filter state matches all packets and does not filter any data from the capture. To restore the default filter state to the LiveFilter tab, click the "Default" button at the bottom of the LiveFilter tab window. Note that the "Default" button only affects the state of the LiveFilter pane and will not apply any settings to the filter.

Restore all filter setting to default settings

The Data Center Software’s LiveFilter feature is one of the most helpful features used to debug and analyze large amounts of bus data, as well as pinpoint areas of interest. This award-winning software combined with our tools has been the preferred protocol analysis solution by developers and their colleagues all over the world. For more information on the Data Center Software or Total Phase tools, please contact us at sales@totalphase.com.

Question from the Customer:

Can you help me use Cheetah Software API commands correctly? I am using the Cheetah SPI Host Adapter running SPI at 1 MHz. I am trying to repeatedly send the target device four bytes of data (4, 41, 0, 0), as shown in the command sequence below.

However, after adding two repeats to the queue and the final batch shift command, the return values are not what I expect.

The first set of four bytes are correct: [0,0,0,172].
However, the second set of four bytes are [0, 0, 0, 0], not the repeated [0,0,0,172] that I expect to see.

If I add the commands Assert SS and Deassert SS between the two groups of the four-byte values during the queue, then the batch shift returns the correct values, [0,0,0,172, 0,0,0,172].

However, using the SS Assert and Deassert commands add an interval of 10 microseconds between sending the two groups of values. I cannot accept this result. That time interval must be no greater than 1 microsecond.

Can you tell me how I can get the send set of four bytes to have the same values as the first set of four bytes? Here are the details, the API command sequences and the output result:

The command sequence:

ch_spi_queue_clear(1)      # Clear the queue first.
ch_spi_queue_oe(1, 1)
ch_spi_queue_ss(1, 0x1)     # Assert SS

ch_spi_queue_byte(1, 1, 4 )
ch_spi_queue_byte(1, 1, 41 )
ch_spi_queue_byte(1, 1, 0x00)
ch_spi_queue_byte(1, 1, 0x00)
ch_spi_queue_byte(1, 1, 4 )
ch_spi_queue_byte(1, 1, 41 )
ch_spi_queue_byte(1, 1, 0x00)
ch_spi_queue_byte(1, 1, 0x00)
ch_spi_queue_ss(1, 0)      # Deactive slave.

(count, data_in) = ch_spi_batch_shift(1,  8 )

print ("\ncount: ", count)
print ("data_in: ", data_in)

The output:

Starting the program ...
creating Cheetah instance ...
connecting Cheetah ...
Opened Cheetah device on port 0
Host interface is high speed
SPI configuration set to spi_mode 0, MSB shift, SS[2:0] active low
Bitrate set to 1000 kHz
byte1: 4,    byte2: 41
self handle: 1
 
count:  8
data_in:  array('B', [0, 0, 0, 172, 0, 0, 0, 0])

Response from Technical Support:

Thanks for your question! The command queue is fine; you only need to “batch” the commands. When using the Cheetah Software API to send SPI data across the bus at high speed, commands are accumulated in a queue until a call is made to batch shift all the queued commands. Here is a summary of sequencing the commands for an SPI transaction queue:

Clear the command queue: ch_spi_queue_clear
Add a command to the queue to enable the Cheetah devices outputs on the SPI bus: ch_spi_queue_oe
Add a command to the queue to enable the slave select signal: ch_spi_queue_ss
Queue the data to be sent across the SPI bus: ch_spi_queue_byte and ch_spi_queue_array
Queue a command to disable the slave select signal: ch_spi_queue_ss

- Optionally, you can call ch_spi_queue_oe to queue a command to disable the outputs of the Cheetah device.

Send the accumulated commands across the SPI bus: ch_spi_batch_shift

In step 4, the ch_spi_queue_byte and ch_spi_queue_array functions execute in a synchronous manner; they are executed sequentially in the order in which they were queued. Each function is executed after the previous line is completed. Processing is not allowed to continue until it returns to the calling thread. For this reason, we recommend using the command for the CS line to rise after the data queues are completed.

For additional information about the Cheetah API SPI transactions, please refer to the section SPI Overview in the Cheetah SPI Host Adapter User Manual.

We hope this answers your questions. Additional resources that you may find helpful include the following:

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo

Question from the Customer:

Our Promira Serial Platform is configured as a slave and is connected to a processor which acts as the master. The master sends 3 bytes of data on the MOSI and later reads 3 bytes and multiple dummy data bytes. The slave must then respond with the 3 bytes and the multiple dummy data bytes. The total bytes are more than 256 bytes.

If we set the slave’s response accordingly using the ps_spi_std_slave_set_resp function from the Promira Software API for I2C/SPI Active, the slave will only send the initial 256 bytes of the buffer repeatedly. Moreover, we are not able to change the slave’s response while transactions are taking place.

Is there a way in which we can send a single response that is composed of more than 256 bytes which are not repeated?

Response from Technical Support:

The buffer size of Promira Serial Platform is limited to 256 bytes. In a single transaction, it is not possible for both the Control Center Serial Software and Promira Software API I2C/SPI Active to send more than 256 bytes of data in a single response.

If there are more bytes than requested in a response, the Promira API ps_spi_std_slave_set_resp function will wrap the response string as many times as necessary to complete the message.

Control Center Serial Software

The Control Center Serial Software lets developers make use of I2C, SPI, and GPIO functionality for our Promira Serial Platform, Aardvark I2C/SPI Host Adapter, and the Cheetah SPI Host Adapter. By using this software, users can emulate a master or slave by writing and reading I2C or SPI messages on the bus.

This software truncates SPI data if it is more than 256 bytes, but it does not wrap the rest of the data in the next transaction since the MISO is set up manually. When "Set MISO" is clicked again, the same data is being treated as new data and hence, the data is being sent from starting location, until the maximum buffer size.

Promira Software API for I2C/SPI Active

In order to send continuous data with data wrapped in the next transaction if data size is greater than read size, we recommend the Promira Software API for I2C/SPI Active. For additional information about the Promira Serial Platform API, take a look at the Promira Serial Platform User Manual.

The API's that fulfill this requirement are:

Set SPI Slave Host Read Size (ps_spi_slave_host_read_size)– This function sets the SPI slave host read size. Instead of waiting for an entire SPI transaction to complete before sending the data to the PC, this function sets a limit for the amount of data to collect before sending it back to the PC. For example, say the host read size is set to 64KB. If the Promira platform receives a large transaction of 1MB from the master, the user will receive the 1MB worth of data in 64KB chunks when calling the ps_spi_slave_read function.
Slave Set Response (ps_spi_std_slave_set_resp)– This function sets the slave response in the event the SPI subsystem is put into slave mode and contacted by a master. Due to limited buffer space on the SPI subsystem, the device may only accept a portion of the intended response. If the value returned by this function is less than num_bytes the SPI subsystem has dropped the remainder of the bytes. If more bytes are requested in a transaction, the response string will be wrapped as many times as necessary to complete the transaction.

We provide downloadable example code in various programming languages such as C, C#, Python, .NET, and VB.NET.

We hope this answers your question. Resources that you may find helpful include the following:

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo

Question from the Customer:

I am using the Beagle I2C/SPI Protocol Analyzer with a PKSA for probing a temperature sensor. I have two questions about viewing and interpreting the captured data.

Question 1 - Scope Capture

Here is a temperature reading and an ID read from the PKSA and the decoded results using the Beagle I2C/SPI analyzer with Data Center Software. Is there a way to see or interpret the details of the scope captured data?

PKSA Reading

Data Center Software Output

Question 2 – Timing Mode

According to the Beagle Protocol Analyzer User Manual, there is section about “Timing Mode”, but I don’t see how to activate it. How can I get the timing mode to display waveforms?

Response from Technical Support:

Thanks for your questions! The output that you provided, Data Center Software Output, reflects the captured data – we will provide details to help you understand the information that is displayed. We will then show you how to easily view the data in digital waveforms.

About the Scope Data

Each byte of the transaction appears as a row in this pane. All the bytes from the transaction are displayed in this pane, including start and stop conditions. The first line of the table (of the ) displays the transaction timestamp as well as the transaction duration. The precision of the timestamp and the transaction is 20 nanoseconds.

Each row contains the following information:

Offset: The offset position of the byte.
Time: The time in nanoseconds from the start of the transaction to the start of the byte.
Value: The hexadecimal value of the byte.
Timing: A graphical display of each individual bit of a byte.
- Each bit is displayed as being either high or low with the time in nanoseconds from the start of the current bit to the start of the subsequent bit. The lengths of the timing blocks in the graph are not drawn to scale; they provide a reference to the relative time scale of one-bit time to the next.
- For the I2C protocol, the timing mode displays 9 bits per line. The ninth bit is the ACK/NACK bit. Please note - depending on the protocol, the bit order may be MSB or LSB. You can determine the bit order by looking at the column label. The text in the label indicates if the data is MSB, shown as (b7...b0) or LSB, shown as (b0...b7). Looking at Data Center Software Output, the data is MSB: Timing (ns): [b7..b0 + ACK]
- (In the case of the SPI protocol, the timing mode displays both MOSI and MISO data.)

Timing Mode for Waveform View

In the Data Center Software, the Timing option of the Details window provides bit-level timing for the data of I2C (and SPI) transactions. This feature is available under Timing Details (select Timing in the Details window). The Details window displays the lower-level detailed information about a specific transaction. An example is shown below.

Digital waveform - a display of captured data with Data Center Software

Data Center Software - Timing of Captured Data

We hope this answers your questions. Additional resources that you may find helpful include the following:

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

The Data Center Software is Total Phase’s free bus monitoring software that is used in conjunction with the line of Beagle Protocol Analyzers, Komodo CAN Duo Interface, USB Power Delivery Analyzer, and Promira Serial Platform with the eSPI Analysis Application. This software provides an interface that is used to capture, monitor, and debug I2C, SPI, USB, USB Power Delivery, CAN, and eSPI communication between devices in real time. Additionally, it allows engineers to gather valuable insights into their embedded systems, providing various details about the devices under test and captured data, including low-level bus events, enumeration details, packet data, bus errors, and much more.

The Data Center Software includes numerous tools within the interface that allow users to review important details regarding the devices and bus data; one of them being the Bus Pane. In this article, we’ll provide an overview of the Bus Pane and how it can be used to gather important information about the bus under test.

About the Bus Pane

The Bus Pane is found in the Navigator window of the Data Center Software and shows the devices that have been detected on the serial bus. It provides detailed device information including addresses, configurations, and endpoint descriptors. Users can view the number of packets and bytes sent and received in real time. The Bus Pane also provides Statistics and Enumeration details of the devices and bus transactions.

Using the Bus Tree

In the Navigator window, I2C, SPI, USB, USB Power Delivery, CAN, and eSPI devices that are detected on the bus are displayed and distinguished by the device IDs or addresses. For SPI devices, all the traffic is lumped into one device per capture since the Beagle I2C/SPI Protocol Analyzer can only monitor one slave select at a time. When performing a simultaneous USB 3.0/2.0 capture, separate bus trees are available for USB 2.0 and USB 3.0 because both buses exists separately, but in parallel.

Example of the Bus Pane

By clicking and expanding a device, a hierarchy of descriptor information will be revealed, including configuration, interface, and endpoint descriptors. Clicking on any level of the tree will show a parsed view of those descriptors and any child descriptors.

The Transactions and Bytes columns list the number of each that have been sent or received from each endpoint, interface, configuration, and entire device.

Right-clicking in the Bus tree will reveal a pop-up menu that gives the user the option to apply a filter so that specific devices can be shown or hidden in the Transaction window. This menu provides the following options:

Filter: Show Only - Only show records of the selected category.
Filter: All Except - Only show records that are not part of the selected category. (Bus Pane Only)
Filter: Disable - Disable the active filter.
Find First - Find the first instance for the selected category. (Statistics Pane Only)
Find Last - Find the last instance for the selected category. (Statistics Pane Only)
Fully Collapse Branch - Collapse the current branch from the selected element down.
Fully Expand Branch - Expand the current branch from the selected element down.
Expand All - Expand the entire statistics tree.
Collapse All - Collapse the entire statistics tree.

This content menu also includes a Manage Configs option where users can manage the configuration information for the device and/or apply a new configuration.

Manage Configs Option in Pop-up Menu

Additionally, users can click on a packet in the Transaction window and the related device will be highlighted in the Bus pane.

Statistics Details

The Statistics Pane provides a real-time count of packets, errors, and other protocol specific constructs as data is being captured. The Statistics Pane is tied to the Bus Pane. When a bus is selected in the Bus Pane, the aggregate of the bus-level data and the bus connected devices data will be displayed in the statistics table. When a device or endpoint is selected, only its data will be displayed.

When the individual statistics are expanded in the Statistics Pane, the sub data will vary, presenting data counts of subcategories of the expanded statistic. If a particular statistic is available for a device and a bus is selected in the Bus Pane, expanding the bottom node of the tree will display data counts for its internal devices.

The Statistic column provides a hierarchical view of all the statistics available. The Available column provides a count of the total number of packets, transfers, and events counted during the capture. If a filter is applied, the Visible column shows the number of packets, transfers, and errors that match the current filter.

By using the Previous and Next buttons, users can quickly jump to a statistic of interest by selecting the category in the Statistics Pane.

Additionally, to download the statistics information for further review, users can click the Save button to save the statistics from the Stats Pane in semicolon-delimited CSV format.

Below are bus statistics that are captured for I2C, SPI, USB, USB Power Delivery, CAN, and eSPI communication.

SPI Bus Statistics Details

I2C Bus Statistics Details

CAN Bus A Statistics Details

CAN Bus B Statistics Details

USB 2.0 Statistics Details

USB 3.0 Statistics Details

eSPI Bus Statistics Details

USB Power Delivery Statistics Details

Enumeration Details

For USB, once devices undergo the entire enumeration sequence, the descriptor information for these devices will be displayed in the Bus Pane. If a capture is stopped prematurely or interrupted, it could result in missing or incomplete descriptor information. In these cases, it is possible to manually apply a device configuration to the device.

For a summary of the descriptor information on specific devices, users can click on the device in the Bus Pane and the Enumeration tab will provide a summary of details for that device. Here, users can view information including the device details, VID, PID, and configurations.

In this example, we can see the device descriptor details for a USB Flash drive:

Example of Enumeration Tab

The Bus Pane in the Data Center Software is a helpful feature for debugging bus communication as it provides insight into the devices detected on the bus and allows users to easily filter for specific devices and its correlating data. This feature also summarizes relevant device descriptor information and other bus statistics that can be useful when analyzing and interpreting the data. For more information on this functionality or the Data Center Software and other Total Phase tools, please contact us at sales@totalphase.com.

Question from the Customer:

Our developers are starting to analyze the interaction between two devices, neither of which has an operating system (OS). One device is a printer. The other device is a medical devic that monitors a hospital patient.

The monitor has an “offline” printing mode and printer drivers that enable it to interact with a printer via USB. This monitor and its drivers have successfully interacted with many brands of computers. One exception is the printer that the developers are troubleshooting.

I am helping the developers find the most cost-effective tool to capture the USB log of the printer. Based on performance and budget, I am interested in two of your analyzers: the Beagle USB 12 Protocol Analyzer and the Beagle USB 480 Power Protocol Analyzer - Standard Edition.

My question - would either of these analyzers work in this scenario? Neither the printer nor the monitoring device has an operating system.

Response from Technical Support:

Thanks for your question! Whether or not the devices that you are monitoring have an OS does not affect the ability of either Beagle USB analyzer to sniff USB data. You can have a non-OS system attached to the Target Device Port or the Target Host Port of the Beagle USB analyzer. The only requirement is connecting the Analysis Port to a platform that can run the Data Center Software.

Recommendations for Capture and Debug

To view, analyze, and capture live USB data through the Beagle USB analyzer, you will need a platform, such as a lab computer, to run the Data Center Software. The Data Center Software is supported on Windows, Mac OS X, and Linux operating systems.

Here is an example of debugging USB in real time.

This video shows how to connect the devices to the host computer Data Center Software, and then capture and filter the USB data for analysis.

USB Analyzers and USB Speeds

The Beagle USB 12 Protocol Analyzer works with Low-Speed (1.5 Mbps) and Full-Speed (12 Mbps) USB. Higher-end products, such as medical monitoring devices, typically operate with High-Speed USB (480 Mbps). For capture data at that speed, we strongly recommend either the Beagle USB 480 Protocol Analyzer or the Beagle USB 480 Power Protocol Analyzer.

We hope that answers your question. Additional resources that you may find helpful include the following:

We also have articles that provide examples of how our products can be used:

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo

Question from the Customer:

I have been using the Beagle USB 480 Power Protocol Analyzer, which has been perfect for measuring VBUS current and voltage, as well as capturing, filtering, and analyzing USB bus data. However, this tool isn’t suitable for my new project, which includes monitoring the delivery of higher levels of power, up to 4A, via USB-C. Is there an upgrade or another analyzer that I can use to monitor and analyze USB Power Delivery?

Response from Technical Support:

Thanks for your question! We have a cost-effective analyzer that is designed specifically for monitoring USB Power Delivery between USB Type-C devices, the USB Power Delivery Analyzer. The following is an overview of the features and usages of this tool.

What the USB Power Delivery Analyzer Provides

The USB Power Delivery Analyzer non-intrusively monitors Power Delivery protocol traffic through a USB Type-C connection. This analyzer is rated for 5A continuous and up to 20V on the VBUS. You can monitor, analyze, test, and confirm the following:

VBUS and VCONN traffic
Power Delivery packages
Power Delivery negotiation
Sink/source level negotiation
Responses from electronically marked cables
Entrance/exit sequences
Sequences during interoperability tests
Switch in Pd/Rp/Pa resistors on configuration channels CC1 / CC2

The USB Power Delivery Analyzer supports USB 2.0 and USB 3.1.

How Do You Use the USB Power Delivery Analyzer?

When used with the Data Center Software (available via free download), you can measure and record the voltage and current on several of the signal lines in the USB Type-C connector. Using the built-in examples of the Data Center Software – before connecting the USB Power Delivery Analyzer or any other devices – you will see realistic instances of how to view and analyze real-time data. To do so:

Install and turn on Data Center Software on your computer.
On the menu, click Help, which opens the Example Captures pop-up window.
To see an example related to USB Power Delivery Analyzer, scroll down to the Power Delivery trace file usbpd-laptop-2-auxmodedevice.tdc.Select that file and click OK.
Select Example in Data Center Software

This trace shows a real-time capture between a USB Type-C SINK and SOURCE, and how the Power Delivery messages are decoded and displayed. This provides an example of what you will see when you start using your devices.
Real-Time Example of PDA Traffic

We also have a video that demonstrates how to set up and use the USB Power Delivery Analyzer.

Information About Power Delivery

In addition to the negotiation between host and target devices, cables are a significant component of USB Power Delivery. Should you need to analyze and evaluate cable performance, take a look at our Advanced Cable Tester v2. With a variety of interchangeable plug-in modules, several types of cables and their connectors can be tested for continuity, signal integrity, DC resistance, and more.

We hope this answers your questions. Additional resources that you may find helpful include the following:

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo

When developing embedded systems, various types of components are used to create a functioning system, including a combination of a computer processor, memory, and input/output peripheral devices. Each embedded system is different and ranges in complexity depending on its desired objective. One of the decisions engineers must make when developing an embedded system is what type of processor or processing system is used to execute computational tasks and manage various components within the system. Two options that are widely used include a microcontroller and an FPGA, or a field programmable gate array.

In this article, we’ll provide background on processors used in embedded systems, the differences between a microcontroller and an FPGA, and the advantages and disadvantages of each.

Processing Systems within an Embedded System

An embedded system is essentially a computer that is designed to control or perform certain functions either by itself or within a larger system. At its core, a processor is used to carry out computations and perform real-time operations.

Different processors or processing systems in embedded systems can include but are not limited to:

Microcontroller: which includes one or more CPUs (central processing units) along with memory and programmable input/output peripherals
Microprocessor: which is also known as a central processing unit that executes and manages the logical instructions
Digital signal processing (DSP): which is used to process digital signals such as image and video
Application-specific integrated circuits (ASIC): which is a microchip designed for a specific application
Field-programmable gate arrays (FPGA): which is integrated circuit designed to be configured by a customer or a designer after manufacturing

Depending on the application at hand, certain ones may be more fitting. Microcontrollers and FPGAs are commonly compared, so we’ll provide insight into each of these and which ones are best for certain usages.

What is a Microcontroller?

A microcontroller is a small computer on an integrated circuit, or chip, that includes a CPU, memory, and peripheral input/output devices. Microcontrollers are programmed to perform a specific task and manage other components within the system, including memory, such as RAM or ROM, and input/output devices that can include LED displays, switches and various types of sensors. In order for the hardware components to function, embedded software is used to provide instructions for the system; microcontrollers are often programmed using higher-level languages such as JavaScript, Python, and C.

Microcontroller

What is an FPGA?

FPGAs are integrated circuits, or ICs, which are sets of circuits on a chip that are designed to be configured by a customer or a designer after manufacturing. FPGA architecture consists of thousands of configurable logic blocks (CLBs) which includes look-up tables (LUTs), flip-flops (FFs) and multiplexers (Muxes). The LUTs are the core of the FPGA that implements Boolean equations and is the primary element that handles logical function.

These CLBs are surrounded by a system of programmable interconnects (switches and wires) that offer connectivity between the CLBs, logic blocks, and input/output (I/O) blocks. The input/output blocks provide the user interface between the FPGA and external devices. All of these components together function as a comprehensive multi-core processor.

When using FPGAs, engineers will program the hardware of the device rather than writing software to run on a predefined processor. FPGAs are primarily programmed using hardware description languages (HDLs).

FPGA Platform; Photo by Sourabh Belekar on Unsplash

Differences Between FPGA and Microcontroller

One of the main differences between a microcontroller and an FPGA is that an FPGA doesn’t have a fixed hardware structure, while a microcontroller does. While FPGAs include fixed logic cells, these, along with the interconnects, can be programmed in parallel by using HDL coding language. This means FPGAs are not predefined and can be altered based on the user’s applications.

Microprocessors on the other hand do have a fixed hardware structure, which means that all of its components, including the processor, memory, peripheral devices, and connections are predefined. By using software, designers can program the processor to perform desired tasks.

Choosing Between FPGA and Microcontroller

So when would one be best over the other? Generally, processors including microcontrollers are more suitable for routine control of particular circuits, such as using a switch to turn on and off a device. FPGAs are suitable for applications that are more customized and require higher processing power or speeds. For example, processing high-resolution video data would be best with a FPGA platform.

Embedded engineers often use microcontrollers in embedded devices as they are easier to program, easier to debug and design, and are often lower cost to implement. However, they lack on the flexibility front. Unlike FPGAs that can allow for reprogramming of hardware/firmware, microcontrollers only allow for reprogramming of firmware, which greatly limits its options for any modifications.

Another benefit of FPGAs is their parallel processing ability, or parallel execution of identical operations. Because of the hundreds or thousands of CLBs processing synchronously, applications including image processing or artificial intelligence are more feasible. Alternatively, microcontrollers perform sequential processing, meaning it reads and processes each line of the program one after the other, which is less powerful in comparison.

While both can be used as the sole processor, it is also possible to implement both a microcontroller and an FPGA within a design concurrently. For example, the microcontroller can be used to perform complex controls while the FPGA performs the functions and does the heavy lifting. By using these both together, developers can take advantage of the processors’ strengths and create robust designs capable of advanced operations.

Tools to Develop and Debug Embedded Systems

Microcontroller-based systems often use I2C and SPI protocols as a means for communication between devices. For embedded systems engineers, debugging and developing such systems wouldn’t be possible without the right tools. Certain tools, including host adapters and protocol analyzers, allow engineers to test systems and gain visibility into the bus.

Host Adapters

Host adapters in particular allow the engineer to emulate master and slave devices and prototype entire systems. By using the tool as a master, users can evaluate peripherals such as sensors and memory chips, and as a slave can test commands sent from MCUs.

Total Phase offers multiple host adapters that suit a variety of I2C and SPI testing and programming applications.

The Aardvark I2C/SPI Host Adapter is Total Phase’s general-purpose host adapter that can be used as an I2C or SPI master or slave device. As an I2C master and slave, it can support up to 800 kHz, as an SPI master it can support up to 8 MHz, and 4 MHz as an SPI slave.

The Cheetah SPI Host Adapter was designed as a high-speed programming device. It can quickly program SPI-based EEPROMs and Flash memory. As an SPI master, it can signal up to 40 MHz.

The Promira Serial Platform is Total Phase’s most advanced serial device. With its FPGA-based platform, users can select from a range of I2C and SPI applications, that provide varying levels of speeds and other functionalities to fit a variety of project requirements. As an I2C device, users can signal up to 3.4 MHz as a master or slave; as an SPI device, users can signal up to 80 MHz as a master and 20 MHz as a slave.

Protocol Analyzers

Protocol analyzers are useful tools to capture and monitor data on the bus, as well as uncover bus errors and their sources. Total Phase also offers protocol analyzers for a variety of different protocols, including I2C and SPI.

The Beagle I2C/SPI Protocol Analyzer allows users to non-intrusively monitor an I2C bus up to 4 MHz and an SPI bus up to 24 MHz.

If you’d like to find out more how our debugging and development tools can benefit your embedded systems designs, please email us at sales@totalphase.com.

Question from the Customer:

I just purchased a Beagle USB 12 Protocol Analyzer. I am using it to debug and sniff USB 2.0 Flash drives. I installed the drivers and the Data Center Software, but I am having problems. When I start a capture and insert a USB Flash drive, I only see the following:

Trying to Monitor a Full-Speed Device with a Low/High-Speed Analyzer

I can see no signals and no packets. I only see "Target Connected" and "Target Disconnected". When I plug in another type of USB device, such as a mouse or a USB-to-serial converter, I can capture and view signals and packet information, which is what I expect. Also, I have tried the Beagle USB 12 analyzer on three different computers, and for each setup, the results are the same.

What am I doing wrong? For budget reasons, I really want to make this work.

Response from Technical Support

Thanks for your question! The Beagle USB 12 Protocol Analyzer is a Low-Speed/Full-Speed device that only tracks Low-Speed and Full-Speed USB traffic. Here are the three speeds of USB 2.0 devices:

High-Speed: 480 Mbit/s
Full-Speed: 12 Mbit/s
Low-Speed: 1.5 Mbit/s

Which USB Protocol Analyzer Do You Need for Which Target Device?

The devices that you successfully monitored are Low/Full-Speed USB devices. A USB 2.0 Flash memory, however, operates at High-Speed USB, which is beyond the parameters of the Beagle USB 12 analyzer. The Beagle USB 12 Protocol Analyzer is really great for a variety of HID devices such as mice and keyboards, but it does not work for the USB devices that operate in High-Speed mode.

To monitor and capture High-Speed data traffic, you could use one of the following USB protocol analyzers:

Beagle USB 480 Protocol Analyzer
Beagle 480 Power Protocol Analyzer, Standard Edition or Ultimate Edition
Beagle USB 5000 v2 SuperSpeed Protocol Analyzer, Standard Edition or Ultimate Edition

Of these protocol analyzers, the Beagle USB 480 Power Protocol Analyzer could be your “go-to” tool. It offers class-decoding, triggers, and filtering with the deepest USB 2.0 High Speed hardware buffer in our tools. For an easy comparison, take a look at our product guide, which summarizes the features of our USB protocol analyzers and other devices.

If you really need to use the Beagle USB 12 Protocol Analyzer for High-Speed devices, there is a way to see the traffic. However, it will be without the benefits of full class-level decoding, triggering, and other advanced features provided by our High-Speed USB protocol analyzers.

The class-level decoding feature of the Data Center Software does provide real-time USB descriptor decoding for data captured with a Beagle USB 12 Protocol Analyzer. However, full class-level decoding is only available with the Beagle USB 480/5000 protocol analyzers.

What Is the Speed of Your Target Device?

If you are uncertain of the speed of the target device, the easiest method to find the device speed is using the USB Device Tree Viewer. When you run the USB Device Tree Viewer, you will see a list of USB Host Controllers. By cycling through each port of the USB Root Hubs attached to the controllers, you will see what is connected to that port. Each USB device that is connected to your computer (mouse, Wi-Fi or Bluetooth adapter, webcam, and so on) will be displayed on one of those ports. It will also show the Device Bus Speed.

The speed values can be displayed as follows:

0x01 (Full-Speed)
0x02 (High-Speed)
0x03 (SuperSpeed)

Monitoring High-Speed Data with Low/Full -Speed Analyzer

If necessary, there is a short-term workaround that could work for you. To buffer and slow down the data traffic to where the Beagle USB 12 Protocol Analyzer could capture the data, place a Full-Speed USB 1.1 hub between the target device and the Beagle USB 12 analyzer. For extended periods of work and detailed analysis, you may find using one of our High-Speed USB protocol analyzers more effective and more efficient.

We hope this answers your question. Additional resources that you may find helpful include the following:

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

The Data Center Software is Total Phase’s free bus monitoring software that is used with our line of protocol analyzers and offers a variety of ways to monitor and debug data in real time. A feature that engineers often find beneficial is the ability to interface with the software through a command line. In this blog, we will discuss what the command line is and how to use the Command Line Window in the software. But first, we will provide a brief overview of the Data Center Software.

About the Data Center Software

These protocol analyzers, including the line of Beagle Protocol Analyzers, USB Power Delivery Analyzer, Promira Serial Platform, and Komodo CAN Interfaces, are used in conjunction with the Data Center Software, which provides an interface to capture and display USB, I2C, SPI, USB Type-C Power Delivery, eSPI and CAN bus data. The Data Center Software is the only protocol analysis software in the industry with true, real-time performance and cross-platform support for Windows, Linux, and Mac OS X.

The software is packed with useful and time-saving features. One of the features that users find beneficial is the Command Line Window.

Command Line Window

Because the command line is a commonly used interface by those with a technical background to instruct the computer to perform specific tasks, this capability is also included directly in the Data Center Software itself.

While the Data Center Software provides users with easy-to-use features to interface with their application, the Command Line Window provides an alternative method to interact with the Data Center application. All operations that can be done through interfacing with the software directly can also be done via the command line. When an operation is performed in the application, its corresponding command line input is displayed in the command line output and added to the command line history. By using the arrow keys in the command line input box, users can scroll back through the command line history and edit or repeat previous commands.

Command Line Window

What are the Commands?

When interfacing with a command line, it is important to know what commands need to be used. To make it easy, the Data Center Software includes a library of accessible commands directly in the command line itself. To view all available commands, type “help” into the command line. If you would like additional help on a certain command, simply type “help COMMAND” to see help for a particular command.

Command Line "help" interface

When the command line input is in focus, pressing the escape key once will clear the command line input box, and double pressing the escape key will clear the command line output and history.

What Languages Can be Used in the Command Line Window?

The Command Line Window uses the Python syntax and behaves similarly to the command line found in the Python interpreter. This means that local variables can be defined and control structures can be used as well. The arguments passed to the Data Center Software commands are generally singleton values (such as integers, strings, or True/False), lists, or dictionaries. For more information on Python syntax and data structures, please refer to the Python website.

How to Enable the Command Line Window

To enable the command line in the software, users can simply navigate to the top menu panel.

Data Center Software top menu panel

Once there, navigate and click on the “Command Line” button.

Command Line button in the top menu panel

Once enabled, users will see the Command Line Window become available at the bottom of the Data Center Software screen.

Command Line Window in the Data Center Software

Additional Command Line Options

Users can also launch the Data Center application from the command line and perform many of the same functions as within the Command Line Window directly. This can be done by using the script located in the bin directory in the software package. Users can perform the following options:

-b FILE, Run the given file in batch mode.
-c, Create a command line interface.
-m, minimized, Start in a minimized state.
-r PORT, Create a remote console on the given TCP port.

Batch Mode

While users can use the Command Line Window to consecutively execute different functions of the Data Center Software, users can also execute batch scripts in the command line to automate such operations. Instead of having to manually set up the software to meet the needed criteria, users can simply execute the script as needed. The -b FILE option allows for the specified file to be run in batch mode when the Data Center application is launched. The file can contain commands in the same format as those entered in the Command Line Window

Command Line Console

Users that have launched the Data Center Software using the command line can also create a command line console in this location. This can be executed by using the -c option. Commands that can be entered in the Command Line Window can also be entered in the console.

Minimized State

Using the -m or minimized option will launch Data Center in minimized mode. This allows users to launch the application, use the Command Line Console, and never see the GUI on screen.

Remote Console

The -r PORT option will create a remote console on the given port. Connecting to this port via Telnet will give the user a command line console similar to the one found in the Command Line Window. This allows users to control the Data Center application from a remote location.

Summary

The Command Line Window is a useful feature when it comes to interfacing with our Data Center software. It is easy and intuitive to use and enables a more standard and familiar way to interface with the software. For more information on the Command Line or other Total Phase related solutions, please contact us at www.totalphase.com.

Question from the Customer:

I have a project that includes the Touch IC of a touch-screen tablet. Looking at your online store, the Aardvark I2C/SPI Host Adapter and the Aardvark Software API look promising. Many of the tools that you provide seem to focus on EEPROMs. Many of the operations to apply to a Touch IC will be similar, but I will need other features, such as touch interrupts and other interactions. Are other API examples available? If not, how easy is it to create what I need?

Response from Technical Support:

Thanks for your question! Each API example can be used as is or modified for your specifications. In addition, each API example consists of independent “sub-functions” that can be used to create new applications. We will provide an on overview about using the API in the following sections.

Examples of API Programs

Following is a list of the examples of Aardvark API that could be useful for your project. Some of these functions operate with Accessory Boards that are often used for prototyping, as well as testing and troubleshooting API programs.

aadetect: Detect Aardvark host adapters that are attached to the system.
aalights: Flash LEDs that are attached to a Philips PCA9554D I/O port expander as found on the I2C/SPI Activity Board.
aai2c_eeprom: Read from or write to an I2C serial EEPROM, such as the Atmel AT24C02 on the I2C/SPI Activity Board.
aaspi_eeprom: Read from or write to an SPI serial EEPROM, such as the Atmel AT25080A found on the I2C/SPI Activity Board.
aai2c_file, aai2c_slave: Demonstrate the I2C slave functionality of the Aardvark device. This example requires two Aardvark host adapters.

Run aai2c_slave with the first Aardvark host adapter to wait for a new slave transmission.
In another shell, run aai2c_file to transmit a binary file with the second Aardvark host adapter.

aaspi_file, aaspi_slave: Demonstrate the SPI slave functionality of the Aardvark host adapter. This example requires two Aardvark host adapters that will be managed in two separate shells.
1. Run aaspi_slave with the first Aardvark host adapter to wait for a new slave transmission.
2. In another shell, run aaspi_file to transmit a binary file with the second Aardvark host adapter.
aagpio: Perform simple GPIO tests with a single Aardvark host adapter. The results can be verified using an oscilloscope or a multi-meter.

Getting Started with GPIO Features

To become more familiar with the GPIO features of the Aardvark I2C/SPI Host Adapter, the Aardvark Software API, and the Control Center Serial Software, we recommend the following quick start:

Install the Control Center Serial Software.
Make sure the Aardvark adapter is not connected to your target device.
Connect the Aardvark adapter to the computer and open the Control Center Serial Software.
Using the Control Center Serial Software GUI, connect to the Aardvark adapter and select the GPIO only mode.
1. Ensure the I2C Pull-ups are disabled in the Aardvark menu.
Set all the directions to OUT and set all the outputs to logical 0. Using a meter, verify that all the pins output 0V.
Set all the outputs to logical 1, and verify that the pin outputs 3.3V.
Do similar testing with the input pins, such as send a 3.3V or 0V signal to each input, then verify that the Aardvark host adapter detects the signals correctly.

Sending Interrupts via GPIO

You can use the GPIO feature of the Aardvark I2C/SPI Host Adapter to send interrupts. In our Knowledge Base, we provide an example of using API commands to send interrupts to the host computer. For details, please refer to the article Using the Aardvark I2C/SPI Host Adapter GPIO Feature to Support Interrupts. For details about the Aardvark host adapter signal pins, please refer to the section Hardware Specifications of the Aardvark I2C/SPI Host Adapter User Manual.

Configuring the Aardvark I2C/SPI Host Adapter

When using API, you often need to configure the Aardvark I2C/SPI Host Adapter. To do so, use aa_configure() . This “sub-function” is applied in many API examples.

def aa_configure (aardvark, config):

"""usage: int return = aa_configure(Aardvark aardvark, AardvarkConfig config)"""
if not AA_LIBRARY_LOADED: return AA_INCOMPATIBLE_LIBRARY
# Call API function
return api.py_aa_configure(aardvark, config)

Placing Libraries for a Correct Build

Here is a hint for “getting it right” the first time. Each executable\binary file depends on some libraries of the solution. Set up correctly, everything builds upon each other in the first build. To ensure the final build can address the libraries, copy all of the dependent dll files into the executable bin folder.

We hope this answers your questions. Additional resources that you may find helpful include the following:

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo

Total Phase offers embedded systems engineers a wide variety of hardware tools to debug and develop embedded systems including host adapters and protocol analyzers supporting I2C, SPI, USB, and CAN protocols. By using such tools, engineers can emulate and test systems as well as monitor bus traffic in real time, ensuring systems are operating properly without errors.

In addition to protocol analyzers and host adapters, Total Phase offers numerous development boards that can be used alongside these tools to assist engineers with their testing and debugging efforts. These boards offer various known-good target devices that make narrowing down on bugs easier and allow developers to get up and running more quickly.

Find out more about the various development boards offered and how their assortment of built-in target devices can help streamline testing and debugging of various embedded systems.

CAN/I2C Activity Board Pro

The CAN/I2C Activity Board Pro provides developers with known-good target devices that can operate as I2C slaves or CAN nodes. The varying target devices included on the board offer numerous ways to test and verify I2C and CAN systems and include: Digital-to-Analog Converter (DAC), Motion Sensor, Light Sensor, GPIO Port Expander, Joystick/LEDs, ADC/LCD, and Temperature Sensor.

This board can be operated by the Komodo CAN Duo Interface and the Aardvark I2C/SPI Host Adapter.

Digital-to-Analog Converter (DAC)

The Digital-to-Analog Converter (DAC) is single-channel 8-bit. It can drive its output between 0V and VDD, with a precision of approximately 12.9 mV. It can communicate directly over I2C or over CAN through the bridge.

Motion Sensor

The motion sensor is a 3-axis linear accelerometer. It can communicate directly over I2C or over CAN through the bridge.

Light Sensor

The light sensor converts light intensity (irradiance) into a 16-bit digital signal. It can communicate directly over I2C or over CAN through the bridge.

GPIO Port Expander

The GPIO Port Expander is an 8-pin port expander which can be accessed through CAN or I2C.

Joystick/LEDs

The joystick and LEDs are connected to a port expander. The microcontroller communicates with the joystick and LEDs through this port expander. The two-axis joystick has five output pins (up, down, left, right, and select) which are asserted high when the joystick is moved to that position. There are three active high LEDs controlled by the port expander: D201, D202, and D303.

ADC/LCD

The CAN Bridge MCU has a built-in ADC which is exposed on the PCB. The board allows the user to read three of these analog inputs with an 8-bit resolution. Inputs may range from 0 V to a maximum of 3.3 V. The LCD is a 2x8 character display that is connected to the CAN bridge over a parallel bus. The characters on the display are ASCII-encoded.

Temperature Sensor

The temperature sensor provides temperature readings over a range of -55°C to +125°C. It can communicate directly over I2C or over CAN through the bridge.

To see how the Komodo CAN Duo Interface can write to and interact with the board as well as monitor the activity, take a look at our video Using the Komodo GUI Software to Interface with the CAN/I2C Activity Board Pro.

Example code for the CAN/I2C Activity Board Pro are available in C, C#, Python, .NET, VB.NET, and VB6 as part of the API package of your host adapter.

For more detailed technical information regarding the CAN/I2C Activity Board Pro, please find the User Manual.

I2C/SPI Activity Board

The I2C/SPI Activity Board is a beneficial tool for engineers developing I2C and SPI systems as it allows users to easily program and test systems against known-working I2C and SPI slave devices. By doing so, this simplifies debugging processes by helping users better differentiate between hardware and software bugs and can even be used to quickly verify a system setup before running extensive tests. Additionally, for the novice embedded engineer, this board can provide insight into the mechanics of the I2C and SPI protocols.

This board offers three different known-good I2C and SPI target devices for testing and development including an I2C Port Expander, an I2C EEPROM, and an SPI EEPROM.

I2C Port Expander

The I2C Port Expander is an 8-bit I2C and SMBus I/O port with interrupts that includes configurable I2C address and full complement of LEDs.

I2C EEPROM

The I2C EEPROM is a 256 Bytes/2 Kilobit (8-byte pages) Two-Wire Bus Serial EEPROM that includes a configurable I2C address.

SPI EEPROM

The SPI EEPROM is 1 Kilobyte/8 Kilobit (32-byte pages) SPI Bus Serial EEPROM and supports SPI Mode 0 and 3; it includes jumpered Slave Select.

The board includes two connections that are used to connect two host adapters including the Aardvark I2C/SPI Host Adapter. Pass-through pins are also included for connecting an external bus monitor or protocol analyzer.

Example scripts for communicating with the target devices can be found in the API package of your Total Phase host adapter.

For more detailed technical information regarding the I2C/SPI Activity Board, please find the User Manual.

High-Speed SPI Flash Demo Board

High-Speed SPI Flash Memory

The High-Speed SPI Flash Demo Board is a useful development tool for those working with High-speed SPI Flash memory or developing High-speed SPI systems. This board comes equipped with a known-good target memory device that is capable of communicating up to 50 MHz. By connecting either host adapters and protocol analyzers to the board, users can easily program the target device and test certain slave responses or other activity.

With the board’s two I/O connectors, users can connect up to two different devices, including a Cheetah SPI Host Adapter, an Aardvark I2C/SPI Host Adapter, or a Beagle I2C/SPI Protocol Analyzer. For example, a Cheetah SPI Host Adapter can be connected to the board to interface with the SPI Flash Memory and a Beagle I2C/SPI Protocol Analyzer can also be attached to monitor the bus.

Sample code for the Cheetah SPI Host Adapter can be found in the API package. While not all examples will work with the High-Speed SPI Flash Demonstration Board, the flash.c example code was specifically developed against this target.

For more detailed technical information regarding the High-Speed SPI Flash Demo Board please see the User Manual.

Level Shifter Board

The Level Shifter Board is an easy-to-use, cost-effective tool that allows users to interface Total Phase products, including the Aardvark I2C/SPI Host Adapter, the Beagle I2C/SPI Protocol Analyzer, and the Cheetah SPI Host Adapter, with lower logic level devices.

The board provides level shifting capabilities for I2C, SPI, MDIO, and GPIO signals. It includes an on-board regulator to specify and power downstream devices to all standard logic levels including 1.2 V, 1.5 V, 1.8 V, 2.5 V, 3.0 V, and 3.3 V.

For I2C communication, the Level Shifter Board supports speeds up to 800 kHz. While maximum SPI and MDIO signaling rates are dependent on specific board configurations and timing specifications, the board can generally support up to 18 MHz when shifting to 1.2 V, and up to 20 MHz when shifting to 3.3 V.

The board contains two connectors which are used to connect different devices including the Aardvark I2C/SPI Host Adapter, Cheetah SPI Host Adapter, and/or Beagle I2C/SPI Protocol Analyzer. Users can connect multiple host adapters to the board via the two connectors if desired.

For users looking for a host adapter that includes built-in level shifting capabilities, please take a look at the Promira Serial Platform.

For more detailed technical information regarding the Level Shifter Board please see the User Manual.

With a variety of hardware tools and supporting development boards, embedded systems engineers can rely on Total Phase for go-to debugging and development solutions. If you have any questions on how our development boards can help streamline your own projects, please email us at sales@totalphase.com

Lab equipment for troubleshooting and analyzing data waveforms

Source: Pexels

Question from the Customer:

I am troubleshooting the serial bus of a system with an oscilloscope. In addition to the electrical characteristics, I need more details to understand the performance of the system. I am looking at the Beagle I2C/SPI Protocol Analyzer – what details can it provide me about waveforms?

Response from Technical Support:

Protocol analyzers and oscilloscopes are essential debugging tools. They differ significantly in usage and application, such as the low-level and high-level attributes of signals. We will begin with an overview of the technical benefits of each tool, and then go into the details of what a protocol analyzer provides.

Oscilloscopes

Oscilloscopes are useful for debugging systems, especially for electrical issues just as jitter, noise, signal to noise ratios, and other signal distortions. This visual diagnostic can be a quick diagnostic, shedding light on some of the most crucial parameters of low-level signal conditions.

Unlike oscilloscopes, protocol analyzers, like the Beagle I2C/SPI Protocol Analyzer, allow designers and developers to debug their embedded systems at a much higher level of signal data. For analyzing data traffic, protocol analyzers provide significant information.

Protocol Analyzers

There are two forms of protocol analyzers: software and hardware.

A software analyzer offers an economic advantage. Its limitation is within the capabilities of the host computer’s hardware.
A hardware analyzer can debug embedded hosts, providing visibility to issues related to timing, transmission, and speed negotiation.

Analyzing Data Packets

An advantage of using protocol analyzers is allowing developers to view data in the form of packets, not just individual bit streams. Protocol analyzers also offer a real-time display of captured data, which can speed up the process of debugging a system.

Some ability of frequency measurement is available through the Timing Details window of the Data Center Software, an application that displays the data captured by a Beagle protocol analyzer. The Details window (Detail->Timing) provides lower-level detailed information about a transaction, which is described in the following sections.

Bit-Level Timing

The Timing pane of the Details window provides bit-level timing for the data of I2C and SPI transactions. Each byte of the transaction appears as a row in the Timing pane. All the bytes from the transaction are displayed in this pane, including start and stop conditions. The first line of the table displays the transaction timestamp as well as the transaction duration, both to nanosecond precision.

Viewing waveforms via Data Center Software

Data Center Software Timing Pane

Each row contains the following information:

Offset: The offset position of the byte.
Time: The time in nanoseconds from the start of the transaction to the start of the byte.
Value: The hexadecimal value of the byte.
Timing: A graphical display of each individual bit of a byte. Each bit is displayed as either high or low with the time in nanoseconds from the start of the current bit to the start of the subsequent bit.

Please note - the lengths of the timing blocks in the graph are not drawn to scale. They show the relative timing of one bit to the next. Depending on the protocol, the bit order may be MSB or LSB. The column label shows the bit order: MSB (b7...b0) or LSB (b0...b7).

For the I2C protocol, the timing mode displays 9 bits per line. The ninth bit is the ACK/NACK bit.
For the SPI protocol, the timing mode displays both MOSI and MISO signals.

For more information about the advantages of protocol analyzers, see this article Protocol Analyzer: Must-Know Advantages for Embedded Systems.

Here is an example of using an Aardvark I2C/SPI Host Adapter with the Beagle I2C/SPI Protocol Analyzer for prototyping.

We hope this answers your question. Additional resources that you may find helpful include the following:

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

The Total Phase Data Center Software is a free software interface that allows users to seamlessly monitor traffic occurring on USB, CAN, I2C, SPI, and eSPI buses. The software provides a variety of different ways to debug and analyze data and has become a familiar tool to engineers across the world. A feature that users often find beneficial is the Capture Control window. In this article, we will provide insight into the Capture Control window, including how it’s used and its different features. First, we will provide a brief overview of the Data Center Software.

About the Data Center Software

The Data Center Software is a bus analyzing software that can be used to interface with Total Phase protocol analyzers. These protocol analyzers, including the line of Beagle Protocol Analyzers, USB Power Delivery Analyzer, Promira Serial Platform with the eSPI Analysis Application, and Komodo CAN Duo Interface, are used in conjunction with the software to capture and display USB, I2C, SPI, USB Power Delivery, eSPI ad CAN bus data. The Data Center Software is easy to use and is the only protocol analysis software on the market with true real-time capture and support for Windows, Linux, and Mac OS X.

The Data Center Software is packed with time-saving and useful features, including the Capture Control window.

Capture Control Window

The Capture Control window provides users a way to see real-time statistics of the ongoing capture, as well as the ability to start and stop the capture.

Capture Control Software Capture Buffer

Software Capture Buffer

Within the Capture Control window is the “Software Capture Buffer” progress bar. This bar represents the total amount of memory available for use from the analysis PC.

When a capture is initiated, the Software Capture Buffer progress bar will begin to fill up with a solid green bar, which indicates the amount of memory used by the Data Center Software. Once this progress bar is completely green, the capture will automatically stop as this means the capture data limit has been reached. A timer is located at the bottom right-hand corner and indicates the time elapsed since the capture was started.

Data Center Software’s capture buffer is reliant on the analysis PC’s onboard RAM. By using the Capture Control settings dialog, users can adjust the data capture limit. Within these settings, the capture data limit must be at least 16 MB and no greater than 80% of available system memory. By default, the capture limit is set to 50% of available memory. Total Phase recommends using caution when setting the capture limit above the upper limit amount. On an extremely busy computer, the capture limit should be set even lower. If the application starts swapping memory, incoming capture data may be lost.

Button Controls

The Capture Control dialog provides various ways to interact with and control the capture:

Start Capture

Start Capture

The "Start Capture" button can be used to start the capture.

Manual Trigger

Manual Trigger

The "Manual Trigger" button is used to manually trigger the capture.

Stop Capture, Download Data

Stop Capture Download Data

The "Stop Capture, Download Data" button is used to stop the capture and to continue to download all captured data. This button is only available when using the Beagle USB 480 Power Protocol Analyzer or the Beagle USB 5000 v2 SuperSpeed Protocol Analyzer.

Stop Capture, Stop Download

Stop Capture Stop Download

The "Stop Capture, Stop Download" button is used to stop the capture and to immediately stop downloading data.

USB 3.0 Capture Settings

The Capture Control window discussed above is the standard control window that most users will interface with. However, when using the Beagle USB 5000 v2 SuperSpeed Protocol Analyzer, additional features will appear.

USB 2.0 and USB 3.0 Progress Bars

The Capture Control window for a Beagle USB 5000 v2 SuperSpeed Protocol Analyzer is more complex and adds two additional progress bars alongside the Software Capture Buffer:

The "USB 3" progress bar displays the status of the USB 3.0 hardware memory buffer on the Beagle analyzer
The "USB 2" progress bar displays the status of the USB 2.0 hardware memory buffer on the Beagle analyzer.

Capture Control 2.0 and 3.0 progress bars

If the Beagle USB 5000 v2 analyzer is configured to only capture USB 3.0 data, the "USB 2" progress bar will be disabled and vice versa. Both the "USB 3" and "USB 2" progress bars behave similarly.

The entire progress bars represent the total amount of memory available. White areas indicate the amount of memory apportioned for the pre- and post-trigger buffer, which can be defined in the “Device Settings”. Gray areas indicate memory that is not accessible or not in use, which can occur when the capture buffer is set to limited. For infinite captures, the entire status bar is used. When memory is used for the capture, the white areas are filled with orange (pre-trigger data) or blue (post-trigger data).

Once a capture starts, the pre-trigger buffers will fill and the orange bar in the progress bar will grow. The pre-trigger buffer is a circular buffer and will only fill up to the limit set in the “Device Settings”.

Filling Pre Trigger progress bar

When the capture trigger occurs, several things happen simultaneously. The pre-trigger (orange) buffer will stop being filled, the post-trigger (blue) buffer will start being filled, and the analyzer will start streaming the data to the analysis PC.

Since the pre-trigger buffer has stopped, the orange bar will stop growing, and any remaining white areas will be filled with gray to indicate that the pre-trigger memory is no longer available since the pre-trigger capture is complete. The orange buffer will be replaced with gray as the pre-trigger data is streamed off the analyzer. The pre-trigger capture is complete when all the orange has been replaced by gray, indicating that all the data has been downloaded to the analysis PC.

Downloading Post Trigger progress bar

While the pre-trigger data is downloading, the post-trigger buffer will fill and the blue bar in the progress bars will grow. Once all the pre-trigger data has been downloaded, the post-trigger data will start being streamed off which will result in the blue buffer being replaced with gray.

The post-trigger will continue to fill until the capture reaches its set limit, the analysis PC runs out of memory, or the user stops the capture. Once the capture stops, any remaining white areas will be replaced with gray. The remaining data will download off the analyzer until the progress bars are completely gray, indicating that all data has been downloaded from the buffers.

Software Capture Buffer Green Status Bar

Once data starts downloading to the analysis PC, the "Software Capture Buffer" will start to fill with green.

Additional Button Controls

In addition to the progress bars, new controls for the Beagle USB 5000 v2 SuperSpeed Protocol Analyzer are available in the Capture Control window as well.

Target Power

Target Power

The "Target Power" button is used to toggle whether V_BUS is passed to the target device or not. This has the same effect as pressing the Target Power button on the front of the Analyzer. When V_BUS is being passed to the target device, the button will be green. When V_BUS is not passed through, the button will be red.

Receiver Termination

Receiver Termination

The “Receiver Termination” button is used to configure the receiver detection system. When the button is clicked, a pull-down menu provides the ability to set automatic receiver detection or to force receiver termination to be either on or off in either the upstream (UP) direction, downstream (DS) direction or both directions. This button is only active when using a Beagle USB 5000 analyzer to capture USB 3.0 data.

Data Scrambling

Data Scrambling

The "Data Scrambling" button is used to configure the data scrambling detection. When the button is clicked, a pull-down menu provides the ability to set automatic data scrambling detection or to force data scrambling to be either on or off in either the upstream (UP) direction, downstream (DS) direction or both directions. This button is only active when using a Beagle USB 5000 analyzer to capture USB 3.0 data.

Polarity Detection

Polarity Detection

The "Polarity Detection" button is used to configure the polarity detection. When the button is clicked, a pull-down menu provides the ability to set automatic polarity detection or to force polarity to be either inverted or non-inverted in either the upstream (UP) direction, downstream (DS) direction, or both directions. This button is only active when using a Beagle USB 5000 analyzer to capture USB 3.0 data.

See our video: Managing your USB 3.0 capture with Capture Control in Data Center Software to learn more:

For additional information and complete details on using the Capture Control window, please visit the Data Center Software User Manual.

Summary

As you can see, the Capture Control window provides users with a plethora of capture-related controls. This window gives users a quick overview of what is happening with the ongoing capture, enabling greater insight and understanding into the bus trace. For more information on the Capture Control window or other Total Phase solutions, please contact us at sales@totalphase.com.

Question from the Customer:

I have a question about using the Beagle I2C/SPI Protocol Analyzer. I am testing SPI devices. I have two sets of data which are shown below. I am using the Control Center Serial Software for viewing and analyzing the captured data.

Comparing new and old data:

The old data shows errors. I have personally confirmed there was a buffer issue in the devices being tested. That issue should have been resolved. However, after making that correction, the new data shows that some of the buffering is still incomplete.

Old Captured Data

New data captured from Beagle analyzer displayed on Control Center Serial Software

New Captured Data

The Device Settings that I selected:

The settings the customer selected on Data Center Serial Software for the Beagle protocol analyzer

Data Center Serial Software – Device Settings

My question - can you check if I made the correct settings for my Beagle I2C/SPI Protocol Analyzer? Also, are there other setup factors that I should look into? I want to make sure the data readings are correct before I initiate more troubleshooting with the SPI devices.

Response from Technical Support:

Thanks for your questions! Most of your setup is correct – there is one change we will suggest. In addition to going over your configuration settings for your test setup, we will provide details about the transaction log data.

About Partial Errors

In the Error column of the Data Center Software Transaction Log, P1, P3, P3 … P7 are indications of Partial last byte errors.

As the analyzer operates at a byte level, the P error shows that the analyzer did not capture an entire byte.
The number following the P represents how many bits of the last byte were captured.

The Beagle I2C/SPI analyzer uses the SPI slave select line to frame each transaction. For example, if the Beagle I2C/SPI analyzer sees one bit and then sees the slave select line go inactive, the rest of the byte will be padded with 0s.

In summary, the partial last byte occurs when the last byte in the data buffer is incomplete. This occurs when the number of bits of data captured did not adhere to the expected data size. This can occur for various reasons, which we will discuss in the following sections.

Optimizing the Setup

Sampling rates can greatly affect the results of the captured SPI data. There are three different sampling rates that can be used to monitor the SPI bus. It appears that you selected 20 MHz. As a rule of thumb, we recommend selecting a sampling rate that is at least four times faster than the data rate of the monitored bus. For your case, we recommend increasing the rate to 50 MHz and retrying your setup.

Cabling and Signals

We recommend using short I2C/SPI cables, about 5” in length. A longer cable length can adversely affect the signal integrity and the operational speed. The SPI (and the I2C) bus does not have any inherent distance capability. Because of that, excessive cable length can easily corrupt the signals being tested, causing any number of problems including partial data size errors.

We hope this answers your questions. Additional resources that you may find helpful include the following:

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo

Flash memory is often used in embedded systems as a means to store data and information, providing the system with the needed instructions to operate. Two of the most widely used types of Flash memory include NOR and NAND Flash. In this article, we’ll discuss the key differences between NOR and NAND Flash, as well as some advantages and disadvantages of each.

What is Flash Memory?

Flash memory is a non-volatile memory storage device that can be electrically erased and reprogrammed. Non-volatile memory means that the memory device will retain the stored data even when the system is powered off. One of the reasons that Flash memory is often used in embedded systems is its ability to erase data in blocks rather than by individual bytes. Because Flash memory needs to be erased before it can be programmed, this helps expedite the process and allows for faster programming.

There are several different types of Flash memory, but the most commonly used include NOR and NAND Flash. Both of these types of Flash memory store data in memory cells made from floating gate transistors. NOR and NAND Flash get their names from the type of logic gate used in the cell and differ through their architecture and purpose.

NAND and NOR Flash Architecture and Purpose

NOR flash is optimized for random access capabilities, which means it is capable of accessing data in any order and does not require following a sequence of storage locations. In its internal circuit configuration, each of NOR Flash’s memory cells are connected in parallel; one end of the memory cell is connected to the source line and the other end is connected to the bit line. Because of this, the system is able to access individual memory cells.

NAND Flash, on the other hand, is optimized for high-density data storage and gives up the ability for random access capabilities. Unlike NOR Flash, NAND Flash cells are connected, usually eight memory transistors at time, in a series to the bit line called a string. Here, the source of one cell is connected to the drain of the next one. This series connection reduces the number of ground wires and bit lines, and as a result of this configuration, NAND has a smaller cell size. This does not however allow for direct access to individual cells.

Advantages and Disadvantages of NOR and NAND Flash

Memory Capacity and Size

Because NAND Flash offers higher densities, it is capable of much higher memory capacities. This gives it an advantage for data storage applications such as Flash drives, digital cameras, and USB drives. Because of its higher densities, NAND has a smaller memory cell size and is able to scale.

USB Flash Drive

Conversely, NOR Flash offers a lower density and therefore has a lower memory capacity compared to NAND. This makes NOR Flash more appropriate for low-capacity and high-reliability applications, such as storing code in devices including cell phones or medical devices. Additionally, NOR has a larger memory cell size which limits its scaling capabilities compared to NAND.

Write/Erase/Read Performance

The architecture of NOR and NAND Flash affect how each perform when writing, erasing, and reading data. Because NOR Flash memory cells are connected in parallel and can be accessed directly, this enables short read times. However, due to NOR Flash having a larger cell size and its more complicated erasure process, this affects its ability to write and erase as quickly compared to NAND.

On the other hand, NAND’s memory cells are connected in a series which are organized into pages which are then sub-organized into blocks. NAND reads are slower since it supports page and block access, not random access where it can read each byte individually. However, NAND writes and erases are quicker than with NOR.

Power Consumption

In terms of power consumption, NOR requires more current when it is first powered on, but requires less power for standby. Conversely, NAND requires less power to start up, but more for standby power. However, both NOR and NAND both are comparable in its instantaneous active power, but this can vary depending on how the memory is used. For instance, NOR is typically slow on writes and consumes more power than NAND. NOR is typically fast on reads, which consume less power.

Cost

Due to its smaller size and high-density configuration, NAND has a lower cost per bit compared to NOR Flash.

Summary

In summary, NAND Flash offers high storage density and a smaller cell size. With its low-cost, high-density, high-speed program/erase applications, NAND is often preferred for file storage in consumer applications. NOR Flash offers a much faster read speed and random-access capabilities, making it suitable for storing and executing code in devices such as cell phones.

Support for Flash Memory Programming

Total Phase offers various host adapters that can be used to program I2C- and SPI-based NOR Flash memory devices. Our host adapters are fit for a variety of different project requirements.

The Aardvark I2C/SPI Host Adapter is a general-purpose I2C or SPI host adapter that can be used to transfer serial messages using the I2C or SPI protocols.

The Cheetah SPI Host Adapter is a high-speed host adapter that is specialized to communicate with high-speed, SPI-based Flash memory. It is capable of communicating over SPI at up to 40+ MHz.

The Promira Serial Platform is our advanced FPGA-based platform that can perform high-speed I2C or SPI programming. Depending on the application, this tool supports up to 80 MHz as an SPI master and up to 3.4 MHz as an I2C master.

The Flash Center Software is a software package that allows engineers to quickly erase, program, and verify I2C- and SPI-based EEPROM and Flash memory chips that are interfaced through the Aardvark I2C/SPI Host Adapter, Cheetah SPI Host Adapter, and Promira Serial Platform.

The software natively supports over 500 memory chips from major chip manufacturers that can be found within the parts library. The software provides expansive support for NOR SPI Flash memories, including Micron N25Q Serial NOR Flash memories and Spansion Serial NOR Flash memories, just to name a few.

If users don’t see their part listed, it’s possible to easily add the part by following these steps: How to Create and Add a Custom Flash Part to Flash Center Software

For more information on how our tools can support your Flash programming requirements, please email us at sales@totalphase.com.

Question from the Customer:

My company is using the Advanced Cable Tester v2 (Advanced Cable Tester v2) to test a variety of cables, such as USB, HDMI, and DisplayPort cables.

We have a question about our test results for the USB-C to USB-C cables. The DC resistance of the VBUS pins does not pass the test. However, testing the contact resistance of the VBUS pins with other tools, the result is less than 0.04Ω, which meets the specifications. Here is a picture of the test results from the Advanced Cable Tester v2:

The DC resistance measurements of a customer's USB-C calbe

Advanced Cable Tester v2 Test Results

The test tables show the following information after the Advanced Cable Tester v2 tests the DC resistance of a pin. This table is for A4:

Sources,
Plug1:A4
Sinks,
Plug1:B4,B9,A4 Plug2:B4,A9,B9,A4

Here are my questions:

How do you test the DC resistance of the Plug 1 Pin A4?
Do you put the positive pole to the Plug1:A4, and put the negative pole to the Plug1:B4,B9,A4 &Plug2:B4,A9,B9,A4, and then test the DC resistance between the two poles?

Here is a diagram of how I think the tests are run:

A diagram of how DC Resistance is Measured

Interpretation of DC Test Resistance

I do not yet understand the test results. Can you tell me how the Advanced Cable Tester v2 takes measurements and how results are determined?

Response from Technical Support:

Thanks for your question! Your diagram about DC Test Resistance is close to correct – sensing is also part of the test measurement. A current, about 100mA, is passed through the cable, and the voltage difference is measured at multiple test points. Ohm's Law is then used to calculate the resistance. We will describe how the resistance is measured in the following sections.

Measuring Pin Resistance

The official specifications are for the resistance of the mated connectors. In that case, the measurements are taken directly at the leads coming off the back of the plug (receptacle).

However, after the cable has been manufactured, the paddleboard (a printed circuit board, PCB) is encapsulated in plastic; we cannot take such measurements directly. Instead, we take multiple measurements using the alternate pins as sense pins: test points. This method provides the best accuracy that can be acquired under such conditions.

Where Voltage Measurements Are Applied to Calculate Resistance

Here is a simplified diagram about the sense measurements:

The location points for sense measurements

Locations of Sense Measurements

Sense1 is used as one half of the differential voltage measurement. The other points are also measured: Sense2, Sense3, and Sense4. The point with the least voltage difference (the least resistance) is then considered "the measurement" for Pin 4.

The unknown is the location where the sense pins merge with the other VBUS conductor:

If the VBUS power plane on the paddleboard is large, then this will be negligible.
If current is always flowing through the used sense pin trace, then the measurement may be several milliohms high.

This is not a full connector test, and every cable is different. We apply best effort, and the results are helpful for locating manufacturing problems. The following sections provide details about our Advanced Cable Tester v2 measurements.

About Resistance Measurement

Measuring the resistance of a cable is comparable to measuring a “black box”. Here are explanations about the measurements that were described above.

Why use the Least Voltage Difference as “the measurement” of a Pin?

We aim for the value that is closest to the resistance between the mated plug pair, excluding any PCB traces. On our side, the sense wire joins the current injection trace within 2mm of the receptacle pin – 2mm is a worst case. On the receptable side, we do not know the topology, but the PCB trace will only increase the measured difference. This makes the lowest measurement the best selection for realistic results.

Why is the impedance of a large VBUS power plane on the paddleboard negligible?

In this case, the impedance can be negligible from the paddleboards of the two receptacles at the ends of the cable. It also indicates that the resistance difference between the common wire and each pin is negligible.

There is a rule-of-thumb for PCB trace resistance: The resistance of a ½ ounce circuit board trace is 1mΩ/square × the number of squares down the length of the trace. This means that across a 10mm x 10mm square, the resistance would be about 1 milliohm. Across a 10mm x 1mm square, the resistance would be about 10 milliohms.

Paddleboards may have 10mm of extra trace to a single pin. However, this design is becoming less common.

If the used sense pin trace always has current flowing and affects the measurements, should the cable be connected to Advanced Cable Tester v2 ground?

Grounding is not necessary. The cable ground and the cable shield are isolated from the chassis ground.

Here are the details about “If the used sense pin trace always has current flowing through it then the measurement may be several milliohms high”.

If no current is flowing through a trace, then the voltage at the start and end will be identical.
If current is flowing through a trace, then it creates a voltage gradient along the trace.

Referring to the Interpretation of DC Test Resistance diagram that you provided, and assuming that the cable was built with copper traces as represented by the lines in the schematic, then the path for current is through pin 4, down to the center horizontal wire, and into Plug 2. In this scenario, Sense3 and Sense4 would provide identical voltage measurements.

As previously stated, the actual topology of a paddleboard is unknown, and we apply best effort. The measurement provided by the Advanced Cable Tester v2 can be slightly higher than what you would acquire from a measurement across a bare paddleboard.

Test Profiles and Test Results

Test results may be affected by the version of the cable design, including the E-Marker chip. Profiles can be set up to run tests more accurately. For more information, please refer to this article: What Details are Needed in the Profile to Accurately Run Type-C Cable Tests?

We hope this answers your question. Additional resources that you may find helpful include the following:

Additional information about using the Advanced Cable Tester v2:

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.

Request a Demo

The Data Center Software is Total Phase’s free bus monitoring software that allows users to interface with Total Phase protocol analyzers supporting I2C, SPI, USB, CAN, and eSPI protocols. These analyzers include the Beagle I2C/SPI Protocol Analyzer, the line of Beagle USB Protocol Analyzers, the USB Power Delivery Analyzer, the Komodo CAN Duo Interface, and the Promira Serial Platform with the eSPI Analysis Application.

This award-winning software provides users with an abundance of tools and ways to analyze and interpret bus data. Users can review decoded bus data and transactions in real time, review flagged bus errors, filter and drill down specific data parameters, perform triggers, and much more.

In this article, we’ll provide background on the USB Configuration Management feature in the Data Center Software and how it can be used to help streamline and customize USB debugging efforts.

What is the USB Configuration Management Feature?

While the Data Center Software uses configuration descriptor information captured during the enumeration phase to configure class-level decoding of USB traffic, users can also apply arbitrary configuration descriptors to the captured USB device data using the USB Configuration Management feature if desired. This allows for a custom class-level decoding experience within the set of USB classes supported by Data Center Software. It is important to note however, that this feature does not add support for decoding custom USB classes, only for specifying custom configuration descriptors.

Allowing users to apply configuration descriptors through this feature can be helpful for when enumerated data isn’t captured or is incomplete, or when users would like to override descriptors that were already applied for a particular device. Configs can be created from scratch or saved from a capture.

How to Access the USB Configuration Management Window in Data Center Software

When analyzing a USB system through the Data Center Software, users can view the devices detected on the bus during the enumeration phase in the Bus Pane. The Bus Pane will show detailed device information including addresses, configurations, endpoint descriptors, and more.

The USB Configuration Management Window can be accessed via the Bus Pane by right-clicking in the Bus tree. A pop-up window will then be revealed to allow users to select from a variety of different options; one of them being “Manage Configs”. Once clicked, users will find the USB Configuration Management Window where they can manage configuration information for the device and/or apply a new configuration.

“Manage Configs” option in Bus Pane

Exploring the USB Configuration Management Window

The USB Configuration Management Window is broken up into three different sections: The Configurations Pane, the Data Pane, and the Details Pane.

USB Configuration Management Window

Configurations Pane

The Configurations Pane is a hierarchical list providing all available configurations separated into four categories:

Enumerated Configs are the configurations enumerated during the capture. Being part of the capture, they can be copied but not modified.
Assignable Configs are custom configurations that have been saved with the capture file. They are the only non-enumerated configurations that the user can directly assign to a device for customized class level decoding.
User Configs are custom configurations that are saved in the user's preferences. These configurations are available to any capture opened with the user's Data Center Software.
Configs Provided by Data Center are immutable custom configurations that were packaged with the application. These can be used as examples or templates for making new configurations.

Below the Configurations Pane, users can create custom configurations using the New button USB Configuration Management button.

The user can also Rename button USB Configuration Management , Copy button USB Configuration Management , or Delete Button USB Configuration Management the selected configuration using the same controls.

Data Pane

When clicking on a configuration in the Configurations Pane, the descriptors raw data will be displayed in the bottom-left of the window. This data can be edited in a variety of formats including hexadecimal and ASCII for “Assigned” and “User” configurations. Users can configure the data display by right-clicking anywhere in the pane.

The Data Pane will highlight relevant regions of the data when a specific parameter is clicked in the Details Pane. Likewise, when changes are made in the data, the Details Pane shows the results immediately if Preview button USB Configuration Management at the bottom is checked.

The user can also Save button USB Configuration Management or Revert Button USB Configuration Management edits to a configuration using the controls beneath the Data Pane.

Details Pane

Similar to the Enumeration tab of the Bus Pane, the Details Pane in this window displays the configuration data that is parsed into higher level parameters. When a specific parameter is highlighted in the Details Pane, the corresponding data is highlighted in the Data Pane. If Preview button USB Configuration Management is checked, any modifications to the configuration data in the Data Pane will be updated accordingly in the Details Pane.

Common Tasks Performed in the USB Configuration Management Window

The USB Configuration Management Window provides ways for the user to:

Create, Edit, and Delete custom configuration descriptors that persist either on the user's machine or in the active capture file.
Assign a custom configuration descriptor to an arbitrary bConfigurationValue of any device on the bus, which can change the way data is parsed during a capture.
Remove one or all previously assigned custom configuration descriptors from a device on the bus, exposing the originally enumerated configuration descriptor where available.

How to Save an Enumerated Configuration for Later

Rather than re-enumerate a frequently used device on every new capture, it can be time-efficient to save the devices configuration descriptor and assign it in future captures using Configuration Management.

To save an enumerated configuration:

Right-click on any Bus, Device, or Configuration in the Bus Pane
Click “Manage Configs”to open the USB Configuration Management Window
Find and click on the enumerated configuration descriptor of interest in the Enumerated Configs section of the Configurations Pane:

Enumerated Configs USB Configuration Management

Click and follow the instructions to name the new custom configuration.

How to Assign a Custom Configuration to a Device

To assign an existing custom configuration to a target device and bConfigurationValue:

Right-click on the device of interest in the Bus Pane
Click “Manage Configs” to open the USB Configuration Management Window
Locate and click the configuration you would like to assign to the device in the Assignable Configs, User Configs, or Configs Provided by Data Center categories of the Configurations Pane:

Assignable Configs USB Configuration Management

Click at the bottom right of the window. This will open a dialog allowing selection of a bConfigurationValue for assignment.
Select the desired bConfigurationValue and click “OK”:

Set configuration USB Configuration Management

The custom configuration is now assigned and will appear blue in the Bus Pane. Until this configuration is removed, the Data Center Software will class-decode all transfers against the device as if the custom configuration actually occupied the device's bConfigurationValue.

Our video: Packet Truncation and Configuration Management of the Data Center Software shows how the packet truncation feature allows for significantly longer USB 3.0 captures and how saved USB configurations can be used to apply class-level decoding to captured data after a capture.

Watch the video here:

How to Remove One Assigned Configuration from a Device

To remove a previously assigned custom configuration from active class-level decoding:

Right-click on the configuration to remove in the Bus Pane.

Favorite hub USB Configuration Management

Click “Remove Assigned Config”on the context menu opened by the previous step. The custom configuration is removed, exposing any originally enumerated configuration on that bConfigurationValue.

How to Remove All Assigned Configurations from a Device

To remove all of a device’s previously assigned custom configurations from active class-level decoding:

Right-click on the target device in the Bus Pane.
Click “Remove Assigned Configs”on the context menu opened by the previous step. All custom configurations are removed, exposing the device's originally enumerated configurations where present.

Summary

The USB Configuration Management Window is a helpful feature within the Data Center Software as it allows users to apply USB configurations to captured USB data. This can help with numerous situations, including when the enumeration data isn’t captured or if users want to manually apply configs to decode class-level data. For more information on how this feature can benefit debugging your USB systems, please email us sales@totalphase.com.

Question from the Customer:

I am using the Beagle USB 5000 v2 SuperSpeed Protocol Analyzer - Standard Edition, and I am having some issues with seeing orphaned packets and empty packets. Some IN (incoming) packets are displayed as orphans, and some IN packets are displayed with no data. What are the potential causes of these orphaned packets? How can these problems be addressed? Here are two examples of what I have seen:

Packets labeled “ORPHANED” contain no data (as well as “IN-NAK” packets).
Orphaned Packet without Data
Looking at “IN” packets, most packets contain data, but other “IN” packets do not contain data.
IN Packets with and without Data

Response from Technical Support:

Thanks for your questions! Orphaned transactions indicate that not all data was visible to the Beagle USB analyzer; only a portion of the data within the packet was captured. There are two common reasons for this to occur: multiple devices with one controller or data from different branches of the USB tree, which we will cover in the following sections.

Orphaned Data – One Controller and Multiple Devices

It is common to observe orphaned packets when multiple devices are plugged into the same host controller or if a USB hub is present on the bus. In such cases, the target device (Device A) has an internal USB host controller. The target device may also have multiple internal USB host controllers and devices, as well as an internal USB hub.

We will refer to the target’s internal device as Device B, and that internal device is connected to the same USB host controller as the Beagle USB analyzer. This internal USB device in the system, Device B, can be connected with or without an internal USB hub. In this scenario, the Beagle sees all the traffic between the host and Device A, but only the downstream traffic from the host to Device B. Here are two common reasons why orphaned packets can occur in this setup:

The USB host controller inside the target host may send an IN to Device B. The Device B may NAK the IN, but the Beagle USB analyzer may see only the IN.
These orphaned packets can also occur if there is internal USB hub in the target host, and the USB host controller sends transactions to the internal USB hub.

We have two approaches for this problem, both of which use filtering.

Select Devices on the USB Host

To observe only the packets of the selected device:

Expand USB 2.0 from the Navigator column in the left side of the Data Center Software You will see the list of all the devices that are connected to the USB host.
One by one, right-click each device, then select the desired options to filter in or filter out the packets of each device.

Filter Captured Data

LiveFilter is another option, which is accessed via Data Center Software. LiveFilter allows you to focus on the data you need by using many filtering options. Here is a video that shows how this feature works:

For more information about filtering a bus capture, please refer to the Data Center Software User Manual.

Orphaned Data – Different Branches of USB Tree

Orphaned transactions can also occur when the target device is on a different branch of the USB tree. In this case, the Beagle USB analyzer may only see a portion of the data packet.

For an Orphaned transaction, there are two traces to look at: Endpoint 2 and the default endpoint, Endpoint 0. For this scenario, we recommend filtering the Endpoint 2 transactions. The easiest way to achieve this is with Quick Filters. To do this:

In the Data Center Software window, right-click any transaction from Device 1 Endpoint 2.
To filter the captured date, choose Quick Filters->Show Except Endpoint.
Filtering Endpoint Transactions

We hope this answers your questions. Additional resources that you may find helpful include the following:

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.