JTAG Chain Configuration for Zynq UltraScale+ MPSoC

[pmg67]

Chapter 39 of the UG1085 (v1.5) TRM for the Zynq UltraScale+ MPSoC describes a sequence for adding the ARM_DAP to the scan chain.

It mentions the JTAG_CTRL instruction.

Where are the TAP instructions for the Zynq UltraScale+ MPSoC TAP documented?

Apologies if this is obvious. I've had a good look through the Technical Reference Manual and on this forum and can't seem to find that information.

[austin]

ug1085

Table 39-7, page 1099?

[pmg67]

Thanks.

Yes I did see that table which lists some TAP instructions.

However it does not give any details about the instructions, such as what are the IR Opcodes, what are the DR length etc.

It also does not list the JTAG_CTRL instruction that is mentioned on Page 1098.

I was looking for something with more detail about these TAP instructions.

[austin]

Got it,

When I get to ARM specific details (their IP), I go to their documents:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.genc008687b/index.html

That has the details (I checked just now).

[pmg67]

The document that you linked to is "CoreSight™ Access Tool (CSAT) User Guide".

It describes the commands and usage of the CoreSight Access Tool. Is that where you saw the details?

I don't think it contains the information that I need about the TAP instructions (such as the JTAG_CTRL instruction).

I appreciate your help.

[austin]

Agree,

The details appear to be buried in piles of documents.  That tells me that folks use the ARM Debug software tools.

https://arm-software.github.io/CMSIS_5/DAP/html/index.html

[austin]

ug1208, page 80?

[pmg67]

I don't think so - those commands for the command line tool would be much higher level than what I'm after.

If you look at UG1085 Table 39-1 it actually shows a little more information. It shows that the JTAG IDCODE command instruction length for the Zynq UltraScale+ MPSoC is 12 bits. It also shows the expected 32-bit IDCODE values for the different parts. What it doesn't show is the actual IDCODE instruction (could be anything from 0x0 to 0xFFF for a 12-bit instruction).

It also shows that the instruction length for the ARM DAP is 4 bits. However, in order to get the ARM DAP into the scan chain you need to issue an instruction to the Zynq UltraScale+ MPSoC - I believe that instruction is the JTAG_CTRL instruction that I've mentioned before.

I can see snippets of information but not the complete picture.

[timran]

@pmg67

Were you able to figure out how to add ARM DAP to the JTAG chain by issuing commands to Zynq UltraScale+ MPSoC TAP ?

Thanks,
Talha

[pmg67]

@timran

No, unfortunately I've been unable to get any more information about the TAP commands for the Zynq UltraScale+ MPSoC TAP.

I've been trying a different approach and attempting to access the ARM DAP via the PJTAG interface. The DAP can be accessed directly in any non-secure boot mode via the PJTAG interface. When I do this I can indeed see two devices in the scan chain - one of these devices has a 4-bit IR length which leads me to believe that it is the ARM DAP. However, it appears to be constantly in BYPASS mode. So far I have been unsuccessful in trying to get an IDCODE from it.

[timran]

I am working on UltraZed board which has a Zynq UltraScale+ MPSoC onboard and the SoC's JTAG pins are exposed directly without adding any other component in the jtag chain.

On running the boundary scan, I am able to see two devices: the first device has the IDCode 0x04710093 (corresponding to Zynq UltraScale+ MPSoC TAP) and the second device has no IDCode (but an IR length = 4).

I am using JTAG (hence non-secure) boot mode. According to ug1085, JTAG access to the DAP is automatically allowed in this mode from security perspective. However, ug1085 elaborates that DAP must be added to the JTAG chain before it can be used. Considering ug1085 Figure 39-1, I am guessing the second device is the "Dummy DAP" because ARM DAP has not been added to the chain yet. Any CoreSight related configuratin should become relevant only after the second (or third?) device reports its IDCode as 0x5ba00477 (for ARM DAP).

However, ug1085 also mentions that "With non-secure boots, the CSU ROM automatically links the Zynq UltraScale+ MPSoC TAP and DAP to the JTAG." If this is the case, shouldn't the second device show the IDCode for ARM DAP ?

