X
RSS YouTube LinkedIn Twitter XCore IRC

Search




Post new topic Reply to topic   [ 30 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Wed Apr 11, 2012 10:54 pm 
User avatar
Experienced Member
Joined: Wed Apr 11, 2012 6:21 am
Posts: 64
Greetings!
I hope this request is in the right place.

I need to Bit-Bang my own JTAG/XTAG device for programming an XS1-L2 device.
Where should I look for documentation on this interface? Any info is helpful, The more info the better.

I'll hold off on unnecessary details unless asked for more info.

Thanks,
LyleHaze


Top
Offline Profile View all posts by this user  
 
PostPosted: Thu Apr 12, 2012 12:44 am 
User avatar
XCore Expert
Joined: Sun Jul 11, 2010 1:31 am
Posts: 675
https://www.xcore.com/projects/xs1-disa ... jtag-tools
will probably help you. If you have any specific questions, do ask!


Top
Offline Profile View all posts by this user  
 
PostPosted: Thu Apr 12, 2012 11:06 am 
User avatar
XMOS Employee
Joined: Tue Feb 23, 2010 6:55 pm
Posts: 125
Also all of the code we run on the XTAG-2 for talking to all XMOS devices via JTAG is here https://github.com/xcore/sc_jtag this may help you out.


Top
Offline Profile View all posts by this user  
 
PostPosted: Thu Apr 12, 2012 3:41 pm 
User avatar
Experienced Member
Joined: Wed Apr 11, 2012 6:21 am
Posts: 64
Thank you both.
I've been digging through documents, trying to find all the details I will need.
Both of your references will be a great help.
I have experience with other embedded processors, but this is my first project with XMOS stuff.
Seeing an active user community supported by the manufacturer is a very promising start. :)

Quote:
If you have any specific questions, do ask!


Thank You, Segher. I'm sure there will be many

From my own end of the project, I can reach all the JTAG pins from my code now.
I have an XMOS chip on the motherboard, apparently just waiting for code to be delivered.
Apparently it is: In Reset, In Debug, XTag not connected, and the JTAG pins can be read
and (most) written as well.

Lots more reading to do. Thanks for the leads!

LyleHaze


Top
Offline Profile View all posts by this user  
 
PostPosted: Sat Apr 21, 2012 11:19 pm 
User avatar
Experienced Member
Joined: Wed Apr 11, 2012 6:21 am
Posts: 64
Some progress, much more to go.

(Lot's of assumptions. I may have ANYTHING wrong here, let me know if I am mistaken)
I have reviewed the code you both provided. It appears that one is the (xc) code for the JTAG programmer, and the other is for the computer (USB Host) that drives it. Fortunately for me, those are the two halves that I will need to navigate.

After also reading up a bit on how JTAG works, I wrote some code to read and write the JTAG connections in my computer. These are already connected to the on-board XMOS chip, so I should see something from the XS1-L2 that I am connected to.

Starting simple, I tried setting the JTAG chain to all "BYPASS" and then counting the devices on the chain. I get a 3 or 4 returned, depending on when I sample the DO pin. Not quite what I expected, but at least I got something! I'm guessing that the "multiple devices" are probably the MUX, possibly the switch and XCORE(s).. ?? I don't yet know.

The next step was to read Device IDs. No matter what I try, I get all zeros back. Possibly I need to set the MUX up first. Any suggestions?

Another "noob" question: I see there is OTP on this chip. Am I in danger of accidentally writing to OTP and ruining my XS1-L2? In other words, is it REALLY OTP, or is there a way to recover the chip by wiping the entire chip to blank? Needless to say I'm a bit nervous about ruining my toy before I've even had a chance to play with it.

I have tried reading the XC code for clues, but I'm not quite sure yet about some of the "new" I/O commands. The "sync()" command waits for the described pin to.. ? Finish it's current output sequence??

When setting a single output pin to an 8, 16, or 32 bit value.. It clocks out the data, LSB first, from what clock source?

Right now I'm confused, but I'm also beginning to see great potential in this "novel" architecture.
Any suggestions, comments, or outright corrections are welcomed!

Thank You,
Lyle Hazelwood


Top
Offline Profile View all posts by this user  
 
PostPosted: Sun Apr 22, 2012 6:09 am 
User avatar
XCore Expert
Joined: Sun Jul 11, 2010 1:31 am
Posts: 675
LyleHaze wrote:
I have reviewed the code you both provided. It appears that one is the (xc) code for the JTAG programmer, and the other is for the computer (USB Host) that drives it.

The code XMatt pointed you to is the code that is usually used on the XTAG2. My
code is for use with the XTAG ("XTAG1"), or any other FT2232-based device; it can
also be easily modified to work with anything else that drives JTAG (since that is
abstracted out).

Quote:
Starting simple, I tried setting the JTAG chain to all "BYPASS" and then counting the devices on the chain.

How do you do that? It is hard to tell what (if anything) you are doing wrong, if
you don't tell us what you do :-)

Quote:
I get a 3 or 4 returned, depending on when I sample the DO pin.

There are four JTAG devices on the chain (after reset), on an L2; two for each chip.

Quote:
Not quite what I expected, but at least I got something! I'm guessing that the "multiple devices" are probably the MUX, possibly the switch and XCORE(s).. ?? I don't yet know.

The MUX and the boundary scan controller. The MUX is last on the chain, i.e.
closest to TDO.

Quote:
The next step was to read Device IDs. No matter what I try, I get all zeros back. Possibly I need to set the MUX up first. Any suggestions?

You do not need to set up anything. You should reset the TAP (toggle TRST).
The MUX boots up in bypass mode; the BS boots up in device id mode.

Does your xcore run code? Often when your clock or reset stuff doesn't work
correctly, you get all zeroes on TDO.

Quote:
Another "noob" question: I see there is OTP on this chip. Am I in danger of accidentally writing to OTP and ruining my XS1-L2? In other words, is it REALLY OTP, or is there a way to recover the chip by wiping the entire chip to blank? Needless to say I'm a bit nervous about ruining my toy before I've even had a chance to play with it.

It is really OTP. You _can_ write to it over JTAG, but unless you do it on purpose
it just isn't going to happen :-)

Quote:
I have tried reading the XC code for clues, but I'm not quite sure yet about some of the "new" I/O commands. The "sync()" command waits for the described pin to.. ? Finish it's current output sequence??

If the port is serialised output, then yes. It does not run the next code until the
last output data has been on the pins for at least one tick.

Quote:
When setting a single output pin to an 8, 16, or 32 bit value.. It clocks out the data, LSB first, from what clock source?

From whatever clock source you configured! Usually the REFCLK divided by something.

HTH,


Segher


Top
Offline Profile View all posts by this user  
 
PostPosted: Sun Apr 22, 2012 7:12 am 
User avatar
Experienced Member
Joined: Wed Apr 11, 2012 6:21 am
Posts: 64
segher wrote:
My code is for use with the XTAG ("XTAG1"), or any other FT2232-based device; it can
also be easily modified to work with anything else that drives JTAG (since that is
abstracted out).

Interesting. I'll have to look deeper into that. Does the FT2232 have any logic, or it just passing bits straight through? That may be the shortest path to my goal.

segher wrote:
How do you do that? It is hard to tell what (if anything) you are doing wrong, if
you don't tell us what you do :-)

Fair enough. ;) I found an interesting website that promised to make JTAG easy! (Uh Oh)
I followed their code along and duplicated it with my own ports and pins assigned. The site is http://www.fpga4fun.com/JTAG1.html. I basically followed what I found there. Not completely useless, as I did get a device count, but the method they describe for getting ChipID's does not work for me today.

