3 Device Operation

Top

3.1 Electrical Connections

Beagle USB Protocol Analyzers

The Beagle USB analyzer’s analysis port must be connected to the analysis computer through a USB cable. The Capture side of the Beagle analyzer must be placed on the USB to be monitored. Normally, this is accomplished by placing the Beagle analyzer in-line between the USB device and host being monitored. In other words, the bus to be monitored goes through the Beagle USB analyzer. To properly accomplish this connection, connect the target host to the USB-B receptacle on the Capture side of the Beagle USB analyzer, and connect the target device to the USB-A receptacle on the Capture side of the Beagle USB analyzer. See Section 2.1 for more details. This is the setup illustrated in panels a–c of Figure 27.

In some cases, the target bus is fully internal to an embedded system. If so, it is simply necessary to tap off the lines through the use of a parallel connector. One can plug in the tapped off cable into either the Target host or Target device port of the analyzer; both are equivalent. This is illustrated in Figure 27d.

Figure 27: Beagle USB Protocol Analyzer Connections
Beagle USB analyzer may be connected to the same bus as it is monitoring (panel a), or to a different bus (panel b). Multiple host controllers may reside in separate host controllers (panel c). Panel d shows the case of sniffing a self-contained embedded bus.

The connections of the Beagle USB analyzer are complicated somewhat by the fact that the Beagle analyzer is monitoring USB signals and then communicating the monitored data back though another USB port. Thus, the issue of the host broadcasting, as described in Section 1.1, comes into play. While all Beagle analyzers use high-speed USB communication rate, this issue is only pertinent when using the Beagle USB 480 Protocol Analyzer to monitor a high-speed device. If the Beagle USB 480 Protocol Analyzer’s analysis port is connected to the same host controller as a high-speed device that it is monitoring (Figure 27a) then the Beagle analyzer will end up sniffing some of its own traffic. This is especially true if the Beagle analyzer is configured to stream back bus traffic to the PC in real time! This will be seen in the capture as many IN packets to the Beagle analyzer’s device address with occasional downstream handshake packets.

This phenomenon has two negative consequences. The extra traffic on the capture bus from the Beagle USB 480 analyzer may make it difficult to locate the USB traffic of interest within the volume of data captured. Additionally, the bus traffic for Beagle USB 480 analyzer will reduce the bandwidth available to other USB devices on the bus.

There are a number of ways to deal with this issue.

One method for dealing with this problem is install another USB host controller to the computer and connect one host controller to the analysis port of the Beagle analyzer and use the other host controller to communicate with the host and device under test (Figure 27b). Downstream USB packets are only broadcast on USB links on the same host controller, so this technique is another way to ensure that the Beagle analyzer’s traffic is not seen on the capture side of the analyzer. The disadvantage is that the PC must spend processing time for communicating both with the target device as well as the Beagle analyzer.

The preferred method is to connect separate computers to the analysis port and to the target host port of the Beagle USB 480 analyzer (Figure 27c). This puts the analysis end of the Beagle analyzer on a different bus, ensuring that its traffic is not seen on the capture side of the analyzer. Furthermore, the analysis PC can have full resources to process the incoming data, and the test PC will not be encumbered by the analysis software.

Note: All of the USB ports on most computers are on a single host controller, so connecting to a different USB port is not sufficient. Installing a PCI, PCI Express, or PC Card USB controller card will ensure there is a second USB host controller on the computer.

If the user is constrained to the scenario illustrated in Figure 27a, there are two features of the Beagle analyzer to help mitigate the dilemmas previously outlined. One is a hardware filtering option that runs on the Beagle analyzer to filter packets directed to the Beagle analyzer’s device address. These packets will be filtered out from the capture by the hardware, so it will not be sent back through the analysis port. This option does not entirely remove the Beagle analyzer’s traffic from the monitored bus, but it will definitely minimize the analyzer’s effect on the bus since the IN and ACK tokens sent to the analyzer will not again appear in the analysis traffic. In situations where the maximum bandwidth is required by the target device, avoid using this option. The second feature is the ability to perform a delayed-download capture. In this capture mode, the capture data is not streamed out of the analysis port of the Beagle analyzer until after the analyzer has stopped monitoring the bus. This greatly reduces the amount of USB traffic going to the Beagle USB 480 analyzer while the capture is active. These features are mentioned later in this section where appropriate.

Beagle I2C/SPI/MDIO Protocol Analyzer

The Beagle I2C/SPI/MDIO analyzer uses a standard USB cable to connect the protocol analyzer to the analysis computer. The data line(s), clock, and ground of the communication protocol in question must be properly connected to the Beagle analyzer’s data line(s), clock, and ground, respectively.

Top