My question (same as the one asked at the start of this thread) is how to add ARM DAP to the JTAG chain via the MPSoC TAP? Is my understanding regarding requirements for accessing ARM DAP (and hence debug the PS), correct ?

[pmg67]

Following on from the previous post from timran -

I see this in the BSDL file for the device:

"The Zynq UltraScale+ MPSoC contains two TAPs in series: the MPSoC TAP and the ARM DAP. See the

System Test and Debug chapter in UG1085. The device BSDL file represents the MPSoC TAP and the device

boundary register. The ARM DAP (zynqultrascale_arm_dap.bsd) must be inserted after the MPSoC in the

JTAG scan chain to correctly model the JTAG chain. In a secure application that has disabled the ARM DAP

and uses the dummy DAP instead, append the file zynqultrascale_dummy_dap.bsd instead."

This suggests to me that the 'real' ARM DAP should be visible when a non-secure boot mode is selected.

There are 3 non-secure boot modes that are selectable using the boot mode switch on the SOM.

I have tried all 3 of these non-secure boot modes and it would appear to me that I am always seeing the dummy DAP instead

of the 'real' ARM DAP.

Why is the 'real' ARM DAP not in the chain in non-secure boot mode?

[pratham]

@pmg67 Sorry for the delay in getting back. I am looking into this Issue and hope to get back to you with a solution.

Thanks for your understanding.

[pratham]

@pmg67 Can you please run the attached script in the xsdb console and post the results?

[pmg67]

@pratham I really appreciate your help with this.

I've tried running your script from the xsct console in the SDK (I couldn't see the xsdb console in my SDK install).

I've attached a screenshot of what I'm seeing  in the console.

(I have the ethernet on the carrier board connected to my network - is this the only connection that I need?)

[losborn]

I have been following the posting. I think PMG67 is my colleague as he shared the script which enable the DAP. I'm trying to get our debugger to attach and it needs the DAP enable to attach. My question is about the register write in the script using the XSCT console. Is that write a JTAG write to that address (register)? Is the XSCT using the JTAG to communicate to the MPSoC SOM?

The documentation on the mwr states that this is a memory write to the target memory but the register data in UM1087 states that the DAP is disabled until a write jtag_sec is written to enable the DAP. So how is this accomplished without the DAP?

[losborn]

Reading about Debug Security in UG1085 it implies that non-secure boots, the CSU ROM enables the PL and the DAP. Is the JTAG boot mode considered a non-secure boot mode? If so, the Ultrazed CSU ROM doesn't appear to be treating it as such. Can I get some guidance?

[timran]

@prathamPlease find attached the xsct console output after executing the provided script.

[timran]

If it is of any relevance, I have a working JTAG debug setup with MPSoC ZCU102 Starter Kit Rev D1 using a third party JTAG probe. I am trying to achieve the same results with UltraZed board.

In JTAG boot mode, both ZCU102 and UltraZed boards behave the same using Xilinx Vivado IDE and USB JTAG port. I am able to connect to and debug baremetal applications after appropriate initializations. The outputs of running the provided script on both the targets is attached.

When trying to debug (with both the targets in JTAG boot mode), using a third party JTAG probe, ZCU102 presents ARM DAP in the JTAG chain and allows connections to it, followed by proper debugging of A53 and R5 cores. For UltraZed board, however, I only get the JTAG chain as described in my previous responses on this thread.

Comparing the schematics, the JTAG connections are practically the same between the two boards. For both boards in JTAG boot mode, the PS_POR_B LED blinks on reset and PS_DONE LED stays OFF.

My guess is that Xilinx Vivado IDE performs some initializations upon connection to make the ARM DAP accessible via JTAG before moving on with the debug launch. Is this the case ? How can I access ARM DAP via JTAG using any JTAG probe ?

[rik.visser]

Hi guys,

Try to run a hw_server with the following command:

hw_server  -L hw_server_log.txt -l "jtag,slave"

Run 

hw_server --help

for more info on the command line options

This will give you a text file containing TDI and TDO values from the target, see the small snippet:

 11:28:09.045: control event 0 received, shutdown initiated
