# LPC2138 and Xilinx in jtag chain - can't get it to work **URL:** \ **Category:** MicroMod\ **Tags:** arm-lpc\ **Created:** [September 28, 2006, 8:02am UTC](https://community.sparkfun.com/t/lpc2138-and-xilinx-in-jtag-chain-cant-get-it-to-work/2810 "2006-09-28T08:02:10Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![nielst](https://avatars.discourse-cdn.com/v4/letter/n/85e7bf/32.png) [@nielst](https://community.sparkfun.com/u/nielst)\ **Post date:** [September 28, 2006, 8:02am UTC](https://community.sparkfun.com/t/lpc2138-and-xilinx-in-jtag-chain-cant-get-it-to-work/2810/1 "2006-09-28T08:02:10Z")
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 ---
**Author:** ![Dominic](https://avatars.discourse-cdn.com/v4/letter/d/13edae/32.png) [@Dominic](https://community.sparkfun.com/u/Dominic)\ **Post date:** [September 28, 2006, 8:25am UTC](https://community.sparkfun.com/t/lpc2138-and-xilinx-in-jtag-chain-cant-get-it-to-work/2810/2 "2006-09-28T08:25:14Z")
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 ---
**Author:** ![AMONTEC](https://avatars.discourse-cdn.com/v4/letter/a/898d66/32.png) [@AMONTEC](https://community.sparkfun.com/u/AMONTEC)\ **Post date:** [September 28, 2006, 10:41am UTC](https://community.sparkfun.com/t/lpc2138-and-xilinx-in-jtag-chain-cant-get-it-to-work/2810/3 "2006-09-28T10:41:33Z")
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 😢). 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 😢 ) 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](http://www.amontec.com) ---
**Author:** ![nielst](https://avatars.discourse-cdn.com/v4/letter/n/85e7bf/32.png) [@nielst](https://community.sparkfun.com/u/nielst)\ **Post date:** [October 3, 2006, 6:09pm UTC](https://community.sparkfun.com/t/lpc2138-and-xilinx-in-jtag-chain-cant-get-it-to-work/2810/4 "2006-10-03T18:09:54Z")
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 ---
**Author:** ![Dominic](https://avatars.discourse-cdn.com/v4/letter/d/13edae/32.png) [@Dominic](https://community.sparkfun.com/u/Dominic)\ **Post date:** [October 3, 2006, 7:56pm UTC](https://community.sparkfun.com/t/lpc2138-and-xilinx-in-jtag-chain-cant-get-it-to-work/2810/5 "2006-10-03T19:56:06Z")
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 ---
**Author:** ![nielst](https://avatars.discourse-cdn.com/v4/letter/n/85e7bf/32.png) [@nielst](https://community.sparkfun.com/u/nielst)\ **Post date:** [October 11, 2006, 5:31am UTC](https://community.sparkfun.com/t/lpc2138-and-xilinx-in-jtag-chain-cant-get-it-to-work/2810/6 "2006-10-11T05:31:52Z")
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 ---
**Author:** ![Dominic](https://avatars.discourse-cdn.com/v4/letter/d/13edae/32.png) [@Dominic](https://community.sparkfun.com/u/Dominic)\ **Post date:** [October 11, 2006, 5:58am UTC](https://community.sparkfun.com/t/lpc2138-and-xilinx-in-jtag-chain-cant-get-it-to-work/2810/7 "2006-10-11T05:58:56Z")
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