ARM11 MPCORE

AMONTEC · March 28, 2008, 12:27pm

Hi,

An other way to detect the JTAG chain and detect the max JTAG frequency is to use the AMONTEC SVF Player project from the AMontec TJAGkey homepage.

Just download the project, and call the amtsvfplayer.exe without any argument and without any SVF file.

The amtsvfplayer.exe will auto-detect the JTAG Chain and will report you the different TAP ID of each TAP found in the Chain.

after what you could compare the TAP IDs you get from the Amontec SVF Player and the ones you are giving in your OpenOCD Configuration file .cfg .

Laurent

http://www.amontec.com

Longfield · March 28, 2008, 2:36pm

Thank you Laurent

I have tried your tool, and here are the results:

JTAG chain analyzing:
---------------------
JTAG TRST_N signal can stay open.
JTAG chain safe max frequency: 6000000 Hz
JTAG chain safe number of TAPs: 3
JTAG chain construction:

  ICE (JTAGkey) PORT[0] -> TDI
                            +
                           TDI
                           TAP[2] / IDCODE: 0X2320203A
                           TDO
                            +
                            +
                           TDI
                           TAP[1] / IDCODE: 0X07B3601D
                           TDO
                            +
                            +
                           TDI
                           TAP[0] / IDCODE: 0X2B900F0F
                           TDO
                            +
  ICE (JTAGkey) PORT[0] <- TDO

JTAG chain is safe and stable!

3 devices ? This sounds strange because the i.MX31 documentation talks about 4 devices, and openOCD complains when I give only 3 devices. What’s also strange is that the first devices have the same IDs for both openOCD and amtsvfplayer, they see a different third device. By the way. how do you decode these IDs, is there a meaning in them ?

edit: I may have an explanation: There are actually 4 devices in the internal i.MX31 JTAG Daisy Chain (the mode selected at boot from our design). These devices are:

ETMBUF
ARM1136JF-S
SDMA (DMA internal microcontroler)
SJC (System JTAG Controller)

However, by default at boot, I cite you Freescale’s doc: “Although the SDMA TAP “pretends” to be in the chain, it is actually bypassed by the alternate TAP to allow faster a TCK frequency for debug.”

Now the question is can this be handled by openOCD ? Maybe now this is a question for the development mailing-list …

AMONTEC · March 28, 2008, 4:55pm

where do you get the info of the 4 TAPS ?

I checked ID and Description

Type

Vendor ID

Format

Size K

Rev #

Date Last Modified

Download Code Files

MCIMX31RM

MCIMX31 and MCIMX31L Multimedia Applications Processors Reference Manual Reference Manuals FREESCALE pdf 13999 2.3 1/5/2007 -

But ofund nothing.

Let me know.

Regards,

Laurent

http://www.amontec.com

Longfield · March 28, 2008, 5:03pm

Well, I have a document under non-disclosure agreement from Freescale where they describe how to use the ARM RealView ICE for the i.MX31, and they cite these 4 devices.

In the ARM RM, you can read section 6.4. Especially there is the Figure 6-13 where you see all the 4 devices (SJC, SDMA, and ARM platform with two devices (ETM and ICE)).

The table 6-13 and Figure 6-15 (they omit the ETM in this buffer) show the configuration we have (in our design, sjc_mod = 0) and the remark about the SDMA being bypassed.

AMONTEC · March 28, 2008, 6:12pm

As you wrote:

<<However, by default at boot, I cite you Freescale’s doc: "Although the SDMA TAP “pretends” to be in the chain, it is actually bypassed by the alternate TAP to allow faster a TCK frequency for debug.>>

The question is to know what mean ‘bypassed’:

In JTAG language ‘bypassed’ corresponds to 1bit shift register
In common language ‘bypassed’ means wired (no register)

Do you know if 1. or 2. ?

laurent

http://www.amontec.com

Longfield · March 31, 2008, 8:55pm

Well, my guess would be that it is a 1 bit shift register to be JTAG compliant, but I cannot find a confirmation about it …

Dominic · April 1, 2008, 6:47am

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)

