Well, we have already talked about that thing earlier in the discussion (have a look at my post of Mach 28th).
I agree that according to the documentation, you should have SJC_MOD high to go into “JTAG compliant mode”.
However, we have got a recommendation from Freescale that tells us to tie it to GND, and this is done in a way that I cannot change it easily on our design (and so it is on most of the designs I know).
If you look at the Figure 6.14 in the i.MX31 RM, the yellow path is the path that is selected by default in our design. Furthermore, if you look again at Figure 6.14, you see that with SJC_MOD high, you cannot (at least at boot) access the ARM11 JTAG TAP, which is what we want in the end ! So I think that SJC_MOD tied to GND is the correct setting for our needs (and that’s how I have used it with ARM RealView ICE).
I think the device that causes a problem for us is the one called Alter. TAP Bypass in our design (but I am not completely sure about it). I have to ask Freescale about the internals of that TAP.
from fig. 6-13, before the TAPs, there are a TAP selection controlled by TMS and TRST !!!
But the doc do not provide a lot info about TAPs and JTAG construction.
Then, the chain construction depends to the SJC_MOD and sdma_bypass.
Do you know how to config this to signals? On boot ?
http://www.amontec.com
No I don’t have more information about this unfortunately.
About the two signals, SJC_MOD is an external signal (that is usually tied to GND, according to Freescale recommendations and on all the devices I have seen) and about sdma_bypass, I have no further information but the one on Figure 6.14 and the fact that it is selected by default at boot with SJC_MOD tied to GND.
Now my understanding is that with SJC_MOD high, the only TAP on the chain is the SJC. This is certainly useful at Freescale for their internal tests and so on. Because in this mode, you can select one single other TAP as shown in Figure 6.13, but this would need some documentation about the TAP Selection Block. We could for example choose to only have the ARM ICE.
But this would need to heavily change openOCD as far as I understand, because it is thought for the common JTAG Daisy Chain architecture.
No, the OpenOCD is written as very generic layer. The only thing you need is to have a correct JTAG chain and to know his construction.
The construction of the JTAG chain must be given in the OpenOCD by its config .cfg file, as you know.
For many ARM7 and some ARM9, only one TAP is in the chain if you have only the processor in the chain. For some ARM9 there are 3 TAPs in the JTAG. In your case you have 4 TAPs in the chain, with one TAPs not JTAG compliant (I think).
Yes I know this, I have badly explained what I meant in my last sentence.
I know it would be easy to configure openOCD for only one TAP. But, in our i.MX31 case, with SJC_MOD to 1, this one TAP would be SJC at first, and not the ARM11 that we finally want. Now imagine that thanks to the TAP selection block, you can select the ARM11 core TAP to be on the chain (again, alone). I don’t think that openOCD is (yet ?) capable of this flexibility to change, while operating, the kind of TAP that is connected on the line (and that’s why it needs precise JTAG line configuration file at the beginning). But maybe am I not thinking correctly ?
But I agree with you, I think that one TAP is not JTAG compliant. I have just received the answer from Freescale, and their answer is we have no document to describe that SDMA bypass TAP …
I must say that I am very confused at the moment, I don’t know in which direction to go to make progress on this problem … 
Yes, you are right. The OpenOCD cannot accept that the JTAG chain construction chain after it was launched.
But in an other hand, I do not think your JTAG configuration will change!
For me, there are two issue:
-
your JTAG chain has something strange with the third TAPs.
-
there are a small bug in the JTAG detection in the OpenOCD.
For 1. we cannot help since we do not have your board;-(
(But the actual OpenOCD is not happy if an IDCODE is shorted in a TAP. We should add a new parameter in the config file as
jtag_device 4 0x0 0x0 0xe noidcode )
For 2. we can still help you.
Please try this new config :
#daemon configuration
telnet_port 4444
gdb_port 3333
gdb_memory_map enable
gdb_flash_program enable
#interface specific to Amontec JTAGkey ( http://www.amontec.com )
interface ft2232
ft2232_device_desc "Amontec JTAGkey"
ft2232_layout "jtagkey"
ft2232_vid_pid 0x0403 0xcff8
ft2232_latency 2
jtag_speed 10
#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst
#reset_config trst_only
#reset_config srst_only
#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
# 4 devices otherwise openocd complains, the last one returns 0x0 for all bytes
jtag_device 4 0x1 0x0 0xe
jtag_device 5 0x1 0x1f 0x1e
jtag_device 4 0x0 0x0 0xe
jtag_device 5 0x1 0x0 0x1e
jtag_nsrst_delay 500
jtag_ntrst_delay 500
#target configuratiorst_delay
daemon_startup reset
#target <type> <endianess> <reset mode>
target arm11 little reset_halt 1
run_and_halt_time 0 5000
And let me know !
This new config will only check
Note: it is really painfull for me to help since we cannot do any hardware tests. Maybe I could try to emulate this kind of JTAG chain in the FPGA of our Amontec UIPkey and debug openocd.
http://www.amontec.com
Hi Laurent
I have just done the check with the new configuration file, and I get nearly the same message as with the last one:
Info: jtag.c:1328 jtag_examine_chain(): JTAG device found: 0x2b900f0f (Manufacturer: 0x787, Part: 0xb900, Version: 0x2)
Info: jtag.c:1328 jtag_examine_chain(): JTAG device found: 0x07b3601d (Manufacturer: 0x00e, Part: 0x7b36, Version: 0x0)
Info: jtag.c:1328 jtag_examine_chain(): JTAG device found: 0x1190101d (Manufacturer: 0x00e, Part: 0x1901, Version: 0x1)
Error: jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x0c2011
Error: jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x0c2011
Error: jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x0c2011
Error: jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x0c2011
Error: jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x0c2011
Error: jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x0c2011
Error: jtag.c:1494 jtag_init(): Could not validate JTAG chain, exit
Does this give you additional information ?
The OpenOCD handles the device without an IDCODE just fine, there never was a problem in that regard. The OpenOCD just isn’t able to handle the non-conforming Capture-IR result from the third device. The JTAG standard says that the two least significant bits of the IR register are always loaded with a b01 upon Capture-IR, but apparently this isn’t true for the i.MX31. The OpenOCD relies on the b01 pattern to identify the number of devices and IR register length.
Maybe the validation code should be changed to use the IR-Capture and IR-Mask settings from the config file instead. I suppose it has to, in order to support broken designs like the i.MX31.
For now, you could change src/jtag/jtag.c to allow the OpenOCD to continue even if the chain validation fails:
Remove the lines 1391 and 1392:
free(ir_test);
return ERROR_JTAG_INIT_FAILED;
Best regards,
Dominic
Hi Dominic,
Thank you for your advice.
Yes you’re right. The OpenOCD should take care about the IR-Capture and IR-Mask when doing the validation JTAG chain.
Also, we should add a parameter telling if the IDcode is present or not for a specific TAP. If it is not present we must see a 1bits bypass register instead the 32bits IDcode register.
The IDcode is optional for a TAP in the JTAG norm.
http://www.amontec.com
instead adding a new parameter, we should work on the IDCODE register address in the config file :
jtag_device 4 0x0 0x0 0xe
jtag_device 4 0x0 0x0 0xf # there are no IDCODE since this register correspond to the bypass register.
Laurent
http://www.amontec.com
In jtag_examin_chain the “if ((idcode & 1) == 0)” does not move one forward on the device list.
I would assume to address the device via jtag_device you’d have to add
if (device)
{
/* device->idcode = idcode; */
device = device->next;
}
But I am not sure what side effect registering that phantom device has on other code.
Longfield, can you build OpenOCD locally, so that sending patches would make sense ?
Sure, I am always doing my tests with the svn tests and I am pretty used to Open-Source development and sending patches to mailing-lists, so I would love to contribute to it.
Thank you all for your guidance, I will try to do the tests with what you suggest tonight (if I have some time after football training).
A big up in the thread list for this one.
Due to very busy last three months (ok, only two months, the last one was busy with Euro 2008 in Switzerland 
), I am finally going back to this project.
Unfortunately, it looks like I even regressed while doing nothing about this work, I cannot seem to connect even to the jtag key probe with the tonight svn revision (737). Here is the log:
Debug: 11 1 command.c:438 command_run_line_internal_op(): telnet_port 4444
Debug: 13 1 command.c:438 command_run_line_internal_op(): telnet_port 4444
Debug: 15 1 command.c:438 command_run_line_internal_op(): gdb_port 3333
Debug: 17 1 command.c:438 command_run_line_internal_op(): gdb_port 3333
Debug: 19 1 command.c:438 command_run_line_internal_op(): gdb_memory_map enable
Debug: 21 1 command.c:438 command_run_line_internal_op(): gdb_memory_map enable
Debug: 23 1 command.c:438 command_run_line_internal_op(): gdb_flash_program enable
Debug: 25 1 command.c:438 command_run_line_internal_op(): gdb_flash_program enable
Debug: 27 1 command.c:438 command_run_line_internal_op(): interface ft2232
Debug: 29 1 command.c:438 command_run_line_internal_op(): interface ft2232
Debug: 31 1 command.c:438 command_run_line_internal_op(): ft2232_device_desc "Amontec JTAGkey"
Debug: 33 2 command.c:438 command_run_line_internal_op(): ft2232_device_desc "Amontec JTAGkey"
Debug: 35 2 command.c:438 command_run_line_internal_op(): ft2232_layout jtagkey
Debug: 37 2 command.c:438 command_run_line_internal_op(): ft2232_layout jtagkey
Debug: 39 2 command.c:438 command_run_line_internal_op(): ft2232_vid_pid 0x0403 0xcff8
Debug: 41 2 command.c:438 command_run_line_internal_op(): ft2232_vid_pid 0x0403 0xcff8
Debug: 43 2 command.c:438 command_run_line_internal_op(): jtag_nsrst_delay 500
Debug: 45 2 command.c:438 command_run_line_internal_op(): jtag_nsrst_delay 500
Debug: 47 2 command.c:438 command_run_line_internal_op(): jtag_ntrst_delay 500
Debug: 49 2 command.c:438 command_run_line_internal_op(): jtag_ntrst_delay 500
Debug: 51 2 command.c:438 command_run_line_internal_op(): jtag_speed 6
Debug: 53 2 command.c:438 command_run_line_internal_op(): jtag_speed 6
Debug: 54 2 jtag.c:1863 handle_jtag_speed_command(): handle jtag speed
Info: 55 2 options.c:50 configuration_output_handler(): jtag_speed: 6, 6
Debug: 57 2 command.c:438 command_run_line_internal_op(): reset_config trst_and_srst
Debug: 59 2 command.c:438 command_run_line_internal_op(): reset_config trst_and_srst
Debug: 61 2 command.c:438 command_run_line_internal_op(): jtag_device 4 0x1 0x0 0xe
Debug: 63 2 command.c:438 command_run_line_internal_op(): jtag_device 4 0x1 0x0 0xe
Debug: 65 2 command.c:438 command_run_line_internal_op(): jtag_device 5 0x1 0x1f 0x1e
Debug: 67 2 command.c:438 command_run_line_internal_op(): jtag_device 5 0x1 0x1f 0x1e
Debug: 69 2 command.c:438 command_run_line_internal_op(): jtag_device 4 0x0 0x0 0xe
Debug: 71 2 command.c:438 command_run_line_internal_op(): jtag_device 4 0x0 0x0 0xe
Debug: 73 2 command.c:438 command_run_line_internal_op(): jtag_device 5 0x1 0x0 0x1e
Debug: 75 2 command.c:438 command_run_line_internal_op(): jtag_device 5 0x1 0x0 0x1e
Debug: 77 2 command.c:438 command_run_line_internal_op(): daemon_startup reset
Debug: 79 2 command.c:438 command_run_line_internal_op(): daemon_startup reset
Info: 80 2 options.c:50 configuration_output_handler(): Open On-Chip Debugger 1.0 (2008-07-01-23:31) svn:737
Debug: 82 2 command.c:438 command_run_line_internal_op(): target arm11 little reset_halt 1
Debug: 84 2 command.c:438 command_run_line_internal_op(): target arm11 little reset_halt 1
Debug: 86 2 command.c:438 command_run_line_internal_op(): run_and_halt_time 0 0
Debug: 88 2 command.c:438 command_run_line_internal_op(): run_and_halt_time 0 0
Debug: 90 2 command.c:438 command_run_line_internal_op(): init
Debug: 92 2 command.c:438 command_run_line_internal_op(): init
Debug: 93 2 jtag.c:326 jtag_call_event_callbacks(): jtag event: JTAG controller reset (TLR or TRST)
Debug: 94 2 jtag.c:1295 jtag_reset_callback(): -
Debug: 95 2 jtag.c:1295 jtag_reset_callback(): -
Debug: 96 2 jtag.c:1295 jtag_reset_callback(): -
Debug: 97 2 jtag.c:1295 jtag_reset_callback(): -
Error: 98 3 jtag.c:1266 interface_jtag_execute_queue(): No JTAG interface configured yet. Issue 'init' command in startup scripts before communicating with targets.
Error: 99 3 arm11.c:1412 arm11_init_target(): 'target arm11' expects IDCODE 0x*7B*7****
Has something changed in the way we are supposed to write the configuration files ? The device is correctly listed and with correct read/write permissions for my user.
Bus 002 Device 005: ID 0403:cff8 Future Technology Devices International, Ltd
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0xcff8
bcdDevice 5.00
iManufacturer 1 Amontec
iProduct 2 Amontec JTAGkey
iSerial 3 32QVFTFA
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 55
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Anyone has an idea so that I can get back to code quickly ?
Has anybody successfully connected OpenOCD to an iMX31 using a jtagKey? Our results are exactly the same as Longfield’s.