There are several types of error found by Connection Test which
regularly (and unsurprisingly) confuse users. This article tries to help out…

Mis-categorised Resistors

Mis-categorising a resistor is probably the most common mistake we see
in circuit set-up. It can cause problems whichever way it’s done.

• If a pull resistor is incorrectly marked as a “Connect” resistor
  then XJTAG will assume that both sides of the resistor are
  power/ground nets rather than just one side. It may be that another
  device on the net then toggles it, causing XJTAG to think the power
  pin is open-circuit. Or alternatively XJTAG doesn’t test a net that it
  could.
• If a low-impedance connection is marked as a pull
  resistor, XJTAG will try to drive the net at some point during the
  connection test. This can cause “stuck-at” errors or may cause the
  power supply to hit its current limit and cause a voltage dip deep
  enough to break the JTAG chain.
• If a pull resistor impedance is too high, it may not work
  properly, or if it does, it may take too long for the voltage to
  return to the correct state, causing XJTAG to take a reading before
  it has done so and causing the connection test to fail.

Configured devices

This happens with both CPLD and FPGA devices. Many programmable
devices can have their pins re-defined, to reduce their
capability. For example the BSDL file may say the pin has both read
and write capabilities, but the configuration applied may make it
write-only. XJTAG will try to read from the pin unaware that it is
disabled, and generally always read the same value. Pre-configured
devices generally result in a number of stuck-at errors being
reported.

We see this most often with FPGAs, where they download an image from a
PROM at power-up or even where they receive an image from a CPU as the
board boots, before it gets put into JTAG mode. Clearing the relevant
EEPROMs before testing and programming them afterwards is one
solution, or you can use the manufacturer’s tools to create a STAPL or
SVF file to clear the device and get XJTAG to run this before it
performs the Connection Test. Or perhaps better yet, bring the Mode
pins for the device(s) to a connector so that they can be put into JTAG
config mode.

Non-JTAG devices driving the net

We frequently see errors caused by non-JTAG devices driving the
net. This is in turn caused by the user not setting disable values
correctly. A typical example of this would be errors on a memory or
flash device’s data bus. During the connection test the device has to
be set not to drive the bus or it will conflict with XJTAG writing to
it. Typically this is done by setting an appropriate disable value on
the device’s chip select or output enable pin(s).

When Connection Test finds an error on a board it tries to ascertain what the problem is. This may involve carrying out additional checks, to try to eliminate noise on a floating net or cross-talk as a cause of the behaviour. If the fault appears to be genuine then the Connection Test reports the error.

On seeing a fault, most people’s first reaction is to want more information. So the first step for most people is to re-run the connection test with the debug level turned up, in order to see the output.
To do this, on the Run Tests screen in XJDeveloper or the main screen in XJRunner, look at the list of tests on the right (in XJRunner you need the ‘enhanced testing’ privilege to see this). At the bottom, there is a button marked "Options…". Click on this to see a pop-up with various
options. The last tab of those options is marked ‘Connection Test’ and allows you to vary the output level. Set that debug level to "All". Now re-run the connection test. Now it will show you a large amount of data for each fault.

For example (taken from the XJDemo board):


Error: Short found between nets: DIL10, DIL11.

Net DIL10 contains:
R39.2
JP6.20
CN3.11
IC3.18(IO18)
IC5.24

Net DIL11 contains:
CN3.12
R40.2
JP6.18
IC3.19(IO19)
IC5.25

      DIL10	 DIL11
      W     R    W     R
0     -     0    -     0
1     -     0    -     0
2     -     0    -     0
3     -     0    -     0
4     0     0    0     0
5     1     1    1     1
6     0     0    0     0
7     1     1    1     1
8     0     0    -     0    *
9     1     1    -     1    *
10    0     0    -     0    *
11    1     1    -     1    *
12    0     0    0     0
13    1     1    1     1
14    0     0    0     0
15    1     1    1     1
16    0     0    0     0
17    1     1    1     1
18    0     0    0     0
19    1     1    1     1
20    -     0    0     0    *
21    -     1    1     1    *
22    -     0    0     0    *
23    -     1    1     1    *
24    -     0    -     0
25    -     0    -     0
26    -     0    -     0
27    -     0    -     0
28    0     0    0     0
29    1     1    1     1
30    0     0    0     0
31    1     1    1     1
32    -     0    -     0
33    -     0    -     0

The first bit is easily understandable – XJTAG thinks there is a short between the two nets listed. The pins on each net are then listed because often looking at the lists of pins on the two nets will show that some adjacent pins are involved, which raises suspicions of a solder short  between pads on the board. You can also see if any test points or components such as resistors are on the nets should you wish to confirm the fault with a probe or multimeter.