TAP[2] / IDCODE: 0X2320203A

TAP[1] / IDCODE: 0X07B3601D

TAP[0] / IDCODE: 0X2B900F0F

The IDCODE for TAP[2] reported by Amontec’s tool violates the JTAG standard. The LSB must be ‘1’, but an “A” reads b1010, i.e. the LSB is ‘0’.

The OpenOCD detected the configured number of four devices just fine, otherwise it would have complained:

LOG_ERROR(“number of discovered devices in JTAG chain (%i) doesn’t match configuration (%i)”, device_count, jtag_num_devices);

I suppose either your IR length settings in the OpenOCD .cfg are wrong, or one of the devices in the chain doesn’t behave JTAG conform.

Best regards,

Dominic

AMONTEC · April 1, 2008, 8:30am

Hi Dominic,

Yes, your 're right.

For TAP[2], device receiving first TDI,

OPENOCD detects 0x2b900f0f

Amontec SVF Player detects 0X2320203A

Question for longfield:

Do you have an on-board JUMPER to select any Debug / Boundary scan path or do you only select the path on BOOT ?

AMONTEC · April 1, 2008, 7:39pm

I think this ARM11 has something very different about JTAG chain construction.

Alos, I think one of the 4 TAPs has NO IDCODE. In the case where the IDCODE is absent from a TAP, the IDCODE is replaced by one bit register, as a bypass.

For me both OpenOCD and Amontec SVF Player do not act correctly when a TAP have his IDCODE absent.

We have now to test more about the JTAG chain construction.

FOR LONGFIELD:

1.Could you please use our Amontec JTAG DEMO software and run a long IR scan (64 bits length) with all bits to ‘1’. Please let us know the 64bits TDO resulting.

Then go to RESET State.
Then please do a DR scan (256 bits length) with all bits to ‘0’ and let me know the result of the TDO vector.

With this two TDO results, I will be able to give you the exact construction of your JTAG chain.

Laurent

http://www.amontec.com

Longfield · April 2, 2008, 6:30pm

Thank you for your answers Laurent and Dominic !

Do you have an on-board JUMPER to select any Debug / Boundary scan path or do you only select the path on BOOT ?

The Debug / Boundary scan path is only selected on BOOT in our design, and this cannot be changed for us. We choose the path where all the devices are present in the chain.

FOR LONGFIELD:

1.Could you please use our Amontec JTAG DEMO software and run a long IR scan (64 bits length) with all bits to ‘1’. Please let us know the 64bits TDO resulting.

Then go to RESET State.

Then please do a DR scan (256 bits length) with all bits to ‘0’ and let me know the result of the TDO vector.

Here are the results:

TDO: 0x FF FF FF FF FF FC 20 11
(I cannot read all the values on your display, small bug in your program), but here is what I have done using several sizes reads:

TDO: 23 (or 32) 20 20 3A 07 (or 70) B3 60 1D 2B (or B2) 90 0F 0F (for the 96 lsbits, all the rest is 0).

The or values are because when they are the first read bytes (with respectively 32, 64 and 96-bit reads), the letters are shift for the first byte ! (maybe also a bug in your software).

I have done the manips a few times and I get the same every time. Thanks now if you can analyze this.

AMONTEC · April 2, 2008, 7:44pm

OK Longfield,

Again we get the strange 0X2320203A IDCODE for the last device like the Amontec SVF detected! But as Dominic told, this is not JTAG compiliant. (LSB of IDCODE must be 1).

Two solutions:

a bug in the AMR11
We have a bypass register just before the last device and we could get : 0X1190101D

Anyway, the result you give me can suggest you to connect openocd with the following .cfg, and let me know :

#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 0xf 0xe

jtag_device 9 0x1 0x1ff 0x1fe

jtag_device 5 0x1 0x1f 0x1e

jtag_nsrst_delay 500

jtag_ntrst_delay 500

#target configuratiorst_delay

daemon_startup reset

#target

target arm11 little reset_halt 1

run_and_halt_time 0 5000

Laurent

Amontec

http://www.amontec.com

AMONTEC · April 2, 2008, 7:45pm

