LPC2138 and Xilinx in jtag chain - can't get it to work

Development Boards MicroMod
1

Hi,

I have a development board which has an LPC2138 and a Xilinx both in the jtag chain. I’ve been trying for days now to get the configuration to work, and not getting anywhere.

The board has resistors on it for configuring the JTAG chain so it can either have the CPU or the Xilinx or both, in the chain. It has been tested with CPU only, which works (with Amontec’s JTAGkey), and Xilinx only, which works (with the Xilinx JTAG probe).

However, when I have it configured for both devices and use the JTAGkey, it never gets past the “value captured during scan didn’t pass the requested check” in jtag_read_buffer.

My configuration is:

#daemon configuration

telnet_port 4444

gdb_port 3333

#interface

interface ft2232

ft2232_device_desc “Amontec JTAGkey A”

ft2232_layout jtagkey

ft2232_vid_pid 0x0403 0xcff8

Increased from default of 2.

jtag_speed 5

#use combined on interfaces or targets that can’t set TRST/SRST separately

reset_config trst_and_srst srst_pulls_trst

jtag_nsrst_delay 250

jtag_ntrst_delay 50

#jtag scan chain

#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

jtag_device 4 0x1 0xf 0xe

jtag_device 6 0x05 0x3f 0x9

#target configuration

daemon_startup reset

#target

#target arm7tdmi

target arm7tdmi little run_and_init 0 arm7tdmi-s_r4

and the responses I get are:

Info: openocd.c:82 main(): Open On-Chip Debugger (2006-08-31 15:00 CEST)

Warning: arm7_9_common.c:679 arm7_9_assert_reset(): srst resets test logic, too

Warning: jtag.c:1037 jtag_read_buffer(): value captured during scan didn’t pass

the requested check: captured: 0f check_value: 01 check_mask: 0f

Warning: jtag.c:1037 jtag_read_buffer(): value captured during scan didn’t pass

the requested check: captured: 3f check_value: 05 check_mask: 3f

I only have a basic understanding of JTAG and I’m not sure what OpenOCD is checking, so I’d appreciate if anyone can cast any light on what the problem is.

Thanks in advance

  • Niels
2

The OpenOCD validates the JTAG scan chain by doing a dummy scan of the IR registers. The JTAG standard mandates that the two least significant bits of each device always return b01, the ARMs for example return b0001. It seems that the JTAGkey receives all 1s (0xf and 0x3f), which indicates a JTAG comms problem.

You could try a really high value for jtag_speed, like 10, 20 or even 50 (i’m using 21 on a board with a really bad jtag circuit), just to make sure that this isn’t the problem.

You should note that your IR capture mask for the Xilinx part is most likely wrong - the upper bits usually change depending on the devices state. Safe values are 0x1 and 0x3 (value should be bxxxx01), with only the lower two bits being checked.

If you have access to a scope you could check signal integrity. With two devices in the scan chain, the JTAGkey has to drive two loads on TMS and TCK. I’ve had problems with a naked FT2232 when trying to drive a Xilinx CPLD and FPGA at the same time, until I enabled high-drive mode - I don’t know how much current the JTAGkey’s output drivers can source.

Regards,

Dominic

3

Hi,

First, could you please try to invert the two jtag_device description :

#jtag scan chain

#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

jtag_device 6 0x05 0x3f 0x9

jtag_device 4 0x1 0xf 0xe

Let me know if this is better :roll:

It should work.

About Amontec JTAGkey Buffer:

By using the Amontec JTAGkey, you have very robust output buffers. In fact, all the output can drive up to 24mA, and the 24mA is guaranti from 5V to 1.4V IOs Voltage ! All the outputs have a guaranti < 5ns propagation delay.

(This is not the case for the other products based on FT2232, not able to drive 24mA or not in all the IO voltage range :cry:).

All inputs are done with ultra-fast analog comparator, propagation delay are <4.5ns with very High input impedance (no charge) !

(The other products use based on FT2232 use cheap digital buffer with Low input impedance :cry: )

But note that our new Amontec JTAGkey-Tiny will not have the same buffer specification ! It comes in a very Tiny price, but with only 2.8V to 5V IOs range and with only 8mA output buffers !

Regards,

Laurent

http://www.amontec.com

4

Hi,

No, that makes it worse. Presumably the lines have to be in the config in the same order that the devices are in the chain?

Anyway, my hardware guy recons there is an issue with ground bounce causing the TMS signal to falsely trigger the FPGA to go wrong, so we’re looking into that first.

However, I’ve found a bug in arm7tdmi.c which will definitely make multiple targets NOT work, as I’ve observed on my other platform which has three LPCs in the chain.

Line 872 in arm7tdmi.c (just checked out of SVN) is:

chain_pos = strtoul(args[2], NULL, 0);

whch should be

chain_pos = strtoul(args[3], NULL, 0);

I had a bit of trouble generating a diff, so I hope the above will do.

  • Niels
5

Hi,

yeah, the lines in the config have to be in the same order as the devices in the chain - the device closest to TDO has to be listed first in the config file.

Thanks for noticing the problem in arm7tdmi.c - of course this is definitely wrong. Guess noone actually used the OpenOCD in a configuration where the ARM target wasn’t the first (index 0) in the chain. I’ll fix that in the next SVN commit.

Regards,

Dominic

6

Thanks Dominic,

I’ve rebuilt my OpenOCD with this issue fixed, which has now given me visibility of another strange issue. You say that “…the device closest to TDO has to be listed first…”, but the question is which TDO? That of the JTAG probe or that of the processor?

I have a board with three LPC2103s on it, with the jtag chain passed through each one in turn. Only the third chip in the chain (the one whose TDO goes to the JTAG probe’s TDI) has LEDs attached to it, yet when I set the chain_pos argument to zero in the target command, that is the chip I am talking to. I can tell this because I can control the LEDs by writing to the GPIO registers.

So it looks like the 0th target is the one furthest away from the TDO pin of the JTAG probe.

If I set the chain_pos to 1, I seem to be talking to the “middle” chip in my chain. All well and good.

If I set chain_pos to 2, it seems to talk to the first chip in the chain, but it fails with an invalid instruction almost immediately.

So, the question in my mind is, how much has the multiple-target code actually been tested? And do you have any suggestions as to where to look next?

  • Niels
7

You said that “the one whose TDO goes to the JTAG probe’s TDI”, but that seems to be wrong. TDI/TDO are from the device’s point of view, and you connect your JTAG probe’s TDI to the TDI of the first device in the chain.

This is what the chain looks like (for me, and thus for the OpenOCD):

JTAG probe TDI → TDI Device2 TDO → TDI Device1 TDO → TDI Device0 TDO → JTAG probe TDO

Guess we have just different ways of labeling the JTAG probe’s signals.

The multiple-target code is hardly tested at all. I’ve rewritten most of the original code about a year ago, and back then I tried to pay attention to situations with multiple targets, but I’ve never actually tested it.

Regarding what to do next:

  • try multiple targets:

target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4

target arm7tdmi little run_and_halt 1 arm7tdmi-s_r4

target arm7tdmi little run_and_halt 2 arm7tdmi-s_r4

and talk to each one. ‘targets’ should display the list of configured targets and their state, and ‘targets ’ selects which target you’re talking to. You should be able to connect with GDB to gdb_port, gdb_port + 1 and gdb_port + 2, each one talking to a target of its own.

Regards,

Dominic