Jack Ganssle is the president of Softaid, a vendor of emulators and other embedded-systems tools. You can contact him via Compuserve: 76366,3333 or Internet: jack@softaid.com. Or send mail to Softaid, 8310 Guilford Rd, Columbia, MD 21046.
Columnist: April 27, 1995
I'm a tool freak. My fingers are not strong enough to remove a bolt, but, give me a wrench, and my hand can perform amazing feats. A hammer gives my soft flesh the toughness needed to drive a nail home; a surface-mount rework station lets me manipulate hairlike pins that crude fingers invariably distort. And, like most males, tools with big motors that hurl sawdust in a swirling gale satisfy my testosterone craving for brute mechanical power.
Computer folks like to consider the PC a mind tool that increases the power and reach of the user's brain. Conventional hand tools give us a similar ability to manipulate the mechanical world in ways impossible via the unaided human body.
I'm a fanatic about woodworking tools. I enjoy keeping them clean and sharp, buying only the best, and collecting the cream of past technology, which, although out of style, may still be the best solution to a problem. Likewise, I relish the tools of the electronic engineer. Each device can make my job easier, provided I take care of it and take the effort to learn its intricacies.
There's the rub: We're inundated with tools. Most of us have fantastic capabilities at our fingertips, yet we limp along using the handful of features to produce work of reasonable quality.
Every week our hard disks fill with more megabytes of cool software that we can't efficiently use due to sheer brain-bandwidth overload. Surely, there's logic to devoting an hour or two each week to becoming more proficient with these wonders; however, few of us have the time. Yet, many engineers never completely master some tools that are critical, such as the oscilloscope. Without the oscilloscope, none of us could do the least amount of debugging.
I've found that surprisingly few engineers ever master delayed sweep, one of the most useful features of the modern scope. OK, maybe the feature is not terribly useful in analog applications. As a confirmed digital type who shudders at the thought of dealing with millivolts and picoamps, I'll plead ignorance to the special requirements of analog wizards. However, in digital and embedded systems, delayed sweep is an absolute must.
All scopes, whether digital or analog, have three major systems: the vertical channels, triggering, and horizontal sweep. Normally, with delayed sweep disabled, the horizontal channel (the time base) runs the beam only from left to right continuously at the rate you've selected via the sweep time per centimeter rotary switch.
Novice scope users understand the operation of timebase A: Crank the time/division knob to the right, and the signal on the screen expands in size. Rotate the knob to the left, and the signal shrinks, but much more history (that is, more microseconds of data) appears.
Timebase B is more mysterious. If enabled, it doesn't start until sometime after timebase A begins. Try it on your scope: Select "Both" or "A intensified by B" and choose a sweep rate faster than that used by A. You'll see a highlighted section of the trace with a width that B's sweep rate determines and a starting position that is a function of the delay time knob.
Switching from "Both" to "B" shows just the intensified part of the sweep-the part timebase B controls. In effect, you've picked out and blown up a portion of the normal sweep. It's like a zoom control-and you can select the zoom factor using the sweep time, and the "pan position," or starting location, using the delay time adjustment.
Suppose you want to look at something that occurs a long time after a trigger event. Using these zoom controls, you can get a very high-resolution view of that event-even when timebase A is set to a slow rate.
A second trigger system always accompanies delayed sweep. Most of us have developed calluses twiddling the trigger-level control in an effort to obtain stable scope displays. Any instrument with dual time- bases comes with a second of these knobs to set the trigger point of the B channel.
The second trigger is important when working on digital signals that usually have unstable time relationships. Set the A trigger to start the sweep, as always, position the intensified part of the sweep to some point before the section you'd like to zoom on, and adjust trigger B until the bright portion starts exactly on the event of interest.
This procedure guarantees that, even though the second trigger event moves around in relation to trigger A, you'll see a stable scope display after selecting the B timebase. In effect, you've qualified trigger B by trigger A, zeroing in on the area you need to study.
Delayed sweep is essential when working on any embedded system. Let's look at a couple of cases. Suppose your microprocessor crashes immediately after RESET. Traditional troubleshooting techniques call for hooking up the logic analyzer and laboriously examining all of the data and address lines. I find this to be too much trouble. Worse, the process tends to obscure "electrical" problems: The analyzer might translate marginal ones and zeros into what look like legal digital levels. Logic analyzers are great for purely digital problems, but any problem at power-up can easily be related to signal levels.
Only a scope gives you a view of those crucial signal levels that can cause so much trouble. Trigger-channel 1 on the RESET input, and probe around with channel 2. Look at READ. Every processor starts with a read cycle to grab the first instruction or start-up vector. You may find a puzzling phenomenon: If the reset is provided by a source asynchronous to the processor's clock, as is the case with an RC circuit, a VCC clamp, and even many watchdog timers, READ bounces around with respect to RESET. You'll never get a nice high-resolution view of READ this way.
Triggering off READ does not help. You need to catch the first read after reset (to look at the first instruction fetch), not any arbitrary incarnation of the signal. And, no doubt, there will be millions of reads between resets.
The answer is delayed sweep. Put RESET into the scope's external trigger input and fiddle the knobs until you get a stable trigger. (I like to put one scope channel on the external trigger while doing this initial setup to make sure the trigger is doing what I expect.) Then, connect channel 1 to your processor's READ output, and crank the timebase until it appears toward the right side of the display. Go to delayed (A intensified by B) mode, and rotate the B timebase trigger adjustment until the bright part of the trace starts on the leading edge of the bouncing READ signal.
At this point, timebase A starts the sweep going on the asynchronous RESET, and timebase B triggers the intensified part of the sweep when the first READ comes along. Flip the horizontal-mode switch to B (to show only the intensified part of the sweep-that part after the B trigger), and a jitter-free READ will be on the left part of the screen. Cool, huh?
With the now-stabilized scope display, you can use channel 2 to look at the data lines, ROM chip selects, and other signals during the read cycle. It becomes a simple matter to see if the first instruction gets fetched correctly. A lot has to be perfect for this to happen. Often, a power-up problem comes from a bad data line or chip-select or buffer problems. However, with the scope triggered properly, these problems are easy to find. This example shows how a few seconds of button twiddling can resolve two asynchronous signals on the scope display.
When your system appears to have crashed, it's often hard to guess exactly what the program is doing: Is the main loop running correctly, or is it stuck waiting for input from a UART? Instead of reaching for the logic analyzer, I usually put on a thinking cap and speculate about what could be happening. For example, in a system that regularly polls a UART, it takes only a few seconds to check the I/O port's chip select to see if the code is hitting that pin. If so, there's a good chance the main loop is running, at least.
When a series of I/O operations happens sequentially, you can use delayed sweep to examine each event in detail. For instance, the code to program a Zilog serial communications controller (a do-everything serial link) sends many bytes to the same port. Triggering a scope on these port writes displays a jumble of mixed-up cycles. Delayed sweep, however, lets you trigger on the first write to the port and display the particular write you'd like to see.
Trigger channel A on the first write. (Use the trigger hold-off control to restrict triggering to burst events.) Set the sweep rate of channel B to something faster than channel A. Then, use the delay-time control to scroll through as many port writes as necessary to find the event causing grief. In this example, the delayed sweep lets you see a high- resolution view of events that may be widely separated in time.
Use a variation of this technique to troubleshoot many hardware/software integration issues. If your system has an unused I/O select, such as an output of an I/O decoder, seed the code with reads or writes to this port. Trigger timebase A from this select, and use delayed sweep to zoom in on an enhanced view of problem areas.
An old adage says, if it sounds too good to be true, it probably is. If your digital scope shows something unbelievable, assume, at least for a minute, that it's lying to you. Try this: Measure a 10- or 20-MHz clock on a digital scope. Crank the sweep rate slower and slower. You'll inevitably reach a point where the scope shows a near-perfect square wave several orders of magnitudes slower than the actual clock frequency. This is an example of aliasing, where the scope's sampling rate yields an altogether incorrect display. I'm sure many folks have heard the claim, "This 16-MHz oscillator is running at 16 kHz! Can you believe it?" Don't: Check your settings first.
Jack Ganssle is the president of Softaid, a vendor of emulators and other embedded-systems tools. You can contact him via Compuserve: 76366,3333 or Internet: jack@softaid.com. Or send mail to Softaid, 8310 Guilford Rd, Columbia, MD 21046.