3.2 Software Operational Overview

There are a series of steps required for a successful capture. These steps are handled by the Beagle Data Center software automatically, but must be explicitly followed by an application programmer wishing to write custom software. The application programmer interface (API) is documented extensively in Section 6, but the following is meant to provide a high-level overview of the operation of the Beagle analyzers.

1. Determine the port number of the Beagle analyzer. The function bg_find_devices() returns a list of port numbers for all Beagle analyzers that are attached to the analysis computer.

2. Obtain a Beagle handle by calling bg_open() on the appropriate port number. All other software operations are based on this Beagle handle.

3. Configure the Beagle analyzer as necessary. The API documentation provides complete details about the different configurations.

4. Start the capture by calling the bg_enable() function.

5. Retrieve monitored data by using the read functions that are appropriate for the monitored bus type. There are different functions available for retrieving additional data such as byte- and bit-level timing.

6. End the capture by calling the bg_disable() function. At this point the capture is stopped, and no new data can be obtained.

7. Close the Beagle handle with the bg_close() function.

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

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

Top

3.3 Beagle USB 480 Protocol Analyzer Specifics

Aside from standard real-time capture, the Beagle USB 480 analyzer provides a number of other features. These features include bus event monitoring, digital inputs and outputs, hardware filtering, as well as multiple capture modes.

Bus Events

The Beagle USB 480 analyzer provides users with insight into events that occur on the bus. These bus events include suspend, resume, reset, speed changes (including high-speed handshake), and connect/disconnect events. Furthermore, events that are unexpected (i.e., don’t conform to the USB spec) are tagged with a specific status code to bring that to the attention of the user. The Beagle USB 480 analyzer also has the ability to identify imperfect resets, like a Tiny J associated with the high-speed handshake. A Tiny J (or K) may also be tagged when not in a high-speed handshake situation if the reset is not fully at an SE0, but is instead floating above the high-speed receiver threshold. This allows users to see if the host is driving a reset signal that is close enough to ground voltage. Alternatively, if this amount of detail on reset signals is not desired, the auto speed-detection could be disabled, and locked to the specific speed of interest.

Where applicable, bus events are also returned with a duration. In most cases, this duration is self-explanatory, such as in the duration of a Chirp K or a keep-alive bus state. However, some clarification is required for the reported duration of suspend and resume events.

For suspend events, the Beagle USB 480 analyzer will return the duration of the event as it is measured from the device’s perspective. For example, in a case where the bus is idle for 8 ms, the analyzer will return 5 ms for the duration of the suspend; this corresponds with the fact that the device can only enter the suspend state after 3 ms of bus idle and is therefore suspended for 5 ms.

For resume events, the Beagle analyzer will return the duration of the K portion of the resume signaling. Rather than combine this duration with the ensuing SE0, this scheme provides users with the ability to determine the individual durations of each segment of the resume event. Specifically the user can refer to the start time of the resume event, the duration of the resume event (time of K state), and the start time of the subsequent event or packet.

For more details on USB bus events refer to Section 1.1 and the USB 2.0 spec.

OTG Events

The Beagle USB 480 analyzer has the ability to detect On-The-Go (OTG) events. These events include the Host Negotiation Protocol (HNP) and each stage of the Session Request Protocol (SRP). For more details on these protocols, see Section 1.1.

A HNP event will be returned upon seeing the correct initial conditions, and then detecting a correctly timed SE0 followed by the full-speed J. If the new host does not issue a reset within the specified time, the HNP event will be returned with an error indication.

There are two stages of the SRP, and a separate event is returned for each of them. Upon detecting a data-line pulse, the Beagle software will return an event corresponding to this condition. After detecting a data-line pulse, the software will report a V pulse if it is seen on the bus. Note that this means that any V pulse that occurs without a preceding data-line pulse will not be reported since it is completely out of the OTG specification. If the SRP is successful, it will be followed by a host connect event. If it is unsuccessful, then it will be followed by a host disconnect event.

Digital Inputs

Digital inputs provide a means for users to insert events into the data stream. There are four digital inputs that can be enabled individually. Whenever an enabled input changes state it will issue an event and be tagged with a timestamp of when the input was interpreted by the Beagle USB 480 analyzer. Digital inputs can not exceed a rate of 30 MHz. Digital inputs that occur faster than that are not guaranteed to be interpreted correctly by the Beagle analyzer. Also, only one digital input event may occur per active packet. All other digital input events can only be handled after the packet has completed. Digital inputs, although guaranteed to have the correct timestamp given the previous conditions, have the possibility of being presented out of order because they are provided randomly by the user and have no direct correlation to the bus.

