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
Documents detailing XTAG interface?
-
- Experienced Member
- Posts: 71
- Joined: Wed Apr 11, 2012 6:21 am
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
https://www.xcore.com/projects/xs1-disa ... jtag-tools
will probably help you. If you have any specific questions, do ask!
will probably help you. If you have any specific questions, do ask!
-
- XCore Addict
- Posts: 147
- Joined: Tue Feb 23, 2010 6:55 pm
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.
-
- Experienced Member
- Posts: 71
- Joined: Wed Apr 11, 2012 6:21 am
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. :)
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
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. :)
Thank You, Segher. I'm sure there will be manyIf you have any specific questions, do ask!
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
-
- Experienced Member
- Posts: 71
- Joined: Wed Apr 11, 2012 6:21 am
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
(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
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
The code XMatt pointed you to is the code that is usually used on the XTAG2. MyLyleHaze 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.
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).
How do you do that? It is hard to tell what (if anything) you are doing wrong, ifStarting simple, I tried setting the JTAG chain to all "BYPASS" and then counting the devices on the chain.
you don't tell us what you do :-)
There are four JTAG devices on the chain (after reset), on an L2; two for each chip.I get a 3 or 4 returned, depending on when I sample the DO pin.
The MUX and the boundary scan controller. The MUX is last on the chain, i.e.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.
closest to TDO.
You do not need to set up anything. You should reset the TAP (toggle TRST).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?
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.
It is really OTP. You _can_ write to it over JTAG, but unless you do it on purposeAnother "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 just isn't going to happen :-)
If the port is serialised output, then yes. It does not run the next code until theI 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??
last output data has been on the pins for at least one tick.
From whatever clock source you configured! Usually the REFCLK divided by something.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?
HTH,
Segher
-
- Experienced Member
- Posts: 71
- Joined: Wed Apr 11, 2012 6:21 am
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: 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).
Fair enough. ;) I found an interesting website that promised to make JTAG easy! (Uh Oh)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 :-)
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.
Great! Now I can put the data capture from TDO in the correct part of the clock cycle and proceed from there.segher wrote:There are four JTAG devices on the chain (after reset), on an L2; two for each chip.
More great information. I understand exactly where to look.segher wrote:The MUX and the boundary scan controller. The MUX is last on the chain, i.e.
closest to TDO.
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: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.
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:Does your xcore run code? Often when your clock or reset stuff doesn't work
correctly, you get all zeroes on TDO.
You need to have more faith in my abilities! :) If it can be screwed up, I'll find a way!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 :-)
Again, I thank you for your time and help. More to study, more code to write.
LyleHaze
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
It is a USB-to-bunch-of-pins converter: UART, SPI, JTAG, I2C, junk bus. It hasLyleHaze wrote: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: 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).
_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 :-)
Maybe because it is incorrect :-)Fair enough. ;) I found an interesting website that promised to make JTAG easy! (Uh Oh)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 :-)
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.
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.
TDI, TDO, TCK are all driven on the falling edge of TCK, and sampled on the risingGreat! Now I can put the data capture from TDO in the correct part of the clock cycle and proceed from there.
edge of TCK.
You can used the "five ones" method to do test-logic-reset, instead of TRST; _but_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 need to handle the TRST and RST signals properly at startup. If you do not,
the xcore's JTAG will not work.
Okay, so you have an XSYS port, and using it you "see" the xcore? Excellent,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.segher wrote:Does your xcore run code? Often when your clock or reset stuff doesn't work
correctly, you get all zeroes on TDO.
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).
I think you want to take smaller steps ;-)The first goal is for me to be able to load programs to the onboard XMOS chip
I don't doubt that, but you are infinitely more likely to fry your chip with someYou need to have more faith in my abilities! :) If it can be screwed up, I'll find a way!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 :-)
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
-
- Experienced Member
- Posts: 71
- Joined: Wed Apr 11, 2012 6:21 am
A picture is worth a thousand words.
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.
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.
You do not have the required permissions to view the files attached to this post.
-
- Experienced Member
- Posts: 71
- Joined: Wed Apr 11, 2012 6:21 am
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.
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.