SparkFun Forums

[Elijah]

Hi guys, I've can't seem to get JTAG working on a custom LPC2148 board. Let me explain my setup so we're all on the same page. I'm using the YAGARTO tool chain and OpenOCD debugger with the Eclipse IDE and on a win7 host OS. I bought the Olimex ARM-USB-OCD JTAG programmer and Olimex LPC-H2148 board from Sparkfun. I have some test code working on the header board (just blinking the LED with an interrupt routine). I loaded that on through the JTAG interface and am able to step through the code, set hardware breakpoints, etc so I know my tool chain and JTAG programmer are working.

Now, here's the schematic of the board in question: http://ad7zj.net/files/fc_01.pdf When I power it up and attempt to talk to it through JTAG, I get an error saying the JTAG communication failed:

target remote localhost:3333
0x00000000 in _vectors ()
monitor sleep 500
force hardware breakpoints enabled
monitor arm7_9 force_hw_bkpts enable
monitor poll
target state: unknown
monitor flash probe 0
flash 'lpc2000' found at 0x00000000
monitor flash erase_sector 0 0 0
failed erasing sectors 0 to 0 (-304)
monitor flash write_image main.bin 0x0
error writing to flash at address 0x00000000 at offset 0x00000000 (-304)
monitor reset
JTAG communication failure, check connection, JTAG interface, target power etc.
trying to validate configured JTAG chain anyway...
Error validating JTAG scan chain, IR mismatch, scan returned 0x00
Error validating JTAG scan chain, IR mismatch, scan returned 0x00
Error validating JTAG scan chain, IR mismatch, scan returned 0x00
Error validating JTAG scan chain, IR mismatch, scan returned 0x00
Error validating JTAG scan chain, IR mismatch, scan returned 0x00
Error validating JTAG scan chain, IR mismatch, scan returned 0x00
Could not validate JTAG chain, exit

All other conditions are the same as when it was working on the header board; unplug the JTAG connector from the header board and plug it into my custom board. As far as I can tell, the JTAG interface is hooked up almost exactly as it is on the Sparkfun header board. I was able to load some test code on through the serial port using the FlashMagic utility, so it's not like the processor is dead or something. I can see with a scope that the JTAG programmer is pulling the RESET line low when it tries to program. I've verified that P0.31 is high and P1.26 (RTCK) is pulled low during a reset as specified in the datasheet.

So, any ideas of what else to try from here? I appreciate any help in getting this working. Thanks,

Elijah

[hsutherl]

Any luck with this yet?

You might try reducing the jtag speed. Add something like

Code: Select all

jtag_khz 100

to olimex-arm-usb-ocd.cfg.

[Elijah]

Thanks for the quick reply. I did try reducing the JTAG speed by setting jtag_speed 2, but still the same issue. I tried using jtag_khz 100 as well, but no luck. It seems to me that since it's working with the header board, it should also work on my board since they're identical processors (unless of course there's a hardware problem, but I've looked many times and been unable to find any differences). I paste-binned my OpenOCD config here: http://pastebin.com/WzxYEtYN Any other thoughts, or see anything wrong with the schematic?

[krkan]

Is JP1 jumper set?
Is it attached firmly to the pins? (Some time ago I had some problems with loose jumpers on one development board)

Test microcontroller JTAG pins for short-circuits. Take a good look and try to find possible problems regarding soldering process.(Board was soldered by some automatic process, or "by hand"?)

I'm not working with ARM7 chips, but is it possible to pull-down (with 10kOhm) pin 17 on that JTAG connector?

[Elijah]

Thanks KrKan, the jumper does seem to be good, as I can verify with a scope that the pin is indeed pulled low. I did reflow the board by hand, but have run continuity tests between the JTAG pins and uC pins. If it would be helpful, I could also try and post some screenshots of a scope showing the waveforms during attempted programming.

