xcore-200 JTAG

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
Post Reply
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am
Contact:

xcore-200 JTAG

Post by segher »

Hi!

I'm trying to get my JTAG tools (dis-xs1.git, a worse name
every day :-) ) to work with the explorerkit board.

Not much luck yet. I see only a single JTAG TAP, where
previous chips showed two (BS tap and chip TAP); the
(preliminary) documentation says there should be two per
processor.

The docs also say the IDCODE should be 0x6633, but I see
it as 0x5633.

Help? Any idea what is wrong? Are the docs accurate?


User avatar
XMatt
XCore Addict
Posts: 147
Joined: Tue Feb 23, 2010 6:55 pm

Post by XMatt »

Apologies, the JTAG section still requires updates as there have been some changes. As far as I know yours are the only other tools that require this information.

The changes that you will need are,

- The JTAG ID is 0x5633
- There is only one top level tap (rather than the 2 in XS1)
- The same instructions are supported in the top level tap.
- MUX values are as they were for XS1 (Like the G series there are multiple xCORE taps)
- The OTP can no longer be accessed via JTAG, this removes the OTP tap from the chain when
an xCORE tap is selected via the MUX.
segher wrote:Hi!

I'm trying to get my JTAG tools (dis-xs1.git, a worse name
every day :-) ) to work with the explorerkit board.

Not much luck yet. I see only a single JTAG TAP, where
previous chips showed two (BS tap and chip TAP); the
(preliminary) documentation says there should be two per
processor.

The docs also say the IDCODE should be 0x6633, but I see
it as 0x5633.

Help? Any idea what is wrong? Are the docs accurate?
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am
Contact:

Post by segher »

Hi Matt,
Apologies, the JTAG section still requires updates as there have been some changes. As far as I know yours are the only other tools that require this information.
I'm only vaguely aware of anyone else trying something similar, yes.
It would be nice if the basics were documented though (what TAPs
there are, their IDs, their lengths at bootup, that kind of thing)
-- this helps debugging new systems (there was a thread some months
ago where this happened).

I had some doubts I was on the right way at all, different ID then
what is documented, different # TAPs... Is this the same chip, did
it perhaps come up in some weird other config, etc. :-)
The changes that you will need are,
- The JTAG ID is 0x5633
- There is only one top level tap (rather than the 2 in XS1)
So where did the boundary scan go? Removed, put under the MUX?
- The same instructions are supported in the top level tap.
- MUX values are as they were for XS1 (Like the G series there are multiple xCORE taps)
- The OTP can no longer be accessed via JTAG, this removes the OTP tap from the chain when
an xCORE tap is selected via the MUX.
Okay, thanks :-)

So I only see an IR (loaded with 0101) and a single-bit bypass DR
(0) right at the start. That sounds right, doesn't it?

[Two minutes later...] Ooh, I got some output. Wrong output, but
output :-)

Thanks for the help!
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am
Contact:

Post by segher »

Happy happy joy joy!

It is all working now. Well, I haven't touched "run" and
"runxe" at all yet, but who wants to actually run code, right :-)

The changes needed were adjustments for the removed BS
and OTP taps, and different addresses for the RAM and ROM.
Nothing fancy.

But when reading from a switch register, I got the data from
the previous command, instead of the new data. This went
away after I added an extra dead cycle after every scan
(making it two total -- on at least G, possibly also L, it
needs one after changing the MUX). Took some debugging
to find that ;-)

Let's see how long I can stare at "regs" output before I get
bored and work on "run". Easter weekend, nice timing!
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am
Contact:

Post by segher »

Now both "run" and "runxe" are working, and the blinkies
blink :-)

One more question... The datasheet lists the "boot from
JTAG" bit (in the sswitch PLL reg) as "DW", does that mean
it can be written from JTAG? I didn't get that to work.
What is the recommended procedure to set this bit, to have
the system boot in a clean state? Currently it boots into
a harmless state, flash checksum is bad (not programmed
at all I suppose), but it won't stay that way forever... Booting
in a random state is, let's say "interesting"... Reminds me
of XC-1 :-)
User avatar
XMatt
XCore Addict
Posts: 147
Joined: Tue Feb 23, 2010 6:55 pm

Post by XMatt »

So the 2 TAP's have now been combined into 1 at the top level in the device, this makes things quite a bit simpler.

There is a new instruction in the top level TAP for booting from JTAG and setting the PLL.

SET_TEST_MODE 0x8 - Load chip test mode register with DR

· The chip test mode control register will control the PLL and the JTAG boot mode:

· bit 31: RESET_N, when writing a ‘1’ to this register, the processor will not be reset. Otherwise, a write to this regsiter will cause a processor reset.
· bit 30: LOCK_N, when writing a ‘1’ to this register, the processor will not wait for a lock.
· bit 29: BOOT_FROM_JTAG, when writing a ‘1’ to this register this causes the bootrom to boot from JTAG.
· bit 28: BYPASS, when writing a ‘1’ to this register, the PLL will be bypassed altogether

· Bit 25..23: OD value of the PLL.
· Bit 20..8: F value of the PLL.
· Bit 6..0: R value of the PLL.

The JTAG test mode register can be written directly from the top level tap
(without any part of the chip operational - only TCK must be provided); it cannot
be read over the top level tap. If the chip is operational, this register can be read
and and written through SSwitchCTL register 6 (PLL settings).

The BOOT_FROM_JTAG bit is also visible through PS register 3 (boot status).
The register is reset when TRST_N is asserted. The initial values are zero for all
bits except for OD, F, and R that be initialised depending on MODE0 and MODE1.
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am
Contact:

Post by segher »

Hi again, and thanks again for the info!

I haven't made it work yet -- got too distracted by poking
around things now, all those top DRs and the analogue --
but I'm not sure about some inconsistencies. I can probably
figure things out, but I'll note things here anyway :-)
XMatt wrote:So the 2 TAP's have now been combined into 1 at the top level in the device, this makes things quite a bit simpler.
Which two do you mean? There are so many :-)
Do you mean the BS TAP? I don't see any DR with enough
bits for that?
There is a new instruction in the top level TAP for booting from JTAG and setting the PLL.

SET_TEST_MODE 0x8 - Load chip test mode register with DR
Ah!
· The chip test mode control register will control the PLL and the JTAG boot mode:

· bit 31: RESET_N, when writing a ‘1’ to this register, the processor will not be reset. Otherwise, a write to this regsiter will cause a processor reset.
· bit 30: LOCK_N, when writing a ‘1’ to this register, the processor will not wait for a lock.
· bit 29: BOOT_FROM_JTAG, when writing a ‘1’ to this register this causes the bootrom to boot from JTAG.
· bit 28: BYPASS, when writing a ‘1’ to this register, the PLL will be bypassed altogether
The datasheet shows 28, 29 swapped (in sswitch reg 06);
which one is right? Both? :-)
The BOOT_FROM_JTAG bit is also visible through PS register 3 (boot status).
The register is reset when TRST_N is asserted.
TRST_N, really?
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am
Contact:

Post by segher »

I have JTAG boot working now, thanks for the help!

Some observations:
-- Bits 28..31 seem to not be readable from sswitch reg 06,
they always show up as 0;
-- The "boot from JTAG" bit can be read from PS reg 03,
but also from sswitch reg 00, which is more convenient;
-- The bit indeed is bit 29. I also could write bit 30, but
writing bits 28 or 31 did not update the register at all.
Some timing issue I suppose ;-)
Post Reply