Couple questions on JTAG and XTAG2

[bearcat]

Taking a final look at my design and have been looking at the JTAG interface in more detail. Looking to minimize the design and parts for this.

1 - Looking to move the debug pullup resistor to a programming interface board. I assume if the JTAG is not used, this pullup is not needed. The XTAG2 itself has this line floating. If the programming board is not connected this will be floating with little trace length, when connected has the pull up. Anybody see any problems with this?

2 - TRST and RST timing. Current best practice shows these to use the same timings. I am assuming the MODE lines are read by the bootup firmware (no hardware latch or something), therefore MODE does not need to be valid exactly at RST release? How much time is there before they are read (ballpark)? 10nS, 100nS, mS's?

3 - TRST and XTAG2. Similiar to above. The TRST line is used to change the boot mode for when the XTAG2 is connected. I am assuming this means that the XTAG2 leaves the TRST line low for some time after RST is released to enable the boot mode from JTAG. How long is this approximately (or recommended)? I will most likely look at this with a scope in any case to verify.

Any comments?

Edit: mode lines.

[segher]

1 - Looking to move the debug pullup resistor to a programming interface board. I assume if the JTAG is not used, this pullup is not needed. The XTAG2 itself has this line floating. If the programming board is not connected this will be floating with little trace length, when connected has the pull up. Anybody see any problems with this?

I assume you mean the DEBUG pin? Floating is fine as far as I can see: a) you need to
explicitly enable it (in software) before it does anything; b) I believe it has a weak pull-up
(or pull-down), like all other similar signals; and c) it is floating (at boot time) on the XC-1A :-)

2 - TRST and RST timing. Current best practice shows these to use the same timings. I am assuming the MODE lines are read by the bootup firmware (no hardware latch or something), therefore MODE does not need to be valid exactly at RST release? How much time is there before they are read (ballpark)? 10nS, 100nS, mS's?

TRST is completely asynchronous to all other signals.
I believe MODE is latched by hardware at reset time; it is made available to the boot firmware
in processor state reg 3. You should have the MODE pins set before you let RESET go.

3 - TRST and XTAG2. Similiar to above. The TRST line is used to change the boot mode for when the XTAG2 is connected. I am assuming this means that the XTAG2 leaves the TRST line low for some time after RST is released to enable the boot mode from JTAG. How long is this approximately (or recommended)? I will most likely look at this with a scope in any case to verify.

Assuming it is the same as on XC-1A and XTAG1, this is actually handled on the board, with
a FET pulling a MODE pin low when TRST is active.

In my JTAG tools (https://www.xcore.com/projects/xs1-disa ... jtag-tools)
I hold TRST for 1ms after releasing RESET. There is some extra delay from the USB stack of course,
on the order of a few ms at most.


Segher

[bearcat]

Thanks for the reply.

If MODE is hardware latched, then the need to hold MODE after RST would be minimal. I will take your 1mS as a reasonable number and implement using that assumption.

Hardware latching would indicate to me, though, that the TRST must be held after RST is released for a few nS at least. I suspect the XTAG2 probably does this, but that's not how the hardware is implemented in some designs from the power monitor chips. The TRST (and MODE pins) and RST get released exactly at the same time.

In my case I have a microcontroller releasing TRST and RST, so I can program what I want and do not need to worry about the above concern. I will put a scope on the XTAG2 to verify what it does in case I missed something.

Edit: typo

[segher]

Hardware latching would indicate to me, though, that the TRST must be held after RST is released for a few nS at least.

TRST is used only by the TAP controller (JTAG), not by anything else in the chip. Many boards
wire things up so that TRST pulls a MODE pin as well. But if you're asking about what the chip
does at reset, talking about TRST makes little sense; you should ask about MODE instead.

That said, I think the only thing that matters here is the value at the MODE pins when RESET
is released, not any time after (or before) that. But I'm not sure, you should check it.

I suspect the XTAG2 probably does this, but that's not how the hardware is implemented in some designs from the power monitor chips. The TRST (and MODE pins) and RST get released exactly at the same time.

That sounds iffy. I recommend you look at the datasheet, see what it says about these pins.

In my case I have a microcontroller releasing TRST and RST, so I can program what I want and do not need to worry about the above concern.

That's easy then :-)


Segher

[bearcat]

As a followup, here are the timings from the XTAG2. Top trace is RST, lower is TRST.

RST low for 400uS. TRST low for 40uS prior to RST. TRST hold 400uS after RST release.

[segher]

Here is some more info on processor status reg 3, from an XC-1A (G4 chip).
When it is normally started, that is boot from SPI rom, it shows:

Code: Select all

xs1:~/xs1 segher$ ./reset
xs1:~/xs1 segher$ for i in 0 1 2 3 ; do ./psregs -j$i | grep ^03 ; done
03: 000000fe 00000000 00000000 00000000 00000000 00000000 00000000 00000000
03: 000100fe 00000000 00000000 00000000 00000000 00000000 00000000 00000000
03: 000200fe 00000000 00000000 00000000 00000000 00000000 00000000 00000000
03: 000300fe 00000000 00000000 00000000 00000000 00000000 00000000 00000000

(register 3 is the first column).

Bits 16..23 are the core #. Bit 8 is the "secure boot from OTP", disabled here. Bits 0..7 are
the boot MODE; only 0..1 are used by the boot firmware (in ROM on the chip).
So, boot mode is 2 here, which means "boot from SPI"; for cores other than #0, the boot
firmware forces mode to 1 if it was 2, which is "boot from link".
0 is boot from RAM, 3 is boot from JTAG (that is, just hang; whatever you run via JTAG
will take care of it, by first going to debug mode and all that).

Now when starting a program via JTAG mode. MODE pin 0 isn't pulled low during reset,
but let flow high:

Code: Select all

xs1:~/xs1 segher$ ./run < forth.b
xs1:~/xs1 segher$      [...wait a few seconds...]
xs1:~/xs1 segher$ for i in 0 1 2 3 ; do ./psregs -j$i | grep ^03 ; done
03: 000000ff 00000000 00000000 00000000 00000000 00000000 00000000 00000000
03: 000100ff 00000000 00000000 00000000 00000000 00000000 00000000 00000000
03: 000200ff 00000000 00000000 00000000 00000000 00000000 00000000 00000000
03: 000300ff 00000000 00000000 00000000 00000000 00000000 00000000 00000000

So, the boot mode is 3, which is not what is on the pins anymore, but is what was there
at RESET time.

This doesn't show exactly when the hardware samples the pins; but from your XTAG2
measurement we know it has to be <400us.