Debug Is About To Get Really Interesting Again

Running trace and in-field debug through I/O is long overdue.


One of the great unheralded chapters in the history of electronics design is debug. After all, where there have been designs, there have been bugs. And there was debug, engaged in an epic wrestling match with faults, bugs and errors to determine which would prevail.

Think about system in the 1970s and ’80s. A typical system would consist of a CPU, (EP)ROM, RAM, Peripherals (PIC, UART, DMA, TIMERs, IO…) each implemented in their own IC.

The typical development flow was to write your code in ASM or C and get it compiled, linked and located so that you ended up with a HEX file for the ROM image. You would then take the old EEPROM out of the sockets on the target board, place the EEPROMs into a UV EEPROM Eraser and blast them with UV light for 20 minutes. You then placed the EEPROMs into an EEPROM programmer and downloaded the HEX file from your computer (typically via a serial or parallel interface) and then programmed them up.

You plugged the EPROMs back in to the target, powered it up and to see if your program worked. If your program didn’t function as expected, you had some options to debug your code:

  • Code inspection. You would walk through your code staring long and hard at it looking for errors. Some people still use this approach, especially those who view the use of any debugging tool as a failure of programming skill.
  • LEDs (Stare at them. Really). You could determine the path through your code by modifying the code to signal a state at significant places in the code. You could then just look at the LEDs to see the progress (or often lack of progress) through your code.
  • On-target monitor: Step through your code at the assembly level. Remember assembly code?
  • In-circuit emulator: The ultimate debug tool, if you could afford it.

Over the decades, debug circuitry migrated on chip, making things a little easier, a little faster. But external trace started to strain with design complexity and increasing CPU clock speeds. Through the 1990s, various techniques were used to maintain the effectiveness of trace-based system, such as compressing the trace data, which could then be transported more easily off chip.

In the early 2000s, ARM introduced the Embedded Trace Buffer (ETB), accessible via JTAG and configurable in size to hold the trace data. This solved the issue of having to provide a relatively high speed off-chip trace port (though still nowhere near core clock speed) at the expense of using silicon area in the SoC.

Then came the ARM Embedded Logic Analyser (ELA), which enabled access to complex on-chip breakpoints, triggers and trace with access to internal SoC signals.

Today, we’re on the cusp of a new era in debug, one in which engineers can do debug and trace over functional I/O.

Tipping point
Anders Lundgren, Product Manager at IAR Systems, put it best: “We are about to see new ways to access debug capabilities, from JTAG or no debug connectivity, to debug and trace protocols running over existing interfaces,” he said in an interview.

Heralding that new era, ARM has announced CoreSight SoC-600, which implements the latest ARM debug and trace architecture to provide developers with high-throughput trace and in-field debug accessibility through existing functional I/O. It allows embedded software developers and system integrators to efficiently make debug and trace agnostic to the underlying connectivity, by re-using existing links already available in the final device (for example USB, PCIe). More product information can be found here.

“This will enable debug capabilities throughout the product lifecycle,” Lundgren said. “The expected proliferation of trace availability and increased bandwidth is a big step towards analyzing complex problems and fine-tuning performance. We can get to the root of the problem faster, cut costly iterations, risk & time to market.”

Robert Redfield, director business development at Green Hills Software, noted that it’s not uncommon for customers to have a successful development campaign, but later run into system performance issues. Developers often mistakenly think they have large-scale performance analysis capabilities with ETM (Embedded Trace Macrocell) and ETB (Embedded Trace Buffer). This is not the case. ARM has now resolved this, with higher trace bandwidth capabilities from the new CoreSight SoC-600 IP.

Redfield also noted that Green Hills Software and ARM have a 20-year history of collaboration on debug and trace solutions. “We applaud the continued enhancement of CoreSight in the release of the SoC-600 platform,” he said. “Our MULTI IDE, Probes and TimeMachine trace debugging suite will benefit from the new platform features, including more detailed system analysis through higher trace bandwidth, and more widespread availability of debug interfaces in deployed devices by reusing functional I/O.”

Leave a Reply

(Note: This name will be displayed publicly)