Stumped on getting the XTAG2 to talk to a L1-128 processor

Technical discussions around xCORE processors (e.g. General Purpose (L/G), xCORE-USB, xCORE-Analog, xCORE-XA).
MaxFlashrom
Experienced Member
Posts: 82
Joined: Fri Nov 05, 2010 2:59 pm

Re: Stumped on getting the XTAG2 to talk to a L1-128 processor

Postby MaxFlashrom » Wed Aug 03, 2011 8:34 pm

snoopy wrote:TMS won't show anything until the JTAG chain is set up. It should remain low until the boundary scan is complete and the JTAG is ready to go.

As far as I know (its been a while since I had a look at JTAG traffic), the TMS will remain low until the JTAG state is ready to change. Once it is ready, TMS will be high and on the next TCK it will change state, TMS will then go low again and remain low until JTAG state machine is ready to move to the next state again.

Do you get any data on TDI and TDO? If these don't work, the JTAG boundary scan will fail.

EDIT: Also check TCK. Without a good clock nothing will happen on any of the JTAG lines

S
The XS1-L1 has two JTAG IEEE1149.1 TAP(Test Access Port) controllers within. The TAPs control access to n-bit shift registers, or scan chains. One such scan chain accesses cells interposed between a chip's pins and its internal core; this is the boundary scan chain. It is not mandatory to perform any operation on this scan chain. and indeed when using the JTAG interface to program a chip's internals this is often ignored. JTAG is ready to go usually after power-up. The JTAG interface comprises TCK(Test Clock), TMS(Test Mode Select), TRST(Test Reset), TDI(Test Data Input) and TDO(Test Data Output). TCK is a clock signal used to clock in data to a finite state machine within each TAP. On each rising TCK the FSM moves to a new(or the same state) ;how it moves depends on the state of the TMS input signal on the rising edge of each TCK pulse.
On each falling edge of TCK data is clocked out of the target chip's TDO.

Asserting the asynchronous TRST signal puts the FSM in a known state, Test-Logic-Reset. The TAP FSMs can also be reset by holding TMS high and issuing 5 TCK pulses. One is then ready to go. To move from the reset state, TMS must = 0, on the next TCK rising edge. This next state is called Run-Test/Idle. It's not that useful and one must move on again to Select-DR-Scan, this requires TMS=1 on next TCK. So, you see TMS is doing a lot of transitions just to get started: it should be doing stuff!

TCK must transition, TMS must transition, data should be coming out of the XTAG TDSRC, going into XS1-L1 TDI(Mine clocks about 12 zeroes in before starting to clock loads of 1s). If the L1 is alive data must come out of its TDO pin, feeding the XTAG TDSNK. If you see nothing on TDO you're not winning! Check that TMS and TCK are not shorted to anything. Check that TDI and TDO are not shorted to anything.

You indicate the XS1 seems to be alive by the fact that it appears to attempt an SPI boot when you set the mode pins[3:2] to 11. I notice you have wired PCU_WAKE to ground rather than leaving it unconnected as recommended in the datasheet, though if the SPI boot seems to be doing its stuff this is probably OK.(I know, leaving CMOS inputs floating which may or may not have an internal pull-up/down makes me nervous too). The data is somewhat vague on whether this pin is active high/rising edge triggered and whether it should be high/low/don't care in normal woken operation. If one follows the datasheet and one's not using it to wake the chip from sleep this need not concern you.

You could try
xrun -l --jtag-speed 100
from the command-line. So as not to conflict with the IDE, it is best to do this while not running that at the same time. This will query the board slowly.
If all is well you will see something like this:

Available XMOS Devices
----------------------
ID Name Adapter ID Devices
-- ---- ---------- -------
0 XMOS XTAG-2 a3zvg42z L1[0]

If stuff is not working it will say "None" or "Error" under Devices rather than the desired "L1[0]"

Hope that helps
Max.
User avatar
rp181
Respected Member
Posts: 395
Joined: Tue May 18, 2010 12:25 am

Postby rp181 » Wed Aug 03, 2011 9:59 pm

Thank you for the excellent reply!

