'Error validating JTAG scan chain, IR mismatch' problem

Development Boards MicroMod
1

Hi,

Can anyone help with a ‘simple’ OpenOCD out of the box problem … I’ve got Philips LPC2129- Amontec JTAGKey - OpenOCD v78, but when I run

OpenOCD I get

‘Error: jtag.c:1096 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch’

Info & the debug output is below.

Thanks

Rich

Setup - I’ve got the Amontec USB JTAGKey connected to a Keil MCB2100 board with the Philips LPC2129 processor. I’ve followed MiFi’s OpenOCD installation notes, with the example LPC project, but when I run the OpenOCD exe I get the debug output below.

The JTAGKey works fine with the Amontec demo software.

I found an ‘IR Mismatch’ topic before, where the solution was to fit a pull down resistor on RTCK - but the eval board already has this.

Debug output :-

C:\Projects\example>openocd-ftd2xx -f.\prj\lpc2xxx_jtagkey.cfg -d

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

Debug: jtag.c:1150 jtag_init():

Debug: ftd2xx.c:887 ftd2xx_init(): current latency timer: 2

Debug: ftd2xx.c:977 jtagkey_init(): 80 08 1b

Debug: ftd2xx.c:1034 jtagkey_init(): 82 09 0f

Debug: ftd2xx.c:143 ftd2xx_speed(): 86 02 00

Debug: jtag.c:234 jtag_call_event_callbacks(): jtag event: 1

Debug: jtag.c:1044 jtag_reset_callback():

Debug: jtag.c:234 jtag_call_event_callbacks(): jtag event: 1

Debug: jtag.c:1044 jtag_reset_callback():

Error: jtag.c:1096 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch

2

Hello Rich,

are you able to read the JTAG device ID using Amontec’s demo application?

To read the JTAG ID, do the following:

  • make sure your board is powered, and the JTAGKey is connected

  • launch Amontec’s demo

  • open your JTAGkey in the USB to JTAG devices box

  • under JTAG port options, select 2 MHz or less (doesn’t matter how slow it is), deselect the internal loopback enable and press initialize

  • in the data register scan box, deselect check tdo, and press DR Scan

post the value that appeared in the TDO field.

Is there already an application running on your board? Does the Keil board have a jumper to force entry into bootloader mode?

Regards,

Dominic

3

Hello Dominic,

Many thanks for your v.quick reply.

There is a demo application which runs on the board.

The value read back was F4 1F 0F 0F. Interestingly, the memo window states the JTAG frequency as 6MHZ even when I reset it lower & press the ‘Initialize’ button !

Anyway, whilst ‘investigating’ this problem I have now discovered a workaround. I have discovered that the OpenOCD will connect if I ‘cycle power’ to the JTAGKey (removing & replacing the USB connector).

From a coldstart (PC power on etc) the system reports the ‘IR Mismatch’ error, but I will try and identify the path(s) into/out of this error state.

Thanks again

Rich

4

Hi Rich,

As Dominc told you, you may use the Amontec JTAGkey Demo Software for testing your JTAG chain.

BUT, your read back value “F4 1F OF OF” was the result of a Data Register Scan and not an Instruction Register Scan.

In normal case and if you have a one ARM device on your JTAG chain, you should receive from a Intruction Register Scan the value hex “xx xx xx x1”

This value hex"x1" in bin"xxxx0001" is the value the OpenOCD check when validating the JTAG chain.

Have a look to the .cfg file you use for starting the OpenOCD. You will see something like :

#jtag scan chain

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

jtag_device 4 0x1 0xf 0xe

The 0x1 is the value you can re-check with the JTAGkey Demo Software.

Could you please re-do this check with the JTAGkey Demo Software in the both case: PC power … and JTAGkey cycle power

If in both cases you catch the hex"x1" value with the Deom Software, this will means we have something wrong in jtag_init function of the OpenOCD !

(Maybe the TAP is not in his TLR state before calling the jtag_validate_chain function).

NOTE: Make sure to close the JTAGkey from the Demo Software before restarting your OpenOCD JTAG server.

BUT this stay a strange issue!

Regards,

Laurent

5

Hey Rich,

if possible, it would help if you could compile the OpenOCD yourself from the sources, after enabling additional debug output in src/jtag/jtag.h. There’s a #define for DEBUG_JTAG_IO which can be enabled to display the actual data written and captured over JTAG. Let me know if you need further instructions for compiling the OpenOCD.

Further increasing the value of jtag_speed (higher value means lower speed) might also help. To be sure, you could try a value of 20, making sure that there’s no problem with the connection.

The value captured in the DR scan is fine, it’s what I get on my LPC2294 board using the JTAGkey, too.

Regards,

Dominic

6

Hi Rich,

I’ve been experimenting with a home made JtagKey and found a similar problem to yours, however with a different solution!

From power-up I get an IR mismatch.

If I run the Amontec JtagKey Demo, select the device and open it, unselect ‘Internal Loopback Enable’ then click initialize.