It is important to note that the digital inputs are susceptible to cross-talk if they are not being actively driven. A situation like this could occur if a digital input has been enabled, but has not been tied to a signal. Any other nearby signal (i.e., other digital inputs or outputs) could cause the input to activate. It is recommended that all undriven digital inputs be disabled or tied to ground.

For hardware specifications of the digital inputs refer to Section 21.

Digital Outputs

Digital outputs provide a means for users to output certain events to other devices, such as oscilloscopes. In this way, users can synchronize events on the bus with other signals they may be measuring.

Digital outputs, like digital inputs, are susceptible to cross-talk if left disabled. It is recommended that users do not attempt to use disabled digital outputs on other devices, as their characteristics are not specified. Either disconnect all connections to disabled digital outputs, or tie those outputs to ground.

There are four digital outputs that are user configurable. Each digital output has the option of being enabled, active high, or active low. Furthermore, each output can activate on specific conditions described below.

• Digital Output 1 will be asserted whenever the capture is running.

• Digital Output 2 will be asserted whenever a packet is detected on the bus.

• Digital Output 3 will be asserted when the selected PID, device address, and endpoint match.

• Digital Output 4 will be asserted when the selected PID, device address, endpoint, and data pattern match.

The digital outputs activate as soon as their triggering event can be fully confirmed. Thus, Pins 1 and 2 will activate as soon as the capture activates or rxactive goes high, respectively. However, Pins 3 and 4 must assure a match of all of their characteristics. Therefore, only once all possible PIDs, device address, and endpoints of a given packet are checked completely can the output activate. The assertion of matched data on Pin 4 must wait until the end of the data packet to assure a match. Packets that are shorter then what is defined by the user to match will activate Pin 4 if all the data up to that point matched correctly.

Hardware specifications for the digital outputs are provided in Section 21.

Hardware Filtering

Hardware filters provide users with the ability to suppress data-less transactions, like those described in Section 8. When possible, the hardware filters will discard all packets that meet the filtering criteria. These filters can save a significant amount of capture memory when used, and are highly recommended when capture-memory capacity is a concern.

Another benefit of the hardware filters is that they reduce the amount of traffic between the analysis computer and the Beagle analyzer. This is especially useful for situations where the analysis computer has a hard time keeping up with the bandwidth requirements of the Beagle analyzer. For example, the analysis computer may be running other applications or it may have other devices attached to the same bus.

There are six different hardware filters that can be used independently or in conjunction with one another. They must simply be enabled by the user. Their functionality is described below.

• SOF Filtering will remove all Start-of-Frame (SOF) tokens from the data stream. Please note that enabling the SOF filter will forfeit the ability to detect suspend and high-speed disconnects conditions on the bus.

• IN Filtering will attempt to remove all IN+ACK and IN+NAK pairs.

• PING Filtering will attempt to remove all PING+NAK pairs.

• PRE Filtering will remove all PRE tokens.

• SPLIT Filtering will attempt to remove many of the data-less SPLIT transactions. This filter will attempt to discard:

  -SSPLIT+IN (for isochronous and interrupt transfers)

  -SSPLIT+IN+ACK (for bulk and control transfers)

  -CSPLIT+OUT+NYET

  -CSPLIT+SETUP+NYET

  -CSPLIT+IN+NAK

  -CSPLIT+IN+NYET

• Self Filtering will remove all packets intended for devices with the same device address as the Beagle analyzer. Due to the architecture of USB, when the Beagle analyzer is sniffing the same high-speed bus on which it is connected, it will see its own traffic on the Capture side (for more details refer to Section 2). This filter gives the user the opportunity to remove that traffic out of the reported data stream. This filter, however, is only effective if the Beagle USB 480 analyzer is in fact connected to the same bus as it is analyzing. If the Beagle analyzer is connected to a different host controller, this filter should be disabled, as there is a probability that another device on the Target bus will match the Beagle analyzer’s device address, and data to that device will be lost.

Top

Filters and Digital I/O

There are a couple of issues regarding the hardware filtering and digital I/O that are worth noting. Digital outputs are computed before any filtering takes place. This means that if an output is set to activate on a normally filtered packet, the output will still activate even if the packet is never seen by the user. For example, if SOF filtering is enabled, digital outputs set to activate upon seeing an SOF PID will still activate when an SOF is on the bus.

Digital inputs can potentially invalidate a filter. The filters that are susceptible to this are the IN, PING, and SPLIT filters. These filters suppress entire transactions based on the sequence of packets on the bus. If an input trigger occurs at any time during this sequence, the entire transaction is sent to the user. As an example of this, if IN+NAK pair filtering is enabled and a digital input event occurs at any time between the start of the IN token and the very end of the NAK handshake, the entire transaction will be reported to the user. However, if no digital input event occurs, the IN+NAK pair will be discarded.