TCF 11:28:26.723: control event 0 received, shutdown initiated
TCF 11:28:41.095: Server-Properties: {"Name":"Name=Xilinx Hardware Server","OSName":"Windows 7","UserName":"VisserR","AgentID":"57750269-27ea-4683-8b23-5c9e77f5156f","TransportName":"TCP","Port":"3121","ServiceManagerID":"57750269-27ea-4683-8b23-5c9e77f5156f-0"}
TCF 11:28:52.801: control event 0 received, shutdown initiated
TCF 11:29:19.436: Server-Properties: {"Name":"Name=Xilinx Hardware Server","OSName":"Windows 7","UserName":"VisserR","AgentID":"5775028f-ca84-4d0e-8f54-4c5d17c32887","TransportName":"TCP","Port":"3121","ServiceManagerID":"5775028f-ca84-4d0e-8f54-4c5d17c32887-0"}
TCF 11:29:45.663: jtagpoll: open port Xilinx/00001631d0f501
TCF 11:29:45.664: JTAG: clear command sequence
TCF 11:29:45.664: JTAG-MDM: shift IR, 6 bits, end state IDLE
TCF 11:29:45.664: JTAG-MDM:  tdi (IR): all ones
TCF 11:29:45.664: JTAG-MDM: shift IR, 6 bits, end state IDLE
TCF 11:29:45.664: JTAG-MDM:  tdi (IR): 000011
TCF 11:29:45.664: JTAG-MDM: shift DR, 32 bits, end state IDLE
TCF 11:29:45.664: JTAG-MDM:  tdi (...): all zeros
TCF 11:29:45.664: JTAG: run command sequence
TCF 11:29:45.664: JTAG-MDM:  tdo (config): 01000010000000000000001000000110
TCF 11:29:45.665: JTAG: clear command sequence

This helped me to debug an issue with multiple microblazes in a kintex 7 with different USER chains. Maybe it can be of help for your issue.

Best regards,

Rik

[rik.visser]

Forgot to mention that this is more a reverse engineer method. Connect via this hw_server in Vivado / SDK with the MPSoC and look for the instructions/data the tools send to the zynq.

[losborn]

@pratham I need some help understanding the lack of DAP access when booting in JTAG mode. The script you provide only works on the Console of the Xilinx SDK and that is not my tool of choice. Please respond.

[pratham]

Hi All, 

We did a Webex with @pmg67 last night and resolved this issue. 

@losborn @rik.visser @timran Have you had a chance to take a look at UG1085 #1098?

@pmg67 Could you please close this thread with final comments about steps you had taken to resolve this issue would help others too.

[pmg67 · Accepted solution]

The solution to the problem is on Page 1098 of UG1085 in the section titled "JTAG Chain Configuration".

The missing ingredient in that section is a description of the JTAG_CTRL instruction.

The JTAG_CTRL instruction has a 12-bit IR Length and the opcode is 0x824.

The DR bits for JTAG_CTRL are described in the table attached.

Set bits 0 and 1 to get the ARM_TAP and PL_TAP enabled.

Thanks @pratham for helping me to resolve this.

Also thanks to @rik.visser for your suggestion. It didn't help me to resolve this directly but that's a very useful tip and I've used it to look at some other functionality in the SDK.

[pratham]

@pmg67 Thanks, Just to give an update we will add this missing information in the TRM.

[losborn]

@pratham  I just got the data last night. I'll be checking the information and setting up my system. As soon as I validate the solution I'll get back to you.

Regards,

Larry

[timran]

The JTAG_CTRL instruction opcode = 0x824 was exactly what was required.

After issuing IR=0x824 followed by DR=0x2, I can access ARM DAP on the JTAG chain.

Thanks,
Talha

[losborn]

@pratham We have verified the connection to the DAP. And now have another problem where the A-53 cores are in sleep mode. Which is a major roadblock. Any reason why the A-53 cores would be in some power-down mode?

Also, We have had problem with the ROM and accessing parts of the Cortex infrastructure. Is there any errata on the ROM?  The R5 seem to be inaccessible.

[sinanakman]

@losborn Were you able to resolve with cores being in power-down more. As soon as we connect via external debugger we see the same issue.

Thanks

Sinan

[losborn]

Yes, Sorry for not closing the loop. We got them powered up and out of reset.