I have developed code for several embedded micros -- mostly Motorola and
Intel. I have always had (or had available, anyway) a reasonable
in-circuit emulator for development and debugging. We are now moving to
higher levels of integration and are considering developing a SuperChip
with a deeply embedded micro, possibly a RISC core. All the micros we've
considered so far interface to the emulator and debugger via the JTAG
port. While this may be adequate for setting breakpoints and peeking and
poking memory, there is one feature that these debuggers sorely lack: a
real time trace buffer.
This seems to me a major step backwards in ICE technology. We develop
fairly large applications (200-500kB), and the thought of of debugging a
once-a-day bug without a C source trace, or even an assembley language
trace, is most daunting. We could probably get something useful with a
logic analyzer, if we could find one that disassembles our core's
instructions, but decoupling the trace from the breakpoints, and giving
up the source level debug, really feels like a move in the wrong
direction.
Has anyone resolved these JTAG issues? Or is there something I'm
missing? Any observations would be most appreciated.
Dan McGuire
Using JTAG/IEEE 1149.1 has many advantages over traditional ICE. They are
truely non-intrusive (as opposed to ROM monitors), allow direct access to
internal registers (as opposed to software accessable registers), don't
require any code/memory space, don't require a socketed or bonded-out
processor, (some) can control multiple processors, and the debugger stays
with(in) the processor. I've used 1149.1 to debug military avionics computers
and comerical embedded systems using it 99% of the time. For the other 1%, we
needed a logic analyzer to catch some noise spikes and a few hardware bugs.
If real-time trace is needed, you can either use a traditional ICE (removing
the processor) or use a logic analyzer (like a HP 16500B) with their software
analyzer option. For a ASIC with a custom or embedded uP core, the cost of
developing an traditional ICE usually isn't justifiable. In these cases, a
scan based emulator is designed in or lifted as part of an original uP core.
The limiting factor for embedded on-chip emulators is the overhead for trace
memory. It's just not practial to include a significant trace buffer on the
device. Some devices, like some of the TI DSPs, make a compromise and include
hardware breakpoints and a small branch trace buffer. This, combined with the
fact that code executed in-line between branches is known, allows a
reasonable amount of code to be traced on-chip in realtime.
--
Regards,
Wayne Daniel
(214) 575-2582
wda...@ti.com
----------------------------------------------------------------
Dan:
A logic analyzer is indeed a good way to provide real-time trace
capability for a JTAG emulator. JTAG emulators and logic analyzers
complement one another very well. Between the two of them, you get almost
all of the functionality of a traditional hardware emulator, but with
several benefits: less hardware invasive (especially at higher speeds),
greater trace buffer depth, and lower cost to adapt to your next project
which uses a different processor. And now days, you don't even have to
give up source level debug. My company, Tektronix, recently introduced a
new product called LA-Browser which works in conjunction with our DAS/TLA
logic analyzers or LA-OffLine data viewer to provide a high-level source
code display of the data in the logic analyzer trace buffer. Basically
the logic analyers displays disassembled data in one window, while
LA-OffLine displays the corresponding source code in another. The two
are locked together such that when you move the cursor in the disassembly
display, the source code window automatically changes to show the matching
source code line, in context.
There are two factors which determine whether or not this solution will
work for you. First of all, is there a compatible disassembler available
for your micro. You apparently haven't decided on a specific micro yet, but
if you choose any of the popular micros in use today, chances are good that
we have disassembler support for it. The second criteria is the format
of the debug information provided by your compiler/linker/locator tools.
LA-Browser reads debug information from the object file created by these
tools in order to enable it to determine the source file and line number
corresponding to any given instruction address in your trace buffer. We
currently have support for most popular object file formats, including:
IEEE695, OMF86, OMF286, OMF386, COFF, X-Coff, Elf/Dwarf, Elf/Stabs, and
an simple ASCII format which can be used in a pinch.
Bob Heath
Logic Analyzer Group
Measurement Business Division
Tektronix Inc.
robert....@tek.com