Testing Power Rail Sequences in Complex Embedded Systems

Figure 1. Four power rail signals on a single grid, with cursors
measuring the time delay between the first pair in the sequence.

Embedded computing systems generally require multiple supply voltages to deliver power to the microprocessor, memory and other on-board devices. There is usually a 12- or 15-volt DC primary supply, and numerous buck or boost converters working off the primary to help provide various voltages throughout the embedded system. Most microcontrollers have a prescribed order in which the voltages must be applied to prevent problems like lockups, so an area of concern when designing deeply embedded systems is the proper sequencing of power rails as they power up or down. Power management IC’s (PMIC) or power sequencers perform many of the sequencing tasks, but during validation and when troubleshooting, the order and timing of the power sequence should be verified.

Correlating Sensor and Serial Data in Complex Embedded Systems

Figure 1: Voltage output of a temperature sensor.
As the temperature rises, the output voltage falls. 

The microcontrollers/microprocessors in deeply embedded systems often are set up to monitor and control operational parameters.  Take, for example, a deeply embedded system where a microcontroller is used to control temperature that has been sensed by a temperature sensor.  The sensor is read through one of the microcontrollers analog interfaces.  As temperature changes are sensed, the microcontroller adjusts the speed of a cooling fan, which is driven by a pulse width modulated signal. The microcontroller uses a program algorithm to convert the DC level of the sensor into a PWM signal with an appropriate duty cycle to set the fan speed to correct any changes in temperature. 

Where it is possible to probe the temperature sensor, the output is a DC signal that changes very slowly over time.  Figure 1 shows a direct measurement of the temperature sensor using a heavily filtered oscilloscope channel to minimize noise pickup.

Correlating Low to High-Speed Events in Complex Embedded Systems

Figure 1: A challenge when testing embedded systems
is to correlate events in a low-speed interface like SPI
to events in a high-speed interface like PCIe.

A common requirement when testing embedded systems is to measure the timing between signals with low data rates and those with high data rates. Looking at the functional block diagram of our typical deeply embedded system in Figure 1, we see low-speed serial interfaces like SPI and I2C along with high-speed serial links, like PCIe (often serving as the high-speed serial PHY in our diagram).

Take for example testing the initialization of the system. When power is first turned on, the ROM bios and flash memory initialize program elements that are required by the embedded system’s microprocessor. Once the initialization is complete, the microprocessor has to notify the motherboard via PCIe that it is active and ready to receive data via the high-speed serial bus. This all has to happen within 200 milliseconds. 

Debugging Complex Embedded Systems

Figure 1: A typical embedded system has many devices
utilizing a wide range of signal types and bandwidths.

In the next few weeks, we’ll present a series of posts describing the debugging of various components of embedded systems, everything from working out the timing of power on sequences to extracting analog sensor data from serial data streams. All these examples of “real world” debugging can be performed using only standard tools available on most mid-range Teledyne LeCroy oscilloscopes.

Let's start by defining what we mean by embedded system and deeply embedded system. For our purposes, an embedded system is a fixed function, self-contained control system on one printed circuit board. Typically, printed circuit boards (PCBs)  will have multiple passive devices, a few active electronic devices, analog devices, digital devices and a few serial data devices. There tends to be a microcontroller device to process data and control other components. There will also be some type of system memory, often embedded inside the microcontroller. And, there will be some power conversion devices and power distribution elements that power all the other devices in your embedded system. 

Measuring Dead Time in 48 V Power Conversion Systems, Part 1: Static Measurements

48 volt power conversion systems input a 48 VDC power bus and output other voltage levels. The key section in the conversion process is the inverter stage. The inverter subsection topology may be half bridge, full or H-bridge, or cascaded H-bridge for 3-phase systems. There is typically a filtering circuit after the inverter before power is passed on to the Load, and a control system that takes care of controlling the entire conversion system. 

Figure 1:Three common topologies for switching inverter stages. The load is connected between upper and lower power switching devices, which are selectively switched on and off to supply power to the load from the DC bus.

The three inverter topologies shown in Figure 1 are all similar in that they use stacked or “totem pole” power devices for switching. 

In operation, each of these topologies provides a path from the DC bus through the load and then to ground (0 V) by turning on selected devices. At no time should there be a direct path from the DC bus to ground, an event called “shoot through.” Designers intentionally add dead time to eliminate the risk of shoot through.

Debugging Dynamic Link Behaviors with CrossSync PHY for PCIe

Figure 1: These upstream lanes show unexpected equalization
behavior. If you only had the electrical signals to work with,
how would you begin debugging them?

Recent generations of PCI Express® rely heavily on the link equalization process to support signal integrity at bit rates of 8, 16 or 32 Gbps. In Phase 1, both sides of the link exchange TS1 ordered sets to establish an operational link. In Phase 2, the upstream port requests the downstream port to configure its transmitter equalization to compensate for the link channel. In Phase 3, the opposite happens, and the downstream port requests the upstream port to configure its transmitter equalization. 

At PCI Express compliance events, or when doing pre-compliance testing in the lab, a transmitter link equalization test is performed to determine whether a device is capable of correct link equalization in isolation. A piece of test equipment, usually a protocol-aware BERT, acts as the link partner for the device under test. The BERT requests specific preset changes from the device, in response to which the device (in theory) changes its preset to provide the correct channel compensation. The changes are captured by an oscilloscope, which is capable of visualizing the transmitter equalization changes in the electrical layer and measuring first of all, if they happen quickly enough, and secondly, if the device actually changed to the preset levels requested, which occur in a known sequence. 

But what happens when you suspect "weird" equalization behavior in a live link between two devices—for example, something off with the upstream equalization in Phase 3?  How would you capture that to begin debugging the problem? Where would you look for a clue as to what is happening?

Debugging L1 Substates Timing Errors with CrossSync PHY for PCIe

Figure 1: CrossSync PHY for PCIe lets you easily map the
electrical to the protocol layer of L1 substate events.

Debugging the L1 substates used for PCIe® power management has been a real pain point for engineers, especially those using the M.2 form factor. The L1.1 and L1.2 substates allow you to take a PCIe link to a deeper power savings state than L1 alone. L1 is entered by either of two mechanisms, an ASPM message or a Power Management message, but in both cases the net effect is that the link goes into electrical idle. Unlike conventional L1, a clock request (CLKREQ#) signal is used to enter and exit the L1 substates. Upon entry, the device or host deasserts the clock request line. By saying, “I don’t require a clock anymore,” the clock can be turned off for additional power savings. Upon exiting the L1 substates, the CLKREQ# is asserted and the reference clock resumes.