OK Longfield,

Again we get the strange 0X2320203A IDCODE for the last device like the Amontec SVF detected! But as Dominic told, this is not JTAG compiliant. (LSB of IDCODE must be 1).

Two solutions:

a bug in the AMR11
We have a bypass register just before the last device and we could get : 0X1190101D

Anyway, the result you give me can suggest you to connect openocd with the following .cfg, and let me know :

#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 0xf 0xe

jtag_device 9 0x1 0x1ff 0x1fe

jtag_device 5 0x1 0x1f 0x1e

jtag_nsrst_delay 500

jtag_ntrst_delay 500

#target configuratiorst_delay

daemon_startup reset

#target

target arm11 little reset_halt 1

run_and_halt_time 0 5000

Laurent

Amontec

http://www.amontec.com

AMONTEC · April 2, 2008, 8:33pm

Longfield,

Please note that the previous .cfg does not in includes 4 TAPs as it should. But try anyway, just to see how the actual OpenOCD react.

In an other way, please take again the Amontec JTAG Demo Software and do:

SCAN IR 32bits all at ‘1’ with endstate to IDLE
SCAN DR 32bits all at ‘1’ with endstate to IDLE
Give the result of TDO after 2.

Laurent

http://www.amontec.com

Longfield · April 4, 2008, 12:27pm

Hi Laurent,

Here are the results of the tests with openOCD with the configuration you have given me:

Error:   arm11.c:1371 arm11_target_command(): 'target arm11' expects 'jtag_device 5 0x01 0x1F 0x1E'

And second try with a correct target arm11 config:

Open On-Chip Debugger 1.0 (2008-03-27-22:30) svn:525
URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
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:1338 jtag_examine_chain(): number of discovered devices in JTAG chain (4) doesn't match configuration (3)
Error:   jtag.c:1339 jtag_examine_chain(): check the config file and ensure proper JTAG communication (connections, speed, ...)
Error:   jtag.c:1486 jtag_init(): trying to validate configured JTAG chain anyway...
Error:   arm11_dbgtap.c:131 arm11_in_handler_SCAN_N(): 'arm11 target' JTAG communication error SCREG SCAN OUT 0x00 (expected 0x10)

Well, it looks like ARM11 definitely is expecting a 5-register (first attempt). With the second attends, I just changed the config so that the arm11 device is no 2 (which corresponds to jtag_device 5 0x01 0x1F 0x1E) to go beyond that first check … but the device 2 definitely is not an ARM11 as the error states it.

I definitely think that the two first devices are configured in openOCD with:

jtag_device 4 0x1 0xF 0xE

jtag_device 5 0x1 0x1F 0x1E

The question remains open for the two (or maybe one ?) remaining devices.

Now for the tests with the Amontec JTAG Demo Software:

SCAN IR 32bits all at ‘1’ with endstate to IDLE

SCAN DR 32bits all at ‘1’ with endstate to IDLE

Give the result of TDO after 2.

TDO: FF FC 20 11
TDO: FB(BF?) FF FF F0

Thanks again for your help !

AMONTEC · April 4, 2008, 4:27pm

Good !

I can confirm, you have 4 TAPS in your JTAG chain. But only 3 IDCODE!

Also, the TAP with shortage IDCODE should have a bypass register when in DRSHIFT JTAG state. Also, the TAP with shortage IDCODE is not JTAG compiliant when in IRSHIFT JTAG state.

Now please try to connect OpenOCD with:

#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 0xf 0xe

jtag_device 5 0x1 0x1f 0x1e

jtag_device 4 0x0 0xf 0xe

jtag_device 5 0x1 0x1f 0x1e

jtag_nsrst_delay 500

jtag_ntrst_delay 500

#target configuratiorst_delay

daemon_startup reset

#target

target arm11 little reset_halt 1

run_and_halt_time 0 5000

This should be better.

Let me know.

Best regards,

Laurent

http://www.amontec.com

Longfield · April 7, 2008, 7:50pm

