JTAG Not Working on Custom LPC2148 Board

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](Header board for LPC2148 - DEV-00676 - SparkFun Electronics)](JTAG USB OCD Programmer/Debugger for ARM processors - PGM-07834 - SparkFun Electronics)

Any luck with this yet?

You might try reducing the jtag speed. Add something like

jtag_khz 100
``` to olimex-arm-usb-ocd.cfg.

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?

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?

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!

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?

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

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?

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.

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.

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?

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.)

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.

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

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.

Hi guys, we may have found the problem. TRST, TCK, RTCK, and TDO toggle, but TDI and TMS are just stuck high. I’ll post my test code for a second set of eyes to make sure that’s not a problem. (IO0 is blinking an LED)

void IRQ_Routine(void) {
	if(set) {
		IO0CLR = 0x20000000;  // Toggle P0.28 & 29
		IO0SET = 0x10000000;
		IO1CLR = 0xFD000000;  // Toggle P1.24 and P1.26-31
		set = !set;
	}
	else {
		IO0CLR = 0x10000000;
		IO0SET = 0x20000000;
		IO1SET = 0xFD000000;
		set = !set;
	}
    TIMER0_IR = 0x01;           //clear interrupt by writing a logical 1
    VICVectAddr = 0;            //end of interrupt - dummy write to the vector address register
}

And a shot of the output. RTCK is in yellow, and TDI and TMS in purple and blue

http://i51.tinypic.com/21ki1xk.jpg

See what you guys think…

Interesting. I’ve shouted “bad chip” too soon so many times in the past that I’m reluctant to do it again, but…

Obviously you set IO0DIR and IO1DIR during initialization. Did you write anything to PINSEL2. bit 2?


BTW, everyone please disregard my earlier claim that NXP recommends pull-ups on all 6 pins. What I read was paragraph 22.5, which says to pull P1.26/RTCK down, and says nothing about the other pins. I can’t explain the error.

Oops, I should have posted the main() function too.

int main(void) {
    int i;
    IO1DIR |= 0xFD000000;	// P1.24 output
    IO1SET =  0x01000000;
    IO0DIR |= 0x30000000;   // P0.28-29 outputs
    init();
    TIMER0_TCR = 0x02;                           //reset counter
    TIMER0_IR = 0xff;
    TIMER0_MCR = 0x0003;                         //interrupt and reset on MR0
    TIMER0_MR0 = 0x03938700;                     //compare-hit count
    VICVectCntl0 = 0x00000024;              //use it for Timer 0 Interrupt:
    VICVectAddr0 = (unsigned)IRQ_Routine;   //set interrupt vector in 0
    VICIntEnable = 0x00000010;              //enable TIMER0 interrupt
    TIMER0_TCR = 0x01;                           //enable Timer0
    enableIRQ();

    while(1){

    }
}

I don’t write to PINSEL2, as far as I understood, it defaults to GPIO. Surely it wouldn’t have to be set a 1 to work with JTAG, right? The datasheet leads you to believe that so long as RTCK is held low during boot, it’ll come up as a debug port. I will try writing a 0 to that though and see if it solves the problem with using them as GPIO pins.

Yeah, no luck setting bit two of PINSEL2 to 0. When I set it to 1, of course none of them work as GPIOs, but the JTAG still doesn’t work. Set to zero, TDI and TMS still don’t toggle. I guess we’re forced to conclude it’s a bad chip… next chance I get, I’ll pull it off and solder on a new one. Hopefully that’ll solve the problem. Next revision of the board will have ESD protection on all the external I/O lines.

Before pulling the chip you might consider:

a) Find a bare board and check for shorts between pins 52 and 60 of the LPC2148 to Vdd. It may be an issue with the board (e.g. under-etching, spacings too close etc).

b) Use an exacto-knife or fine-point tool and, using deft soldering, lift the two pins in question off the board just enough to break the connection to the board. Then either scope the pins with your I/O test code to see if they toggle or flywire them to the JTAG connector. If things work you probably have an issue that that particular board. It may be an etching issue like ‘a’ above but it may also be a solder issue. You could do a continuity check between TDI and TMS to Vdd on that board with no connection to the '2148 to check for shorts on the board.