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).
User avatar
rp181
Respected Member
Posts: 395
Joined: Tue May 18, 2010 12:25 am

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

Postby rp181 » Sun Jul 31, 2011 3:46 am

I have been trying for a couple of weeks to get the XTAG2 to talk to my board, unsuccessfully. I do not know what to try now.
To date, this is what I have done:
Bypassed the TRST,RST,TCLK,and TMS buffers as the signals were not passing through those correctly.
After powerup (sequence is correct), manually hold TRST to ground while pulling RST low to ensure boot into JTAG (MODE pins tied to TRST)

I have been comparing signals from the XK-1 to my board. The XTAG pulls the TRST pin low, then sends a pulse on TDSRC. The XK-1 sends a pulse on TDO, but my processor is sitting inactive. Here are some scope screenshots.
In this one, I am in the run-> run configurations menu, and pressing refresh on the list of devices.
http://i.imgur.com/aIH68.png
(I might not have had TDSRC connected; it usually gives a pulse after the TRST is pulled low)
Here is a picture of the Clock signal:
http://i.imgur.com/eONtU.png
I took sphere's advice and checked the SPI pins (its supposed to boot to SPI when XTAG is not connected, as both MODE pins are tied to TRST and TRST is high default), and there is a good clock signal and pulses coming through the DI pin. This isolates the problem to the JTAG.

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

Postby rp181 » Sun Jul 31, 2011 4:10 pm

Here are two more pictures.
This first one is when I turn on the 3v3 supply.
http://i.imgur.com/qfJEi.png
Obviously this 1 volt, trst, and rst rising edges are too close, so after this, I manually grounded TRST and RST. I then booted it into JTAG mode by keeping TRST grounded while pulling RST high. This is a picture of the XTAG trying to initiate communication:
http://i.imgur.com/g8vLX.png
User avatar
segher
XCore Expert
Posts: 843
Joined: Sun Jul 11, 2010 1:31 am

Postby segher » Sun Jul 31, 2011 6:48 pm

rp181 wrote:I then booted it into JTAG mode by keeping TRST grounded while pulling RST high.
That's not what causes JTAG boot mode: you need to set the MODE pins for that. Nicely
designed boards will have circuitry to pull the MODE pins when TRST is active, so that
the chip boots in JTAG mode when TRST is held low when you let RESET go high.
User avatar
rp181
Respected Member
Posts: 395
Joined: Tue May 18, 2010 12:25 am

Postby rp181 » Sun Jul 31, 2011 7:07 pm

Oops, should have mentioned that. Yes, TRST is tied to the MODE2 and MODE3 pins.
User avatar
rp181
Respected Member
Posts: 395
Joined: Tue May 18, 2010 12:25 am

Postby rp181 » Sun Jul 31, 2011 11:44 pm

In order to clean it up, I desoldered the JTAG wires and put them back on, now actually bypassing the buffers rather than skipping the whole Buffer and Pull ups. Now I get a error, rather than no device found. When trying to execute, this comes up:
set_configuration_error -6
set_configuration_error -6
xrun: Problem in connection to device
snoopy
Member++
Posts: 28
Joined: Wed Dec 01, 2010 5:46 pm

Postby snoopy » Mon Aug 01, 2011 11:14 am

I don't think you can bypass the buffers. There is a slight issue where the pads will not be able to draw enough current from the JTAG lines, so without buffering them the signal dies and you end up with zip. Do you have a schematic of your board??

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

Postby rp181 » Mon Aug 01, 2011 12:30 pm

The buffers are only needed with multiple processors, it is fine without one for now.
I attached the schematic.
Last edited by rp181 on Thu Aug 04, 2011 11:06 pm, edited 1 time in total.
snoopy
Member++
Posts: 28
Joined: Wed Dec 01, 2010 5:46 pm

Postby snoopy » Mon Aug 01, 2011 1:57 pm

I imagine that the buffers are in fact connected to power and ground right?

Also the PLL_AVDD doesn't look connected to VDD.

The only other thing I can think is maybe the power supervisor. Its recommended that the +1V0 enable signal comes from a +3V3 "power good" signal which ensures its already ramped before +1V0 is at most 0.4V. How is your +3v3 supplied?

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

Postby rp181 » Mon Aug 01, 2011 2:35 pm

I imagine that the buffers are in fact connected to power and ground right?
Well, that explains that. I had made this block in a separate file and added it in later, so I forgot to connect power. Especially bad considering I have GND and PWR planes. I will try putting those back on.
Also the PLL_AVDD doesn't look connected to VDD.
It is, through the 4.7 ohm resistor as recommended. I checked it, and it is a very clean supply. Odd though, I noticed that too when looking over the schematic again.
The only other thing I can think is maybe the power supervisor. Its recommended that the +1V0 enable signal comes from a +3V3 "power good" signal which ensures its already ramped before +1V0 is at most 0.4V. How is your +3v3 supplied?
I am feeding 3v3 directly from a digital power supply (Agilent U8001A). The power ramps up quite slowly; it takes 30ms to get to 3v3 (the PSU is slow, not due to my capacitances. Same thing when using an Omega PSU301). However, the 1v line comes on well after the 3v3 is in spec, around 30ms I think. This ramps up quickly from the onboard reg (NCP1521B). I used a RC (5M ohm, 100nf) circuit on the enable pin of the NCP1521B to provide the delay.
snoopy
Member++
Posts: 28
Joined: Wed Dec 01, 2010 5:46 pm

Postby snoopy » Mon Aug 01, 2011 2:56 pm

Hmmm I'm at work at the moment so can't really look at it properly but I'll try have a look when I get back home....but nothing is screaming at me.

Maybe try with the buffers again but connect them to the power??

Can't think of anything else off the top of my head.

Keep us updated if you find a solution

Who is online

Users browsing this forum: No registered users and 4 guests