It does look like my problem is mainly the TMS, nothing happens on it. In addition, my TRST line "low" may be too high at 580mv. I am suspecting this is due to the pull ups and caps on the lines before the buffer; so I am going to add the buffer and see what happens before pulling those components.
Here are some more screenshots. I did what you suggested, and the JTAG clock is now operating at 245khz.
Note that I am having some noise issues (from ground loops and such) on my scope; but you can pick out the nosie (the clock, and triangle shaped transitions into negative voltages).

One set of two pulses. What is displayed happens twice, the other one after quite some time.
http://i.imgur.com/9STE8.png
TCK, 245khz:
http://i.imgur.com/9nilg.png
Zoom in the initiation:
http://i.imgur.com/RAnnL.png
the TRST form makes it look like a capacitor problem, and you can see the noise on the other lines caused by the TRST transition.

TMS is quite on all accounts.

EDIT:
I painstakingly soldered on the buffers and actually gave them power. After realizing I should have connected the XTAG GND to my scope/psu ground, they work great. The output is very clean, more than that of the input.
The odd thing is though, the buffer is not working on the TMS signal. I see a TMS signal before the buffer, but its just gone after the buffer. These are dual channel buffers; and the other channel works fine. Otherwise, all other signals check out at the processor pin.

Current draw also went up to 90ma. When I unplug it from the computer, current draw goes up to 120ma.

Thank you all!
MaxFlashrom
Experienced Member
Posts: 82
Joined: Fri Nov 05, 2010 2:59 pm

Postby MaxFlashrom » Thu Aug 04, 2011 12:00 am

rp181 wrote:Thank you for the excellent reply!

It does look like my problem is mainly the TMS, nothing happens on it. In addition, my TRST line "low" may be too high at 580mv. I am suspecting this is due to the pull ups and caps on the lines before the buffer; so I am going to add the buffer and see what happens before pulling those components.
Here are some more screenshots. I did what you suggested, and the JTAG clock is now operating at 245khz.
Note that I am having some noise issues (from ground loops and such) on my scope; but you can pick out the nosie (the clock, and triangle shaped transitions into negative voltages).

One set of two pulses. What is displayed happens twice, the other one after quite some time.
http://i.imgur.com/9STE8.png
TCK, 245khz:
http://i.imgur.com/9nilg.png
Zoom in the initiation:
http://i.imgur.com/RAnnL.png
the TRST form makes it look like a capacitor problem, and you can see the noise on the other lines caused by the TRST transition.

TMS is quite on all accounts.

EDIT:
I painstakingly soldered on the buffers and actually gave them power. After realizing I should have connected the XTAG GND to my scope/psu ground, they work great. The output is very clean, more than that of the input.
The odd thing is though, the buffer is not working on the TMS signal. I see a TMS signal before the buffer, but its just gone after the buffer. These are dual channel buffers; and the other channel works fine. Otherwise, all other signals check out at the processor pin.

Current draw also went up to 90ma. When I unplug it from the computer, current draw goes up to 120ma.

Thank you all!
Your graphs, and what you tell me about TMS after the buffers strongly suggest to me that the TMS signal on your board is shorted to ground after the buffers, most likely at the chip. This will not do your buffers much good:they may get hot. The power consumption will also be high. TMS is pin 58 on the L1-128 package. It is sandwiched between GND(pin 57) and VDD(pin59). Turn your board off. Get out your DVM and check the resistance between TMS after the buffers and ground. Get out your magnifier and check that pin 58 is not shorted to 57.

My TMS starts high immediately and goes low after about 7 TCKs and then high again.

Good luck
Max.
snoopy
Member++
Posts: 28
Joined: Wed Dec 01, 2010 5:46 pm

Postby snoopy » Thu Aug 04, 2011 10:08 am

MaxFlashrom wrote: Asserting the asynchronous TRST signal puts the FSM in a known state, Test-Logic-Reset. The TAP FSMs can also be reset by holding TMS high and issuing 5 TCK pulses. One is then ready to go. To move from the reset state, TMS must = 0, on the next TCK rising edge. This next state is called Run-Test/Idle. It's not that useful and one must move on again to Select-DR-Scan, this requires TMS=1 on next TCK. So, you see TMS is doing a lot of transitions just to get started: it should be doing stuff!

