Engineer999
Engineer999

Reputation: 3955

What's inside a debugger box and how does it work exactly

I'm working with an iSystem debugger box used for debugging automotive embedded systems.

I can't help but wonder what is inside such boxes and how they work exactly.

I understand only that there is a USB interface on one end and a JTAG interface on the other. There will be electronics to convert the USB signals to TTL I guess, but after this I'm not sure.

Is the box just responsible for setting breakpoints in our code in real time over the JTAG interface (commanded by us) and relaying information about the state of the MCU back to us over USB? What would be in there exactly that makes it so complex and expensive?

Upvotes: 1

Views: 662

Answers (2)

Clifford
Clifford

Reputation: 93556

On most modern processors, most of the heavy-lifting for debugging is performed on-chip. Before on-chip debug was common, in-circuit emulators were very complex and even more expensive - I remember renting one for an Intel 8051 project, for a weekly rent probably greater than the cost of most JTAG pods. The thing was also a large book-sized slab with an expensive and fragile debug probe that you plugged into your board instead of the processor.

Even though the on-chip debug provides services such as instruction level single-stepping, break-points and memory and register access, the debug host needs to do some work. While often that work is performed by the host PC, on more expensive debug hardware solutions it is often implemented on the debugger interface.

For example the GNU debugger GDB requires a "GDB stub" - a software interface between the host debugger software and the target hardware. The GDB stub may run on the target - for Linux for example this allows "remote debugging" over a network or even a serial interface without any debug hardware, but is unsuited to bare-metal and board bring-up debugging. In other cases the stub runs on the host - the common OpenOCD for example provides this for very simple JTAG on-chip debug hardware. In more expensive debuggers, the stub might run on the debugger hardware itself, so the hardware must have processing capability.

The physical interface for JTAG or proprietary on-chip debug interface is trivial. Implementations using host resident debug software such as OpenOCD, need not be very sophisticated at all. In fact in days when PCs had parallel ports for printer connections, it was possible to use this to drive the JTAG signals, so the hardware was completely dumb - the so called "Wiggler" design. Simple modern "wiggler" type designs are also dumb, but require typically a USB to parallel port device chip, or a small microcontroller to perform that function. These often are quite slow.

More complex debuggers typically contain a microcontroller to provide the USB device interface and faster I/O for the JTAG. Devices that support debug trace require relatively higher speed I/O and the ability to transfer large amounts of data quickly.

All the iSystem debuggers at https://www.isystem.com/products/hardware/on-chip-analyzers.html also have Ethernet connection and large high-bandwidth on-board debug trace buffers, and analogue and digital inputs for monitoring the connected system in parallel to the code debugging. They appear to be far more sophisticated that a typical low-end debugger that you describe as "a USB interface on one end and a JTAG interface on the other". This would suggest that they have capabilities over and above a simple debugger.

The iSystem devices also support multiple architectures where most low cost solutions are architecture specific or rely on the host to support multiple architectures. Nothing in particular makes them architecture specific at the hardware level.

Ultimately the price you pay bares little relation to the cost of the physical hardware - a $35 Raspberry Pi probably has greater capability than even the most sophisticated of JTAG debuggers. The volumes for these devices, especially the high-end devices are low, and the development costs relatively high, so what you are paying for is the amortised development cost, expertise and ongoing sales and technical support provided by the vendor/manufacturer. As a developer yourself you will appreciate that these things are not free if you make a living and your company makes a profit. Looking at the iSystem documentation, you are also not just buying the hardware - the package includes the WinIDEA debug software as well - whether that is worth anything is a matter of opinion, I am not familiar with it.

If your debug needs are satisfied by "USB interface on one end and a JTAG interface on the other.", perhaps you did not need a device as sophisticated as the iSystem. It supports the function of an oscilloscope and logic-anlyser as well, but synchronous with code instruction trace - very powerful for complex systems.

Upvotes: 1

Turbo J
Turbo J

Reputation: 7701

What would be in there exactly that makes it so complex and expensive

Nothing. But these sell in low volumes only - I would expect between 1k and 10k units to be sold for a specific debugger, maybe even less.

But you still have fixed development costs - for both hardware and software. This results in a high per-unit cost that is not really related to hardware at all.

what is inside such boxes

Usually some USB-enabled microcontroller and a level shifter, sometimes with isolation (that you would need for automotive ISP applications).

Upvotes: 0

Related Questions