Tutorial: On-chip MCU debug and the end of the (off-chip) ICE Age

Designers have had a long love-hate relationship with the traditional in-circuitemulator (ICE). On one hand, they provide valuable insight into theinternal operations of a microcontroller during the development anddebugging process.

Unfortunately they also have a few less desirable traits. They areexpensive, the interconnection systems tend to be complex and difficultto work with, and as hard as the designers try, they never quite do aperfect job of emulating the real microcontroller.

Many application systems are so small that it is impossible toconnect an emulator in the real application system. Other applicationsare embedded into machinery where an emulator connection wouldinterfere with normal operation of the machine.

Traditional in-circuit emulators also imply that the address anddata information from the microcontroller is visible on themicrocontroller's pins. Typically address, data and a few controlsignals are provided as alternate functions on several MCU pins.

When the device is used in an emulator, the normal I/O functions ofthese pins are rebuilt with custom hardware in the emulator. Althoughthese rebuilt I/O functions can be made to emulate the function of thereal microcontroller pins, they usually cannot exactly duplicate subtletiming and drive characteristics of the original MCU pins.

In cases such as the smallest 8-pin microcontrollers, where themicrocontroller doesn't have enough pins for address and data, theemulator must use some sort of special bond-out device or completelyemulate the function of the small microcontroller.

In order to better understand the need for a new emulation approach,consider a few practical application systems. Small hand-held devicestypically have the MCU squeezed onto a very dense circuit board insidea small enclosure with very little space for wiring to supportdevelopment and debug. Attaching an emulator cable in place of the MCUis not really a practical option, but running ground, reset, and asingle background communications signal can be done in the finalproduct form-factor.

In the case of automotive electronics, consider the controller in anautomatic transmission. It isn't practical to connect an emulatorumbilical to the electronic control module under the car. However youcould run ground, reset, and a single background communication signalthrough a small cable to the inside of the vehicle and perform fullreal time debugging as the car is driven on a test track.

Implementing on-chip debug
To resolve such issues, some new microcontroller architectures, such asthe HCS08and HCS12,incorporate two key additional elements: (1) a single-wire background debuginterface and (2) on-chipdebug logic with the functionality of an emulator including a bus stateanalyzer inside the microcontroller.

With these two elements you can completely eliminate the need for anexpensive external emulator box and the nasty interconnect problems.Since none of the pins on the microcontroller are used by this on-chipdebug system, there is no need to rebuild anything in external hardwareand the emulation is exact, including subtle timing and drivecharacteristics.

The single-wire background debug interface is similar to thebackground access ports which have become common on modern MCUs exceptthis system uses only one MCU pin. On some cost-sensitive consumerMCUs, this pin can be shared with other general purpose outputfunctions, but ideally it would be a dedicated pin. This backgroundinterface allows a developer to program the Flash memory at the end ofthe production line or re-program the Flash in the field.

During debugging, this background interface can be used to read orwrite memory and registers in the MCU (without stopping the applicationprogram). It also allows for stopping the application program, readingand writing CPU registers, single-stepping, and setting up basichardware breakpoints. Although this single-wire background debuginterface is separate from the on-chip ICE functions, it is aconvenient way to setup emulation runs and read out the results ofreal-time traces.

The on-chip debug support logic includes address, data and R/Wcomparators as well as trigger control logic similar to that on atraditional emulator. (See Table 1 below for a brief summary oftrigger modes supported by the on-chip debug system.)

Like almost any ICE, you can capture bus information before or afterthe trigger event. You can choose to stop execution of the applicationprogram at the end of a trace run, or you can keep running after thetrace information has been captured. You can even set an independenthardware breakpoint to occur at some point after the trace informationis captured. This delayed breakpoint is especially helpful when circuitdamage can be caused by stopping the application at certain times, suchas while the controls to a motor H-bridge driver are being changed.

Table1: The on-chip debug system supports nine trigger modes. An additionaladdress comparator C is available to set an independent breakpoint. Inthe HCS08, breakpoint C is in the background debug module so it is onlyaccessible through a BDM pod. In the HCS12, breakpoint C is accessiblethrough BDM or the serial monitor.

The bus capture buffer is a little different than that on atraditional emulator because buffer memory is still relativelyexpensive in terms of silicon area. Because of this, the on-chip systemis more selective about what gets stored into this memory.

Traditional emulators take the blunt approach to capture the addressand data for every bus cycle and then worry about sorting out what isuseful after the trace run is finished. In these new on-chip systems,most trace runs capture only the address information from change-of-flow (COF) events. The host debug software can easily fill in the gaps betweenthese COF entries.

One benefit of having the trigger logic on chip is that it hasaccess to internal CPU control signals. This allows a user to configurea trigger to occur when an instruction has propagated through theinstruction queue and is about to be executed. This is called atag-type trigger as opposed to a force-type trigger that fires as soonas a comparator match occurs. In another case, the newest MCUs use CPU signals to allow the capture mechanism to ignore “free” cyclesin order to avoid filling up the capture buffer with unimportantinformation.

If you use an available serial monitor program in the target MCU,you can connect the target system to your PC with a simple serialcable. An alternate connection method would be to use an inexpensiveBDM pod for the connection from the host PC to the target MCU. Bothconnection methods provide the same debugging capabilities but the BDMpod is completely non-intrusive. To support our implementation ofon-chip debug on the HCS08 and HCS12, a special edition of CodeWarrioris available which provides full access to the applicable debugfeatures.

You use the same techniques to set up triggers as you would use toset simple breakpoints. The user interface is smart enough toautomatically select some trigger settings based on context. Forexample, if you right-click on an instruction line in a source codewindow, the debugger knows that you want to set a tag-type trigger onan instruction.