segher wrote:
There are four JTAG devices on the chain (after reset), on an L2; two for each chip.

Great! Now I can put the data capture from TDO in the correct part of the clock cycle and proceed from there.

segher wrote:
The MUX and the boundary scan controller. The MUX is last on the chain, i.e.
closest to TDO.
More great information. I understand exactly where to look.

segher wrote:
You do not need to set up anything. You should reset the TAP (toggle TRST).
The MUX boots up in bypass mode; the BS boots up in device id mode.

That explains it. I have not played with either of the resets yet, but give me about ten more minutes after I finish this post... :)

segher wrote:
Does your xcore run code? Often when your clock or reset stuff doesn't work
correctly, you get all zeroes on TDO.

Thanks, I'll watch for that. So far the chip is blank, as far as I know. The only one that has been programmed was done through an XTag port provided for that purpose, but it's multiplexed with six pins of a PGA, which I have been asked to write drivers for. The first goal is for me to be able to load programs to the onboard XMOS chip or any additional chips added into the XTAG chain (brought out to a card slot). Once I can load and verify code, probably add boundary scans, then we will look into whether or not some part of the toolchain might be ported over.


segher wrote:
It is really OTP. You _can_ write to it over JTAG, but unless you do it on purpose
it just isn't going to happen :-)

You need to have more faith in my abilities! :) If it can be screwed up, I'll find a way!

Again, I thank you for your time and help. More to study, more code to write.

LyleHaze


Top
Offline Profile View all posts by this user  
 
PostPosted: Sun Apr 22, 2012 5:52 pm 
User avatar
XCore Expert
Joined: Sun Jul 11, 2010 1:31 am
Posts: 675
LyleHaze wrote:
segher wrote:
My code is for use with the XTAG ("XTAG1"), or any other FT2232-based device; it can
also be easily modified to work with anything else that drives JTAG (since that is
abstracted out).

Interesting. I'll have to look deeper into that. Does the FT2232 have any logic, or it just passing bits straight through? That may be the shortest path to my goal.

It is a USB-to-bunch-of-pins converter: UART, SPI, JTAG, I2C, junk bus. It has
_some_ logic, mostly to do with timing; it handles the commands you send it.
It being USB, you send the commands in packets; you also have to read reply
packets, for those commands that return data (those that sample TDO). The
return buffers are fairly small, and you often need to see the result of some
JTAG transaction before you start the next; USB's structure limits you to 1kHz
to do that. The 2232 also has a maximum output frequency of 6MHz (when
using its JTAG output), and it is full-speed USB only (12Mbps). So, in total,
using a 2232 to drive JTAG has some gross inefficiencies, but it isn't _so_ bad,
and it works, and it is used all over the place :-)

