K9JTAG
JTAG Debugger for ARM Microcontrollers
K9JTAG
Schematic Diagram
Parts List

BBMICRO Development Board

LPC2103 ARM7TDMI-S Microcontroller

This is a parallel port JTAG Debugger circuit for Philips LPC2xxx ARM microcontrollers. I have built it without the 22pF filtering capacitors and briefly tested it with ocdremote at speed 8, and it worked! Higher speeds don't always work, maybe something to do with the +5V power I'm stealing from the parallel port. Speed 4 works fine the first time after boot up, but if I re-start ocdremote for a second debugging session, it often doesn't connect at speed 4. I'm thinking maybe it is turning off power the INIT pin that my parallel port provides the most current from when exiting.

The circuit is intended to be backwards software compatible with "wiggler" JTAG debuggers. Originally based on Leon Heller's "wiggler" clone schematic, then tweaked by suggestions from the LPC2000 Yahoo Group members.

Click here for a parts list with links to distributors for each component used on the schematic.

Read on for descriptions of what are hopefully improvements made by the K9JTAG "wiggler" compatible JTAG debugger circuit.

Noise Filtering

The 1K/22pF RC circuits are intended to provide low pass filtering of the input signals. I built it without soldering down the 22pF capacitors and it seems to work fine. The 74HCT14 input pin capacitance (5pF typical, up to 10pF max) probably provides enough low pass filtering anyway. The 51 ohm resistors provide series termination. I'm not sure how to determine what values should be used for best performance without building the circuit and experimenting. 51 ohms was used in Leon's original schematic, while ARM Application Note 31 uses 47 ohms instead. Experiment and modify resistor/capacitor values as necessary.

This circuit uses a 74HCT14 and a 74VHC14 hex inverter with schmitt trigger to help provide clean signals and voltage level conversion. The 74HCT14 chip is powered at 5VDC to drive the parallel port with full 5V logic levels. The 74HCT14 has input voltage thresholds compatible with 3V logic. The other inverter chip is a 74VHC14, which will run off the target board's power (3.3VDC for my LPC2103). The 74VHC14 is used because it can accept input voltages greater than the supply voltage, allowing us to step down from 5V logic to 3V logic.

Note that you should not use the 74VHC14 for the 5V side of the circuit. When the 74VHC14 is powered from 5V, it's input threshold voltages leave very little margin for 3V logic signals to work properly. Similarly, you should not use the 74HCT14 for the 3V side of the circuit because the 74HCT14 will be operating outside of it's absolute maximum ratings when powered at 3.3V and having input pins driven at 5V logic levels.

Power

The circuit is intended to pull +5VDC from the parallel port's INIT signal (pin 16) or DATA7 signal (pin 9). I get about 60mA to 75mA at 4.4VDC from INIT pin on my parallel port. Using DATA7 as suggested here was considered, but I can only seem to get about 2mA of power out of this pin on my parallel port, so it's not going to do much for me. Depending upon how much power your parallel port can provide, it might not work. The circuit can be powered off of the target board's +3.3VDC power, which should still hopefully be enough voltage to drive your parallel port's input signal lines. In a pinch, if neither works for you, you can connect an external +5VDC power source to the 5V LDO regulator through J4.

Additional Signals

The original "wiggler" never provided means for reading back the optional RTCK signal from the target. This signal should not be necessary at parallel port speeds, but we added it anyway because we have an extra pair of gates and someone might want to play with it. If it turns out that this connection some how breaks backwards compatibility with existing host software, it should be easy to remove resistor R12 to disable the feature.

The Macraigor Wiggler seems to have control of the TRST signal through DATA4 of the parallel port, while many "wiggler" clone schematics fail to include support for this signal. I'm told that this signal is optional, but I'm sure it doesn't hurt to include it, especially considering that existing host software may even be expecting it.

Copyright © 2006-2007, K9spud LLC.