If you right-click on a data value in a memory display window or avariable label in a software variables' window, the debugger knows youwant to set a force-type trigger at the selected memory address. Aftersetting the trigger address, additional pull-down menus allow you tospecify the conditions for R/W and whether you want to trigger on aspecific data value at the selected address. Some trigger modes requiretwo trigger addresses and the debugger recognizes that you are tryingto set up one of these triggers when you right-click on anotherinstruction or another memory location.

No External Emulator Required
A typical in-circuit emulator has an external box connected to thetarget system with some sort of wiring harness, including dozens ofwires. With this on-chip debug system, the capture memory is inside thetarget MCU; you just need a way to set controls and read results. Thereare at least two ways to do this. The preferred way to connect thetarget system to the host PC is through a background debug pod becauseit allows completely non-intrusive access to the target system througha single dedicated pin on the target MCU. USB versions of BDM pods areavailable.

The second way is through a simple RS232 serial cable from the PC tothe target system. To use this option, you need a small 1 KB to 2 KBserial monitor program in the target MCU. Evaluation boards for theMC9S08GB60, MC9S12E128 and MC9S12C32 all support the serial monitoroption. The CodeWarrior debugger looks and works the same regardless ofwhich connection option is used.

Figure 1 below shows theresults of a trace run using the on-chip bus state analyzer. Beforerunning the program you want to debug, you open a trace window in theCodeWarrior tool. You can see the source code partly hidden by thetrace window on the left side of Figure1 .

The red A in the left column just above the JSR ,X line isthe trigger point for starting the bus capture. We set this byright-clicking on that source line. In the two lines below, there is ared arrow in the left column indicating that we have set a breakpointthat will fire after we finish the JSR to SpSub that has been relocated to the stack. When we run this program, the buscapture starts when we reach trigger point A and stops when the buffergets full. A little later, the program will stop when it reaches thebreakpoint after theJSR .

Figure1: Source and trace windows showing the results of a trace run. As thecursor is moved over lines in the trace window the line, 4, in thisfigure, is highlighted and the corresponding line in the source code isalso highlighted in grey.

After the program stops, the CodeWarrior tool reads the contents ofthe trace buffer and fills in the trace window. This window includesframe (line) numbers for reference, program addresses, program data,re-constructed instructions and comments. Lines that include thecomment DBG FIFO are the only bus cycles that were actually capturedinto the on-chip bus capture FIFO buffer. All other lines correspond tocycles that the host debugger has reconstructed based on knowledge ofyour source code and the change of flow events that were in the FIFO.

In the portion of the trace that we can see in Figure 1 , there are only threechange-of-flow events. Frame 4 is an indexed JSR so the FIFO capturedthe destination address that corresponds to frame 5. Frames 26 and 32are both branches that were captured as change-of-flow events becausethe branch was taken. Frame 0 is a special case. The CodeWarrior toolknows this address was executed because the trigger was set at theinstruction at this address.

The comment “Instruction outsideapplication ” indicates that the addresses in frames 5 through 34do not correspond to addresses in the source program. Usually thiswould indicate an error, but in this case it corresponds to when theCPU is executing the SpSub routine that we copied onto the stack beforecalling it. Note the addresses are in the area around through 0x0FE80x0FFE .This area is near the top of the stack RAM.

As you move the PC mouse over lines in the trace window, thecorresponding line in the source code is highlighted gray so you canassociate events in the trace with the source code. In Figure 1 , Frame 4 is highlighted inthe trace window and the JSR ,X line ishighlighted in the source window.

The reconstructed instruction sequence in the trace window providesmuch useful information to developers as they debug their program. Wecan see that the LDA at the trigger address and the highlighted JSR ,X wereexecuted as expected in trace frames 0 through 4. In frame 5, we seethat the indexed JSR took us to address 0x0FE8 in stackRAM and executed a LDHX 28,SP instruction that corresponds to the ldhx.

The instructions executed in frames 5 through 34 are in therelocated copy of the SpSub routine,not the original routine from the source code that is located at adifferent address in the Flash memory of the MCU. When the programreaches the branch (BPL) instruction in frame 26 and 27, we see fromthe comment “DBGFIFO ” and the address 0x0FF9 in frame 28 that the branch wastaken. This loop near the end of the SpSub routine iswaiting for the Flash programming operation, which is beingautomatically controlled by an on-chip state machine, to finish.

Next in Part 2: Putting on-chipdebug to work

References :
1) Eduardo Montañez,”Using the HCS08 On-Chip Debug System,” Freescale Application Note, AN2596/D.

2) Motorola, HCS08 FamilyReference Manual Volume 1, 2003.

3) J. Sibigtroth, “SerialMonitor for MC9S08GB60,” Freescale Application Note, AN2140/D.

4) J. Williams, “SerialMonitor Program for HCS12 MCUs,” Freescale Application Note, AN2548/D.

Jim Sibigtroth has worked for Freescale Semiconductor (formerly the Semiconductor ProductsSector of Motorola, Inc.) for more than 27 years and is currently asenior systems engineer in the 8/16-Bit MCU Division of theTransportation and Standard Products Group. Jim defined the originalMC68HC11 and wrote the M68HC11 Reference Manual, commonly known as the”Pink Book.” More recently he defined the CPU12 instruction set and thesingle-wire background debug interface that is on all HCS08 and HCS12MCUs.

Eduardo Montañez has workfor the past five years at Freescale Semiconductor (formerly theSemiconductor Products Sector of Motorola, Inc.) as a Systems &Applications Engineer in the Microcontroller Division.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.