Underneath that is the data.
This is the write (W) and read (R) information XJTAG has stored during the test. Depending on the type of fault this may be the value read on a net or value from an individual pin. For example with an open on the net it will display pins information, to let you see which pin doesn’t follow the rest of the net. In this case, because the error is a short circuit, the data is for nets. Down the left hand side are test numbers, and then the read and write values for each of the nets.

Marked tests (*)

For certain types of fault XJTAG marks (in groups of 4) tests where it considers the error to manifest itself by putting a * character to the right. For some faults it does not make sense to do this (stuck-at faults would be pretty boring) but where it is relevant the *s are shown.
In the above example, each set of *s shows a place where one of the nets is not being driven, yet it is picking up the value of the other net.

Undetermined faults

There are two error messages which indicate that XJTAG found something wrong but that it is unable to diagnose what the problem is. These error messages look like:

Error on net XXX: Undetermined error (possible open pin)

or

Error on net XXX: Either it is shorted to another net
or a non-JTAG pin is also driving the net.
 

Sometimes these errors occur because the circuit is more complicated than XJTAG has been told (eg logic devices or buffers (uni-directional devices) have been represented as simple connections) or because there are multiple interacting errors on the board which make it difficult to determine each one individually. Unfortunately XJTAG is going to have to pass the investigation of this one over to you. A good place to start is by checking whether this net can be driven by anything
else, and if so, whether that device has its disable values set correctly to prevent it driving the net during the connection test. XJAnalyser (if you have the licence) is also an extremely useful
way to investigate this kind of fault further.

The XJTAG connection test is an automated interconnect test which checks for shorts, opens, stuck high and stuck low errors on a circuit board. Some circuit boards have cross-talk or similar issues, which do not affect the normal running of the board, but are picked up by the XJTAG connection test.

The Connection Test screen is in the Run and Deploy section of XJDeveloper. It adjusts how the XJTAG connection test runs. If the connection test works for your circuit, it’s probably best to just leave that screen on its default setting, with the “Configure Connection Test” checkbox left unchecked.

“My Connection Test Fails!”

There are two distinct types of way in which the connection test can fail.

1. The connection test finds fault(s) with your circuit, and prints a message saying the type of fault it found and the net(s) it found the fault on.
2. During the test, the JTAG chain stops working. This causes the connection test to fail, typically producing a large amount of output with a “The JTAG chain appears to be broken” message at the end of it.

Type (1) is the sort of failure normally associated with a fault on the board which needs investigating. How to go about this, and how to deal with suspected false failures will be the subject of a future blog post.

Although type (2) could be caused by this, it is more normally seen during set-up and implies that the XJTAG system doesn’t know something it needs to. This would typically be :

• a) A missing “disable value” – typically something like a reset pin which XJTAG needs to be told to hold at a constant value to avoid resetting the board
• b) a watchdog chip that hasn’t been disabled
• c) XJTAG causing something to draw a current which causes a voltage drop, which in turn stops the JTAG chain operating. This may be caused by a power supply with a limit set a bit low, or may be due to XJTAG not being told of a connection or required constant value pin.

Fixing a ‘broken chain’

To track down these types of problems, turn on “Configure Connection Test” and set the Connection Test Type to “Debug Errors”. The next stage is to find out exactly what breaks the chain, and it’s a matter of stepping through the possibilities.

A “Debug Errors” connection test starts by putting all the nets into one state, and then switching them one at a time until they all arrive at another state. In your case you are looking for the place where it fails when trying to do this. There are 3 starting states and 2 finishing states, so there are 6 tests to run. Because it may be a one-directional problem (ie the problem happens when netA is low and netB is high, we also have a “direction” flag (giving another 6 test situations) if the first 6 don’t find a problem.

What you are looking for is the chain to break as it does during the normal test. This will cause a large amount of data to scroll past, and at the bottom again it says “The JTAG chain appears to be broken”. The following line will give you a pointer to the problem. It will say something like “A problem occurred whilst setting net NET23 high.” This is the place to start looking. What does that net do? Should it be kept at a constant value? Are there any resistors on that net that haven’t been properly defined? It may be worth setting the “Wait for keypress” option so that you can press a key to step through each net in turn.

Whichever options you choose it is often worth watching your board as the tests run, to see if the current demand surges or reset lights flash on, etc.

If you can’t reproduce the fault using the 12 tests above, then it may be that more factors are involved. There is a further option in the Connection Test settings to use a random setting algorithm. Check that box, start the connection test running, leave it while you go to a meeting, make a coffee, etc while it works.

It is also worth mentioning that the help in XJDeveloper gives details of each of the settings available in both modes.

Further information is also available on the XJTAG support pages in the “Application Notes” section.