I can then run OpenOCD and it works.

If I then go back into the JtagKey Demo and set loopback then re-run OpenOCD, I get the IR mismatch error again.

It would appear that OpenOCD does not change/initialise the loopback mode!

I haven’t looked further into the ftd2xx initialisation yet. It would be good to know if this can be reproduced on your setup, or if I’m just doing something wrong?

The other option is that this is something peculiar to my setup - with a home-made JtagKey and setup with MProg myself :wink:

Regards,

Ian.

… Edit …

I’ve also remembered that a week ago I was testing the JtagKey on a different board (arm7 at91R40008) and it worked fine, but the board I’m currently using has an arm926 and has the problem described above.

Maybe not so clear-cut.

However, using this current setup it ALWAYS fails at power-up, and ALWAYS works after clearing the loopback ???

7

Hi Ian,

Thanks for the advice.

This means our JTAGkey Demo Software works all times! This is a software initialisation trouble in the OpenOCD.

I will compare our JTAGkey Demo Software Init function with the OpenOCD one.

Regards,

Laurent

PS: Does your board have a pull-up or a pull-down on TCK ?

8

Hi Laurent,

I’m back online, and so could run your test this morning … and it worked fine (but I had followed Ian’s workaround to run the test, since I had cleared the loopback mode and changed the freq to 2MHz). I did the IR test and got the 0x01 back AND OpenOCD connected ok.

I tried some resets (cycling power to the eval board and the JtagKey) to see if all was stable, but then I did manage to get the IR mismatch error again when running OpenOCD. Ater this, when I connected with the demo software the IR test returned 0x00.

I power cycled the eval board, and JTAGKey again … ran the demo software and cleared the open loop init as suggested by Ian, and it appeared to clear the error - now the IR test returned 0x01 again, and OpenOCD connected ok !

Cheers

Rich

9

Hello Rich,

thanks for doing these tests. I’ve added a command to explicitly disable loopback to the initialization routine. The new version is available as revision 80 in the SVN. Let me know if you need help getting it compiled.

Regards,

Dominic

10

Hi -All-,

I’ve tried r80 on the same setup as previous and found the following:

After plugging in the USB to the JtagKey and powering the uut, I get an ‘IR mismatch’ error. If I run OpenOCD again there is no error.

I can then run OpenOCD multiple times without any problem.

I can remove and re-apply power to the uut and OpenOCD works.

If I unplug the USB connection, re-insert, power-up uut, and run OpenOCD, I get the ‘IR mismatch’ error. Again if I re-run OpenOCD it is OK?

This is without running the Amontec demo software at all.

It would appear that something is not initialised at the point where the IR mismatch is checked, but gets set correctly the second time round.

Would a before and after logfile with DEBUG_JTAG_IO defined help out?

Although it’ll probably be Friday pm before I get time to do it!

Regards,

Ian.

11

Hello Ian,

would be great if you could provide me with these logs. Just send them to Dominic.Rath gmx.de once you get a chace to generate them.

Regards,

Dominic

12

Hi Dominic,

Just to say thanks - I installed the re80 build from MiFi, and since then I have not seen the IR mismatch error.

I’ve repeated the sequence of events Ian describes cause him a problem, but have been unable to generate an error.

All works well on the Kiel eval board - my own dev board reports SIGTRAP problems, but that’s another story.

Thanks

Rich

13

I use openocd-2006re80 version on windows,I use Wiggler to connect my develop board s3c4510(arm7tdmi)

the config file i use:

#daemon configuration

telnet_port 4444

gdb_port 3333

#interface

interface parport

parport_port 0x378

parport_cable wiggler

jtag_speed 0

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

reset_config trst_and_srst

#jtag scan chain

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

jtag_device 4 0x1 0xf 0xe

#target configuration

daemon_startup reset

#target

#target arm7tdmi

target arm7tdmi big reset_halt 0 arm7tdmi-s_r4

#run_and_halt_time 0 30

The debug info:

D:\Program Files\openocd-2006re80\bin>openocd-pp -d -f 7.cfg

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

Debug: jtag.c:1180 jtag_init():

Debug: parport.c:358 parport_init(): requesting privileges for parallel port 0x378…

Debug: parport.c:368 parport_init(): …privileges granted

Debug: parport.c:203 parport_reset(): trst: 0, srst: 0

Debug: jtag.c:240 jtag_call_event_callbacks(): jtag event: 1

Debug: jtag.c:1070 jtag_reset_callback():

Debug: jtag.c:240 jtag_call_event_callbacks(): jtag event: 1

Debug: jtag.c:1070 jtag_reset_callback():

Error: jtag.c:1131 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch

But,I use similar cfg file,and use wiggler can connect my another board at91rm9200,and openOcd works fine!

I doubt 4510’s jtag is not properly inited,but i don’t know how to shot the trouble.

Any guide to give me, Thanks in advance.