Capture Modes

The Beagle USB 480 Protocol Analyzer provides the user with 3 different capture modes: real-time capture, real-time capture with overflow protection, and delayed-download.

Top

Real-time Capture

Real-time capture is the default capture mode. It provides the user with real-time status of the bus being monitored. The real-time capture can be stopped by three methods. The first method is by having the user end the capture through a bg_disable() call (or though the Beagle Data Center software). The second method is if the Beagle analyzer loses power. This is not the recommended method for stopping a capture. Finally, the capture will be automatically stopped by the Beagle USB 480 analyzer if the 64 MB hardware buffer fills to capacity. In this situation, the Beagle analyzer will no longer capture new data from the monitored bus. Instead, calls to bg_usb480_read() will only retrieve whatever data is remaining in the buffer. The last call of bg_usb480_read() will return a BG_READ_USB_END_OF_CAPTURE indicating that the capture has stopped and that there is no new data. The hardware buffer may fill in conditions where the analysis computer is not reading the data from the Beagle analyzer as fast as it is capturing new data.

Top

Real-time Capture with Overflow Protection

Real-time Capture with Overflow Protection is essentially identical to real-time capture except that it allows for more efficient use of the hardware buffer when it nears full capacity. When the buffer is near capacity, the Beagle USB 480 analyzer will truncate all incoming packets to 4 bytes. The true length of the packet will still be reported to the user, however only the first 4 bytes of the given packet will be returned. If the user is using a custom application, the remainder of the packet field will be filled with 0s. However, all packets captured when in truncation mode will be tagged with the BG_READ_USB_TRUNCATION_MODE status code bit. Because packets are truncated to 4 bytes in length, only DATA packets have the potential of being truncated. All tokens, handshakes, etc. will still be shown in their entirety.

This mode truncates large packets reducing further usage of the hardware buffer. This allows the analysis PC a chance to siphon more data off of the Beagle analyzer before the hardware buffer becomes completely full. In other words the analysis port can catch up to the target traffic. If the buffer usage drops below a certain threshold, the analyzer will automatically return to normal operation and cease the truncation of long packets.

Top

Delayed-download Capture

Delayed-download capture does not stream data to the analysis computer in real time, but instead saves all of the data in the 64 MB hardware buffer until the user is ready to download it. The size of the capture is clearly limited by the hardware buffer’s max capacity, so it is recommended to use the hardware filters to limit data-less transactions when appropriate.

The delayed-download capability will especially benefit those users that are analyzing high-speed traffic, but are only using a single computer with a single host controller for both the analysis computer and the target host computer. As described previously, devices on the same host controller must share the available bandwidth. Also, all high-speed devices on the same host controller will see all downstream traffic. Therefore using delayed-download will limit the Beagle analyzer’s participation on the bus. In fact, if no other functions are called between the enable of the capture and the disable, there will be nearly no traffic at all between the PC and analyzer. The only traffic will be at the very start and end of the capture session.

The delayed-download will stop automatically once the buffer has reached capacity. It may also be stopped at any time by the user by calling the bg_usb480_read function. Polling of the status of the buffer is possible through bg_usb480_hw_buffer_stats(), function call. Polling the Beagle analyzer will create traffic on the bus, and thus take up some of the available bandwidth. Faster polling rates will clearly take up more bandwidth, and thus if users wish to minimize their impact on the bus, they should not poll the buffer at all. Regardless, the polling traffic itself can be filtered from the analysis data by using the hardware based Self Filter.

Top

3.4 Beagle I2C/SPI/MDIO Protocol Analyzer Specifics

Sampling Rate

Unlike the Beagle USB analyzers, the sampling rate of the Beagle I2C/SPI/MDIO analyzer is configurable. In order to accurately capture data the sampling rate must be properly set. For SPI and MDIO analysis all data lines are registered using the clock line of the bus. The internal sampling clock is then used to retrieve the data. The sampling rate should be set to at least twice the bit rate, but preferably faster (4-5 times) if possible. Higher sampling rates can have the added benefit of increasing timing precision.

Due to the architecture of I2C , there are specific bus events that occur between the standard bit-times. In order to capture these transitions, the bus must be oversampled independent of the clock line of the bus. A sampling rate of five to ten times the bus bit rate is recommended. This should not be a problem, however, since the minimum sampling rate of the Beagle I2C/SPI/MDIO analyzer is 10 MHz, and I2C buses usually operate at less than 1 MHz frequencies.

The one caveat to setting the sampling rate to very high values is that higher sampling rates create more traffic on the analysis USB that connects the analyzer to the host PC. This may or may not affect performance depending on the analysis PC configuration.