8 Hints for Debugging Microcontroller-based Designs

The Challenge of Debugging MCU-Based Designs

It’s almost impossible to design an electronic or electromechanical product these days without using a micro-controller. While there are plenty of interesting design challenges, the debugging tools for MCU-based designs haven’t always kept up. If you work with 8- and 16-bit MCUs, for instance, you’ve probably felt stuck in the middle, between generic, basic tools (such as scopes) and higher-end tools aimed at microprocessors (such as traditional logic analyzers and emulators). At the same time, you’re probably dealing with a mix of analog and digital signals, so a scope by itself or a logic analyzer by itself is only half a solution. Moreover, you probably don’t have the luxury of specializing. You have to know analog hardware, digital hard-ware and firmware — and be good at all three. And all the while, market windows are getting narrower, competition is getting stronger, and customers are expecting more power and capability from your MCU-based products. Your job may be a lot of things, but boring certainly isn’t one of them.

Help is on the Way

As the worldwide leader in test and measurement, we’re working hard to help engineers like you meet your MCU-based design challenges. One way we can help is with the information in this booklet, practical debugging hints from engineers working with a variety of MCUs. You’ll see how these designers use some of the latest MCU debugging tools to get their new products to market faster.

Tracking Down Elusive Glitches

Infrequent, unpredictable events can present some of the toughest trouble[1]shooting challenges around. I recently encountered such a glitch while designing a low-power data acquisition device. This wireless instrument system uses a group of remote sensor units and spread spectrum radio transceivers (Figure 1). Data collected at the system can be retrieved by a network control unit connected to a computer. The system uses the interrupt pin on a low-power clock chip to trigger power-up events every 60 seconds. Between events, the clock and sup-porting logic are the only devices drawing current (approximately 50 µA). After getting a trigger from the clock, the Motorola 68HC11K1 micro[1]controller powers up, collects temperature data and listens for transceiver activity. If it hears a data request on the transceiver, the MCU transmits the temperature data. The glitch in question was showing up during this 60-second interval, when the system was supposed to be quiet. To find and analyze this anomaly, I used a deep memory (1 Mbyte) digital oscilloscope with peak detect. Since the glitch occurred so infrequently, I first set the scope’s time base at 10 seconds/division in order to capture the entire 60-second sequence. Without peak detect, most narrow events would be impossible to detect at this time base setting. But as Figure 2 shows, the glitch in my system was easily captured and viewed. Peak detect showed some[1]thing unusual happening approximately 15 seconds after the clock trigger event.

Once I became aware of the anomaly’s presence in my system, the scope’s deep memory made it easy to zoom in and analyze the glitch in more detail. With the scope’s 1 Mbyte of acquisition memory, the initial waveform capture at 10 seconds/ division was also sufficient to see waveform details when I zoomed in and viewed at 10 milliseconds/division (Figure 3).

Characterizing Analog-to-Digital Converters Using a PC-Hosted Logic Analyzer

With today’s digital revolution in the electronics industry, analog-to-digital converters (ADCs) are increasingly common. ADCs can be found as either stand-alone parts or integrated into microcontrollers as special I/O peripherals. Depending upon the analog input accuracy require[1]ments of your particular MCU-based application, certain ADC specifications may require verification prior to releasing the design to production. This hint shows how to test analog-to-digital conversion integrity using a low-cost oscilloscope, an arbitrary waveform generator, and a PC-hosted logic analyzer (test setup shown in Figure 1). Specifically, this hint will examine differential nonlinearity errors as they relate to missing digital codes of the ADC.

Generating the test signal

A common test signal used to evaluate analog-to-digital converters is a voltage ramp. The voltage range for the ramp is the range of analog inputs applied to the converter for which it is expected to generate digital outputs. In this particular example where we test the integrity of an 8-bit ADC, the operating range is 0 to 5 volts. Because an ADC converts continuous analog voltages to a discrete number of digital codes, a conversion (or quantization) error will be introduced. In our case, each of the 256 possible digital output values represents a 19.5-millivolt voltage range for the analog input. In this example, we are testing for missing digital output codes. To ensure that the ADC has an opportunity to output the correct code for the given analog input value, we generate the voltage ramp slowly enough that the ADC has at least four chances to output each digital code. For this example, the input voltage change is about 19.5 mV every four sample clocks. Since our sample clock is 2 kHz, four sample periods represent 2 milliseconds.

Applying this voltage change over the entire 5-volt operating range results in a 1.95 Hz ramp. We also have to consider test signal noise on the ADC input. An input signal with 50 millivolts of noise could generate missing ADC output codes even if the ADC is operating correctly. Figure 2 shows an oscilloscope measurement using a Keysight Technologies, Inc. 54622A digitizing scope. The test signal was generated from a Keysight 33120A function/ arbitrary waveform generator. A close examination of an expanded portion of the signal shows that we have about 10 millivolts of noise. If the noise is significant enough to cause missing ADC codes, multiple applications of the ramp can be applied. If the noise is truly random, eventually we would expect to see all apparent missing codes. Capturing the ADC digital outputs Most logic analyzers have two modes of operation: synchronous/ state analysis and asynchronous/ timing analysis. The asynchronous sampling mode will produce timing waveforms, much like an oscilloscope. The synchronous sampling mode produces a state listing of captured data on most logic analyzers.