14

Dominic,

I captured some logs on Friday, but I was getting different results to the last time. I’ve repeated them again and have the same as Friday.

I’ll explain the problem I’m seeing.

On power-up of the PC, I get the IR mismatch error.

In the log files I get :-

Debug: jtag.c:957 jtag_build_buffer(): fields[0].out_value: 3f

Debug: ftd2xx.c:773 ftd2xx_execute_queue(): IR scan, 6 bit, end in 0

Debug: jtag.c:988 jtag_read_buffer(): fields[0].in_value: 29

If I run OpenOCD multiple times I still get this value and the IR mismatch error.

If I now run the Amontec demo, disable loopback, it then works with the entry in the log file :-

Debug: jtag.c:988 jtag_read_buffer(): fields[0].in_value: 31

If I unplug the USB connection and try again, it fails with :-

Debug: jtag.c:988 jtag_read_buffer(): fields[0].in_value: 3f

If I now run the Amontec demo again, but with loopback ENABLED, OpenOCD works with the log entry :-

Debug: jtag.c:988 jtag_read_buffer(): fields[0].in_value: 31

I reported in an earlier post that running OpenOCD a second time cleared the error, I can no longer reproduce this behaviour, I have to run the Amontec Demo to get OpenOCD working.

It would appear that the Amontec demo is doing some initialisation that gets the setup working, but the loopback seems to be a red-herring.

Although the change you made seems to have got Rich’s setup working?

It could be that the Amontec demo is just flushing out the scan chain and getting it back to a state where OpenOCD then works.

Regards,

Ian.

15

Dominic,

My previous tests have been on version r80. I’ve just spotted r82 and quickly repeated some of the tests.

I tried r82 without the debug, and get my initial results - fails first time, second time works - without using the Amontec demo program.

I then compiled with the jtag debug enabled, works every time (so far).

I’ll have to repeat the test more thoroughly to be sure!

Have you made any significant changes to the ftd2xx from version r80 to r82. I noticed that the debug output in the logs is different, I now get :-

Info: ftd2xx.c:286 ftd2xx_send_and_recv(): inter: 0.0, inter2: 0.0 end: 0.0

Regards,

Ian.

16

Hi!

I have a problem. I am trying use the Openocd with LPC2138 (ARM7TDMI-S) and Wiggler cable in Debian GNU/Linux 2.6.16 but don’t run. When I run the comand openocd -f configfile.cfg -d this error happen: Error: jtag.c:1123 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 3f.

That’s all right with my cable Wiggler. I already used it with OpenWince Jtag and Spartan3 Kit. My Wiggler cable is that: http://wiki.openwrt.org/OpenWrtDocs/Cus … JTAG_Cable .

My ARM’s board haven’t any pull-up neither pull-down resistor. This is necessary? I used Openocd with MCB2130 (Keil board with LPC2138) and Wiggler cable and happened the same error even so this board has pull-up resistors in TRST, TDI, TMS and TDO signals and pull-down in TCK and RTCK signals. The RTCK signal there isn’t in my Wiggler cable. As the standard jtag 1149.1 the TDI, TDO, TCK and TMS signals are essential to comunication, but TRST and RTCK aren’t.

The configuration in my config-file is the same used in: http://www.siwawi.arubi.uni-kl.de/avr_p … index.html

I need only to program the flash memory…

17

Hey,

the openwrt Wiki page has two different JTAG interfaces - which one do you use? If you’re using the “Unbuffered Cable, Xilinx DLC5 Cable III”, you should use “parport_layout dlc5” and “reset_config none”.

If instead you’re using the “Buffered Cable, Wiggler”, you should use “parport_layout wiggler” and “reset_config trst_and_srst srst_pulls_trst”.

If the OpenOCD still doesn’t work, you might have to add your own layout definiton to parport.c. You have to define the bitfields used for TMS, TCK, TDI and TDO, as well as the bitfields and polarity of nTRST and nSRST (if implemented).

Pull-up/down’s shouldn’t be necessary.

Regards,

Dominic

18

Hi Dominic,

In your parport.c file, the mask for TDO is 0x80 (LPT D7 pin). My Wiggler cable (buffered) uses TDO in Busy pin. It will be that the problem is this? Or I understood wrong?

Thank you, Alexandre.

19

The OpenOCD expects the parallel port to be in uni-directional mode, that is it only writes signal using the data pins, and reads signals using the status pins. TDO is usually connected to the ‘busy’ pin, which affects the msb of the status port (0x80).

Regards,

Dominic

20

Ok Dominic! Therefore, apparently that’s all right with my parellel port and wiggler cable. I will go to reread the manual one more time so that discovery something wrong in my config.cfg file. Perhaps I am “eating fly”. We say thus here in Brazil! If I won’t have positive result, I am going to post my config.cfg file here to you see.

I hope not to be disturbing you. I really need to do this to run. My project is stopped more than one week…

Thank you one more time, Alexandre.