Yes it SHOULD be better … unfortunately it does not work, and it’s exactly the configuration I had started with at the beginning, and the results are the same:

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 0x042011
Error:   jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x042011
Error:   jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x042011
Error:   jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x042011
Error:   jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x042011
Error:   jtag.c:1383 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x042011
Error:   jtag.c:1494 jtag_init(): Could not validate JTAG chain, exit

Now I have the feeling we have pretty much done all the logical configurations and come back to the status we were at the beginning. Either there is a problem in the openOCD code that I need to debug or (this second hypothesis is what I think is correct) there is something not correct in the i.MX31 JTAG chain that must be supported with some openOCD code changes.

Laurent, do you have other ideas ? Or anyone else ? Dominic ? I am going to ask someone at Freescale about it, to maybe confirm my hypothesis and get some guidance … I still have to look the errata sheet too.

AMONTEC · April 7, 2008, 8:29pm

Did you try my last .cfg, because it is different from your first one:

your one with jtag_device 4 0x1 0xf 0xe

My last one with jtag_device 4 0x0 0xf 0xe

please confirm you have try with jtag_device 4 0x0 0xf 0xe

regards,

Laurent
http://www.amontec.com

Longfield · April 8, 2008, 6:03am

Yes I confirm it is the last one, with the 0 for IR Capture on the third device.

I have also tried with IR Capture on 0 for the fourth device, but I get also the same problem:

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

Except that the scan returned is 0x0xc2011, that we had already seen earlier … I must say that I am a little lost at this point, I don’t know JTAG very well, and I don’t feel comfortable to extract pattern from these results.

AMONTEC · April 8, 2008, 12:29pm

#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 0xf 0xe     # IR capture 0001
jtag_device 5 0x1 0x1f 0x1e   # IR capture 00001
jtag_device 4 0x1 0xf 0xe     # IR capture 0001
jtag_device 5 0x1 0x1f 0x1e   # IR capture 00001

with this config the IR capture should be on 18bits : 000010001000010001
via Amontec JTAG Demo IR captured :                   000010000000010001
via OpenOCD                                           000010000000010001

This is why I suggested to you to try with the config
jtag_device 4 0x1 0xf 0xe     # IR capture 0001
jtag_device 5 0x1 0x1f 0x1e   # IR capture 00001
jtag_device 4 0x0 0xf 0xe     # IR capture 0000
jtag_device 5 0x1 0x1f 0x1e   # IR capture 00001

with this config the IR capture should be on 18bits : 000010000000010001
then openocd receive IR :                             000010000000010001

Also, these two vectors match !!!

But OpenOCD say NO

Yes, this is a bug in OpenOCD.

In an other hand, your JTAG chain is not JTAG Compliant since the third device do not have start with IR capture as 01, but 00.

The next step will be to have more info from vendor of your processor. I am sure there can give you more info on the JTAG chain construction of your very special device!

Have fun,

Laurent

http://www.amontec.com

Laurent

mbruck2 · April 9, 2008, 12:32am

I checked the Freescale spec:

Doc list:

http://www.freescale.com/webapp/sps/sit … tation_Tab

Datasheet:

http://www.freescale.com/files/32bit/do … umentation

in 6.4.6/6.4.7 (PDF p. 368) it explains that there is a pin “sjc_mod” that must be set to high on TRST to go into JTAG compliant mode.

Do you have access to that pin?

Michael

Topic		Replies	Views
JTAG chain MicroMod arm-lpc	9	3858	May 6, 2008
'Error validating JTAG scan chain, IR mismatch' problem MicroMod arm-lpc	24	16083	September 5, 2006
how to make OPENOCD support new cpu? MicroMod arm-lpc	0	963	September 8, 2010
olimex-arm-usb-tiny-h with new hardware MicroMod arm-lpc	9	2948	January 11, 2013
Failure with Olimex USB and Phytec LPC3180 MicroMod arm-lpc	12	3536	September 12, 2007

ARM11 MPCORE

4 devices otherwise openocd complains, the last one returns 0x0 for all bytes

4 devices otherwise openocd complains, the last one returns 0x0 for all bytes

4 devices otherwise openocd complains, the last one returns 0x0 for all bytes

Related topics