Quote:
segher wrote:
How do you do that? It is hard to tell what (if anything) you are doing wrong, if
you don't tell us what you do :-)

Fair enough. ;) I found an interesting website that promised to make JTAG easy! (Uh Oh)
I followed their code along and duplicated it with my own ports and pins assigned. The site is http://www.fpga4fun.com/JTAG1.html. I basically followed what I found there. Not completely useless, as I did get a device count, but the method they describe for getting ChipID's does not work for me today.

Maybe because it is incorrect :-)

Not all JTAG devices reset to IDCODE: some reset to BYPASS (with modern devices,
that is mostly when there are multiple JTAG devices in a single package). You can
see the difference because the (1-bit) BYPASS reg is initialised to 0, and the (32-bit)
IDCODE reg is initialised to have a 1 in the lowest bit.

Your example code does not handle BYPASS regs, but the xcore uses it.

Quote:
Great! Now I can put the data capture from TDO in the correct part of the clock cycle and proceed from there.

TDI, TDO, TCK are all driven on the falling edge of TCK, and sampled on the rising
edge of TCK.

Quote:
That explains it. I have not played with either of the resets yet, but give me about ten more minutes after I finish this post... :)

You can used the "five ones" method to do test-logic-reset, instead of TRST; _but_
you need to handle the TRST and RST signals properly at startup. If you do not,
the xcore's JTAG will not work.

Quote:
segher wrote:
Does your xcore run code? Often when your clock or reset stuff doesn't work
correctly, you get all zeroes on TDO.

Thanks, I'll watch for that. So far the chip is blank, as far as I know. The only one that has been programmed was done through an XTag port provided for that purpose, but it's multiplexed with six pins of a PGA, which I have been asked to write drivers for.

Okay, so you have an XSYS port, and using it you "see" the xcore? Excellent,
working stuff is always good :-)

You say your JTAG bus is multiplexed between the XSYS and the PGA. If I were
you, I would check (with a logic analyser or scope) if all the signals are handled
correctly (you can at least see if all signals are as they should be; you cannot
see the difference between open drain and push/pull with an LA, but just assume
it is okay, heh).

Quote:
The first goal is for me to be able to load programs to the onboard XMOS chip

I think you want to take smaller steps ;-)

Quote:
segher wrote:
It is really OTP. You _can_ write to it over JTAG, but unless you do it on purpose
it just isn't going to happen :-)

You need to have more faith in my abilities! :) If it can be screwed up, I'll find a way!

I don't doubt that, but you are infinitely more likely to fry your chip with some
short-circuit (or whatever else stupid) first, way before you program the OTP (and
you can change almost all of the OTP contents to whatever you want anyway, if you
aren't going to boot from it -- just not the "boot from OTP" and "disable JTAG"
etc. bits).

Writing to OTP is a quite complicated procedure. You really will not manage to
do so accidentally, it is not a chance of one in a million.


Segher


Top
Offline Profile View all posts by this user  
 
PostPosted: Sun Apr 22, 2012 7:21 pm 
User avatar
Experienced Member
Joined: Wed Apr 11, 2012 6:21 am
Posts: 64
A picture is worth a thousand words.
Attachment:
File comment: Our connections on board
xena.jpg [113.62 KiB]
Not downloaded yet


The one test that was done previously used the XTAG header and worked fine.
The PLD has been programmed to tri-state the JTAG outputs when there is a programmer connected to XTAG. It also adds any additional XMOS chips on the XORRO card to the TDO/TDI loop if a card is present in the Xorro slot.

Currently I'm working with the PLD outputs X_TDI, X_TMS, X_TCK, X_TRST#, X_RESET# and the input X_TDO.


Top
Offline Profile View all posts by this user  
 
PostPosted: Fri Apr 27, 2012 10:01 am 
User avatar
Experienced Member
Joined: Wed Apr 11, 2012 6:21 am
Posts: 64
Porting the code has gone very well, my biggest problem right now is decoding the libusb/2232 calls back into basic bit operations. I have looked online and found very little in the way of documents on the 2232 as a JTAG device. Lots of people using it (or were), but very little info on the lower-level details.

Since libusb is foreign to my OS, I have been trying to replace it with a library of stub functions that will let me compile the code and inspect the arguments of each call. It's not the most efficient way of getting it done, but it is at least a few steps in the right direction.

One fun detail, the FTDI site is pushing an app from TI to educate people on how JTAG works. I dug out my old XP box to give it a try. It is a DOS app and would not run under XP. Checking again, I see it was posted by TI about 20 years ago. Ouch!
No wonder it won't run for me!

Any links to useful documents or other suggestions you might offer would be gladly accepted. :)

Thank You,
Lyle Hazelwood.


Top
Offline Profile View all posts by this user  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic   [ 30 posts ]  Go to page 1, 2, 3  Next


Who is online

Users browsing this forum: No registered users and 2 guests



Search for:
Jump to: