Trying to load code to new hardware

[gerrykurz]

OK, these signal captures are the first things sent out the xTime Composer tools when it looks for devices on the JTAG interface.

So what you are saying it seems to me is that my board is not getting the TMS input.

What would be really useful here is a utility that would allow individual JTAG commands and sequences to be sent and read from the PC. However, the USB interface to the XTAG2 board does not support this. All the protocol handling is done by the XTAG2.

I personally would not have designed the system this way. To me, the XTAG2 should simply be a USB to JTAG convertor and nothing else or at least a tool designed this way should be available.

[segher]

You can use any other JTAG adapter just fine, to talk JTAG
to an xcore device.

The firmware of the XTAG2 is downloaded from the host
to the XTAG2; writing such a firmware to talk "raw" JTAG
is on my to-do list (but has been there for a long time).
Maybe someone else will beat me to it, hint hint.

[gerrykurz]

OK fair enough, the xtag2 interface is an industry standard.

Writing a PC app and XMOS firmware for the XTAG2 to do raw jtag commands is also way outside of my to do list....unless it becomes the only way to solve this problem

So, current status:

Board assembly issues seem to be within or at least close to the xmos recommendations.

I have done the appropriate hardware mods to another one of my boards to meet the powerup, reset and trst conditions.

This board is responding exactly the same way as the previous one. To me, this seems very unlikely to be a result of random assembly opens on pins. Why would the TMS or TDI be open on two separate boards while other signals seem to be fine (ClockIn, ResetIn, SPI interface, TDO)

So what I am getting is same as the first board, a single 0 followed by 2633 followed by 17 0's, then another 2633 followed by 17 0's followed by another 2633 followed by another 17 0's and then what looks like the start of anther 2633

This seems to be a design issue to me and not an assembly issue.

I am interested in why you think that sending a 110 on TMS is not the usual thing to do when that is what xTime Composer seems to do when looking for devices. I agree it seems strange to want to look at the instruction register instead of the data register where you say the id code is after reset.

I am also interested in trying to use xgdb instead of xTime Composer to initiate JTAG interactions but there is no documentation on how to install xgdb or on the command set on the web site. Also you are obviously very familiar with what to expect on the JTAG interface, however it would be nice if this was documented so I could work through this on my own.

How can this be moved forward in a more efficient way?

[gerrykurz]

Here is some more information:

Schematic of the XSYS circuitry.

Two modifications that have been made are:

The buffer for the debug line has been bypassed so that it is now an I/O line to the XSYS connector

The ARM controller now controls the TRST line and holds it low until after the 1V supply comes up.

I am releasing TRST slightly prior to RST whereas the reference designs release them together. Could this be an issue?

[segher]

I wonder if U45D is strong enough to pull low all five MODE
and TRST it connects to? There is this erratum (mentioned
in the datasheets). And you said you modified the circuit here?

Having TRST come up before RST might cause problems;
the other way around should be safe.

One thing that works (but it sounds like you cannot rework
your board for it) is to connect TRST and RST on the device,
and let the TRST signal on the XSYS drive only the mode pins.

[mon2]

XS1-L16A-128-QF124 datasheet notes to tie RST_N and TRST_N together to pin 15 of XTAG-2 header. (page 56 of datasheet)

Could this be tested by your side ?

Thought there was a discussion on this subject and a possible race condition that can surface if not applied.

[mon2]

Please review the wiring of the XTAG-2 header. Specifically, where is Pin #1 on your XTAG-2 male pin IDC headers (2x10) on your PCB ? From a "bird's eye view" (top side/aerial view), Pin #1 should be the top left pin on the PCB (square peg). The way it is drawn in the schematic, Pin #1 = top right pin which would not incorrect to mate with the XMOS XTAG-2 adapters.

See attached drawing to compare.

< update - added XSYS header for XTAG use pinout from datasheet >

[gerrykurz]

Ok I checked the RST and TRST low voltage levels, both are less than 20 mV.

In this design, there is an ARM processor acting as a supervisor and internal communications processor. So I modified the TRST circuit to add an open collector output from the ARM to the buffered TRST line. This output gives me software control of TRST. It is a high output drive line and it seems to have no problem sinking the TRST load.

I modified the TRST timing in software and it is now coming up 124 nsec after RST (measured at the 2V minimum input voltage threshold)

Here is a picture of that: Red trace is RST, yellow trace is TRST



Here is a picture of the 1V supply to RST timing: Red is RST, Yellow is 1V supply, RST comes up 12 usec after 1V



And finally, here is a picture of the 3.3 V supply to 1V supply timing: Red is 3.3 V, Yellow 1V comes up 4 msec after the VDDIO supply reaches it's minimum level of 3V



Still not getting the JTAG to work.........

[gerrykurz]

I am using a vertical surface mount connector for the XSYS:

It is correct, here is a photo:

[segher]

I still suspect TMS. Try these two commands, see if the
second works better:

Code: Select all

xrun -l
xrun -l --jtag-speed 50