TCK must transition, TMS must transition, data should be coming out of the XTAG TDSRC, going into XS1-L1 TDI(Mine clocks about 12 zeroes in before starting to clock loads of 1s). If the L1 is alive data must come out of its TDO pin, feeding the XTAG TDSNK. If you see nothing on TDO you're not winning! Check that TMS and TCK are not shorted to anything. Check that TDI and TDO are not shorted to anything.
That makes things a lot clearer re the signals, I was under the impression TMS would remain low due to reset and would only rise when moving to the next state. I've not got access to an oscilloscope so I haven't looked at the traffic from an JTAG since I first got my hands on an XK-1 :s

I'm also a bit apprehensive about leaving the PCU pins floating but they have done that on the XK-1, its in the documentation and as of yet I haven't seen any real application of it. I saw a suggestion somewhere on the forum which indicated that all the IO must have pull downs on them if your planning on using the PCU :/

But thats a whole different topic. Look forward to hearing what your discover rp.
User avatar
rp181
Respected Member
Posts: 395
Joined: Tue May 18, 2010 12:25 am

Postby rp181 » Thu Aug 04, 2011 12:30 pm

It seems it is shorted to VDD. Looking back at the scope shots, you can see that. I will try to fix that today. I don't see any short between the pins, but I will flood it with solder and wick away incase there is a small bit in the "back".

This looks like the last probem :D
User avatar
rp181
Respected Member
Posts: 395
Joined: Tue May 18, 2010 12:25 am

Postby rp181 » Thu Aug 04, 2011 9:48 pm

It works :D
Thanks guys! I am going to look into the flash programmer now, and I can actually start working on my app!

EDIT: Flash works flawlessly; i'm glad I did something right.

Looking back; the only error was the power to the buffers and that soldering mistake. Time to invest in a microscope.
MaxFlashrom
Experienced Member
Posts: 82
Joined: Fri Nov 05, 2010 2:59 pm

Postby MaxFlashrom » Thu Aug 04, 2011 10:25 pm

I'm glad you got it sorted out and the the chips still work OK!

The buffer chip will have been doing its best to shove 3.3V into the 1.0V power supply through the short to VDD, which is not great. I assumed a ground short as I missed that TMS was looking more like 1.0V than 0V on your 'scope traces and forgot that VDD was 1.0V on the L1, so it would not look like an I/O-level HI of 3.3V

We had a very similar problem on one of our boards where the only problem was that TCK and TDI were shorted together by a solder bridge at the XSL-L1-128's pins. That 0.4mm pin pitch is really tricky.

Max.
User avatar
rp181
Respected Member
Posts: 395
Joined: Tue May 18, 2010 12:25 am

Postby rp181 » Thu Aug 04, 2011 11:06 pm

Agreed; My usual method of soldering larger chips is drag soldering (with a proper tip too), but that failed too. I also tried hot air, but that also did not work well. I resorted to the flood and wick method :/
User avatar
rp181
Respected Member
Posts: 395
Joined: Tue May 18, 2010 12:25 am

Postby rp181 » Sun Aug 07, 2011 11:22 pm

I soldered up another PCB, to test the stacking. Of course, this is not working. The mux looks like it's working, but the default state on the top PCB TDO (second PCB TDI) is default 1.8v. I think this is the cause of the error.

With a single processor, not connected to the XTAG, the TDI line is default high and the TDO low. When connected, the TDI line is brought low. It looks like the TDO line of PCB 1 is not able to pull the TDI line of PCB 2 low all the way. Here is a screenshot.
http://i.imgur.com/bjlXv.png
On the flipside, when actually signaling it is able to bring the line low.
User avatar
leon_heller
XCore Expert
Posts: 546
Joined: Thu Dec 10, 2009 10:41 pm
Location: St. Leonards-on-Sea, E. Sussex, UK.

Postby leon_heller » Mon Aug 08, 2011 10:05 am

rp181 wrote:It works :D
Thanks guys! I am going to look into the flash programmer now, and I can actually start working on my app!

EDIT: Flash works flawlessly; i'm glad I did something right.

Looking back; the only error was the power to the buffers and that soldering mistake. Time to invest in a microscope.
I use one of these SM-20 stereo dissecting microscopes:

http://www.lakeland-microscopes.co.uk/stereo.html

The optical and build quality are surprisingly good for such a cheap unit.

Who is online

Users browsing this forum: No registered users and 1 guest