I haven't tried pulling pin 17 low; as I understood, it was unused, but I will definitely try that. Will let you know how that goes. Thanks for all the suggestions... keep 'em coming!

[d4n1s]

may I ask why are you using DBG and why are you using pull downs to GND on RTCK and TCK even if the manual doesn't instruct so?

[leon_heller]

10k - 100k pull-ups on TMS, TDI, TRST, and TCLK are recommended by ARM to prevent the signals floating when they are not connected.

[Elijah]

Pulling down pin 17 as recommended by KrKan didn't seem to change anything. I used what was used on the Olimex header board, because it worked and I figured you can't go wrong with something that works. Leon, you think TCK should be pulled high instead of low? Could one of you guys point me to the documentation where you're finding this?

[krkan]

Just to eliminate possible problems with the external oscillator - have you tried to use the internal RC oscillator as a main clock source?
That way you can detect if there are any problems with XT2 crystal.

[Elijah]

As far as I know, the LPC2148 doesn't have an internal RC oscillator; you have to use an external crystal. I think the crystal is fine though, because test code loaded through the serial port runs at the correct speed and you can verify with a scope that there is a perfect 12 Mhz sinusoidal waveform being generated on the OSC pins.

[krkan]

I am right now working with one Cortex-M3 board and have forgot that there is no RC in LPC21xx. Sorry.
Looked at the JTAG pinout, seems to be OK.
Since you are using 12V power supply is it from some battery or power line adapter, or you are using step-up converter on the ARM-USB-OCD debugger?

As a last resort -> you have made only one board, or do you also have a spare one?

[hsutherl]

Your config file is the same as one that works here (under XP) with the same olimex arm-usb-ocd jtag interface and the same header board. If it doesn't work at 100 KHz I doubt it is a layout issue. Has to be a hardware problem.

The LPC214x user manual from NXP suggests 4.7 - 10k pull-ups on all 6 JTAG pins.

Since you can program via serial port, if you have plenty of time and no other solution, I suppose you could make a program to test the TMS, TDI, TRST, and TCLK as GPIO in, and TDO as GPIO out. That would at least determine whether the pins are "blown", but would not help with a case where they're GPIO rather than JTAG after reset.

(The .cfg file I mentioned earlier was from a Linux install of openocd.)

[d4n1s]

Code: Select all

http://olimex.com/dev/pdf/arm-jtag.pdf

PIN.9 (TCK) JTAG clock.
PIN.11 (RTCK) JTAG retimed clock.
Implemented on certain ASIC ARM
implementations the host ASIC may need to
synchronize external inputs (such as JTAG
inputs) with its own internal clock.

However,

PCB design considerations:
Use single point to point connections between
ARM core and JTAG connector. The length of
all tracks must match to within 2-3 cm (1”).
JTAG connector should be placed as near Arm
core as possible. If lines are longer than 5 cm
(2”) they should be series terminated at device
end with series resistors equal to the
characteristic impedance of the PCB tracks and
the connector.

but still it doesn't mentions anything about pulls...

I have seen olimex boards my self and your right that their using these resistors, but I can't find why, I guess leon can tell us.

[d4n1s]

Here is something interesting... http://www.micro4you.com/files/ZP2148.pdf

[Elijah]

Thanks guys, I'm using a 12v switching PS for testing. That's a little 3.3v switching regulator on the board, but the output is dual filtered and has a ripple of a few mV, so I would think that's clean enough. The only discrepancy I was able to find in the arm-jtag.pdf manual was they suggest pulling TCK to Vcc instead of Vss. Again though, the Olimex board has it pulled to Vss and works, so I doubt that's the problem. Some boards like that one you posted don't have any pulls. This does seem very weird, but that's a good idea to try testing them as GPIO pins. I'll try that later tonight. We'll see what that turns up, perhaps that's been the problem all along. Probably wouldn't have been a bad idea to put some ESD protection on the JTAG lines.