|
We decided to create a new product using the OpenBSD operating system
running on an embedded MIPS32 core (specifically the Alchemy Semiconductor
AU1500). When we went to purchase a JTAG emulator for the board we were quite shocked at the prices and
the overall type of devices available. Having a good knowledge of JTAG and what it does, it has ALWAYS been a
sore spot to see all these high dollar, complex, proprietary JTAG emulators.
Here are some things to know about JTAG:
|
* The JTAG interface on all devices in the world works the same
* The JTAG interface is very simple
* You should be able to purchase 1 jtag access device and use it on all products
|
A common scenario is to have to purchase a $2000.00+ proprietary JTAG access pod from whomever makes your
development tools. The development tools you use will only work with their JTAG access pod.
You get no ability to use your new JTAG access pod for anything except emulation. However, JTAG can be used
for many other things than emulation such as hardware validation and programming of flash memories. If you
want to do these things you will have to purchase yet another JTAG access pod. So in your collection of JTAG
access pods you have 1 for every different design you have worked on and 1 generic one for testing and flash
programming. This gets expensive fast and is absolutely not necessary.
With this product we are going to use the GNU tool chain which uses the debugger
GDB. These tools are FREE, open source, and work excellent. After a bit of research we found a couple of JTAG
emulators that claimed compatibility with GDB that would work on the MIPS32 core. We almost purchased one until
I called them and asked them if their device would work for what we are doing. They promptly told me they would
have to check and call me back. No one ever called me back, so considering these things cost $2400.00 each, it
must not work as well as they claim. Also, their product requires installation of special software and/or special
versions of GDB that they have created. This is somewhat of a problem because they don't want to make binaries
for every OS out there and I'm not using Cygwin or Linux. (which is what they support)
We decided to make our own VERY cheap and VERY functional JTAG emulator. Since JTAG requires only 3 wires out and
1 wire in its easily accomplished via the parallel port of a PC with about 3 bucks in hardware. Pictured above
you can see how small the hardware is. (the board pictured is our target hardware not the emulator! The emulator
is attached to the end of the parallel cable on the bench)
Basically the hardware
consists of a buffer chip and a handful of resistors and capacitors for filtering noise.
We wanted this device to work with GDB without making any modifications and it turns out this is very easily
done. GDB supports what is known as
the remote serial protocol (RDP for short). You can start up GDB and tell it you are debugging a remote target and it will
use this protocol to perform all debugging operations. All you have to do is tell GDB how to find the remote target
which is over TCP/IP with this device.
What we did is write a software application (the whole design will be released open source soon) that you run in the background
that listens on a TCP/IP port of your specification. This application knows how to talk RDP and is ultimately what
GDB talks to for debugging. The application also knows how to wiggle the bits on the parallel port via our hardware
to perform JTAG operations. The application also knows how to perform EJTAG (extended JTAG which is MIPS extensions
to JTAG to perform emulation - More on this below) operations to perform emulation of the processor.
All said and done, here's the advantages of our design:
|
|
* Its dirt cheap.
* It works with ANY GDB on ANY platform with NO modifications.
* You can use it yourself for flash programming and hardware validation.
* The whole design is easily portable to other platforms.
* It could be easily ported to new processor types.
* Using TCP/IP the target is accessible from anywhere in the world, not just on your desk.
|
Now it is true that using the parallel port for JTAG is nothing new. There are several products out there that
do just that. Two that I can think of are
The Wiggler and JTAG for the lart project. Both of
these are good products and can even work with this package because they are ultimately the same as our hardware.
You could even buy one of these and use our software with it, you would simply need to change what pins are used
for what on the parallel port. It is also known that the parallel port is not the fastest way to do this stuff.
That's why in the future we plan on making a CHEAP open source design that uses an Atmel AVR microcontroller
that has a TCP/IP stack and real JTAG hardware for super fast speeds.
Click here for a diagram on how it all ties together with 1 computer.
Click here for a diagram on how it all ties together with 2 computers.
Click here for a tutorial on JTAG.
Click here for a breakdown of how the JTAG emulator software works.
The overall solution exists as a parallel port buffer which you can
build from this schematic.
So basically, you hook up that parallel port devices to your target and run the daemon on that same machine. (Unix daemon
you can compile on any target) The daemon listens to a port which you direct GDB to use with the 'target remote
command. The daemon translates GDB RDP commands into actual JTAG commands on the parallel port.
Here is the tarball of the sources.
Here are the sources individually for your viewing pleasure:
asmtoc.pl
gdbrdp.c
gdbrdp.h
jtag.c
jtag.h
jtagemul.c
jtagsock.c
jtagsock.h
makefile
mips32.c
mips32.h
parport.c
parport.h
entryhiread.s
hwbkptread.s
hwbkptwrite.s
led.s
readbyte.s
readdebug.s
readhalf.s
readregisters.s
readword.s
singlestepclear.s
singlestepset.s
writebyte.s
writehalf.s
writeregisters.s
writeword.s
Special notes on building this daemon
First of all, this code is a little more complicated than even a cross compiler because the x86 based machine
must spoon feed Mips32 assembly instructions across the JTAG port to accomplish primitive actions such as
modifying registers, reading memory, etc. So in the source tree for the daemon are a pool of .s files which
are assembly files for the Mips32 architecture. You must have a GNU Mips32 cross compiler installed to build
the daemon. The cross compiler is used in the makefile to generate listings from the .s files that contain
HEX notation of the Mips32 instructions. Furthermore you must have perl installed because after the listing files
are generated a perl script converts them into actual C files containing HEX arrays of instructions for the
daemon to feed to the target.
If you want to try and use this code, or mature it some more please contact us and we'll be more than
happy to support you. We used NetBSD to build this system because cross compilers are available from the
native ports collection which is VERY nice.
|
