Problem at first load with JTAG

Technical questions regarding the XTC tools and programming with XMOS.
norman
Active Member
Posts: 55
Joined: Wed Jan 11, 2012 2:27 pm

Post by norman »

About your last post, all VDD pins, VDDIO pins and GND pins (and center pad) are respectively connected.

One of the first thing i've done is to check the continuity between the xsys connector and the closest via of the XS1. I should have no reason - at this time - to suppose that there is a solder problem.

I've tried with a 100nF instead of 1uF for the PLL capacitor, no better luck. Thanks again !

I didn't find the OTP default value, obviously, i supposed that the JTAG access have to be enabled by default.


User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am

Post by mon2 »

Focus on the MODE2 & MODE3 pins. To boot from JTAG, these pins remain LOW.

Your schematic has MODE2 & MODE3 connected to #RESET.

Consider to apply a wire to ground onto the open drain buffer Pin 4 of device 2A. Being open drain, there is no harm to just short this pin to ground. Then test again.

What are the details of your clock source ? Are you using a 25 Mhz crystal or oscillator ?

25M REF X 8.33 = 208.33MHz BOOT
MODE[1:0] = 10 => PLL x 8.33

Power supply ok with the current draw ?

Update #1:
=====

Also do not agree with the use of #XCORE_TRST on pin 3 of the XSYS connector. This pin is MSEL and is driven by the external XTAG tool. Respectively, this should not be wired to #XCORE_TRST.

Check for the activity on Pin 3 of XSYS connector on working and compare to non-working. Like above suggestion, since this Pin 3 connection is to an open drain buffer - ok to connect to ground.

Update #2
======

Pin 3 of XSYS connector is being driven by the external JTAG tool so should be fine with respect to timing and wiring but do confirm that MODE2 & MODE3 remain low upon reset to allow for a JTAG boot.
From the SliceKit schematic:
You do not have the required permissions to view the files attached to this post.
norman
Active Member
Posts: 55
Joined: Wed Jan 11, 2012 2:27 pm

Post by norman »

I has the same idea about MODE2-MODE3-TRST wired to ground, without success.

the clock is a 25Mz oscillator (http://www.mouser.com/ds/2/160/FXO_HC73-7971.pdf)

How can i estimate the current draw ? the 1V linear regulator can provide 1.5A. I've tried with an external 1V DC power supply, without success...

I will post capture for TRST, TDI, TMS... when scanning the Xtag with Xtime.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am

Post by mon2 »

1.5A LDO for the 1V0 rail sounds fine. Does this regulator feature an enable pin ? The enable of this 1V0 regulator is to be used to enable this voltage rail only after the 3V3 voltage rail is stable.

Which P/N and vendor is applied for this 1V0 regulator ?

Your power source to feed this project has enough current ? 1A or higher should be ample.

Common grounds (different symbols are posted in the schematic) ?
norman
Active Member
Posts: 55
Joined: Wed Jan 11, 2012 2:27 pm

Post by norman »

the 1V LDO is a NCP565MNADJT2G, it has no enable pin but the source voltage (3V3->1V) is delayed to 500ms.
the power supply for all can provide 3A for VDD, VDDIO.

i have 85mA on the 1V after starting.

i've got 2 grounds, GND and GND_ETH, connected ahead.
You do not have the required permissions to view the files attached to this post.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am

Post by mon2 »

Suspecting that the delay between the 3V3 and the 1V0 rail power up is very (too) long. Can you steal the power rails from the working board and apply onto the non-working board ? Of course, remove or disable the non-working power supplies so that they will not interfere with the operation.

Fairly sure that the power sequencing is important here. The very large bulk caps on your power supply are likely responsible for the lengthy delay (ie. 150uf + 150uf). You should be fine to place a 10uf - 22uf (X7R or even electrolytic to get started) at the input of this regulator in place of the 300 uf.

The purpose now is to use a verified power supply from the working board and apply onto the non-working board to validate the power sequencing / power up timing.
norman
Active Member
Posts: 55
Joined: Wed Jan 11, 2012 2:27 pm

Post by norman »

if it can help, i capture the scope for the JTAG connection. as i saw, the capture are the same with or without the XTAG2 plugged.
You do not have the required permissions to view the files attached to this post.
norman
Active Member
Posts: 55
Joined: Wed Jan 11, 2012 2:27 pm

Post by norman »

I've use 500ms of delay to be close to the delay of the XR-AVB-BRD, i've tried with 100ms delay, not working ever.

here's the capture of the actual power sequencing. The rising time of 3V3 is under 5ms, and under 2ms for the 1V.
You do not have the required permissions to view the files attached to this post.
norman
Active Member
Posts: 55
Joined: Wed Jan 11, 2012 2:27 pm

Post by norman »

mon2 wrote:Suspecting that the delay between the 3V3 and the 1V0 rail power up is very (too) long. Can you steal the power rails from the working board and apply onto the non-working board ? Of course, remove or disable the non-working power supplies so that they will not interfere with the operation.

The purpose now is to use a verified power supply from the working board and apply onto the non-working board to validate the power sequencing / power up timing.
i use the 3V3 and 1V of the working board, still the problem, i try the same thing with other pin like RST...
Redeye
XCore Addict
Posts: 131
Joined: Wed Aug 03, 2011 9:13 am

Post by Redeye »

mon2 wrote:Suspecting that the delay between the 3V3 and the 1V0 rail power up is very (too) long.
Apologies for a brief thread hijacking here, but can someone explain this as we've just seen this as a problem while working on a variant of an existing board. Basically if the 1v0 doesn't come up very quickly after the 3v3 then the system won't boot. I'm not aware of any specification for a maximum time between 3v3 good and 1v0 good. Have I missed something on a datasheet somewhere? Or is there an explanation for this behaviour?