Main features

Device library/auto-categorisation

XJTAG 2.6 brings an update to the way devices are categorised in XJDeveloper. XJDeveloper can now use its installed library of devices to make suggestions for how to categorise devices. This uses information from the BOM and other information to make the suggestions. The user can then accept some or all of the suggestions.

Updates to the device library will be made available and automatically detected through XJDeveloper so long as the software remains in maintenance. It requires your customer support login to the XJTAG website – if you do not have one or have lost it please contact XJTAG Support. Likewise if you feel we are lacking support for particular devices in the library, please let us know.

New XJRunner Integration API

XJTAG version 2.6 has a new integration interface using .NET, and reworked LabVIEW VIs, which make it easier to integrate XJTAG into other test solutions or into your own programs. These new interfaces also make it possible to use formatted XJEase text output and to access the Layout Viewer.

XJDeveloper enhancements

In particular the Netlist Explorer has been enhanced. The window is now non-modal, which is to say that it can now be left open whilst other operations are performed, and other enhancements have been made to improve usability.

Chain Debugger

The output formatting has been improved and a debug option has been added to allow you to view the raw data returned from the JTAG chain.

What is the Safe bitstream?

The Safe bitstream is the default binary data that is shifted into the JTAG devices. The aim of the safe bitstream is to disable as much of the board as possible. This means that in general, logic devices that have a chip enable pin will be disabled, and pins on the JTAG devices will be setup as input pins wherever possible.

How is it generated?

The Safe bitstream is generated automatically by XJEase, and derives first of all from the BSDL files in the project. Part of the description of the boundary scan register includes the values needed to disable pins, and what the resulting disabled value will be, so the starting point for the Safe bitstream is one which disables all possible outputs. This starting point is then modified to take account of any constant pins or disable values where signals need to be driven in order to keep other parts of the circuit disabled. For example, the nOE pin on a RAM device would be set to be driven high (by the disable values in the device busses) to stop the data bus becoming active.

In addition to this, XJTAG’s safe bitstream will drive pins which need to be driven in order to prevent logic devices outputting, e.g the enable pin on a buffer chip.

When is it used?

The Safe bitstream is automatically applied on two occasions:

1. Before the first test that accesses the boundary scan registers.
2. At both the beginning and end of the Connection Test.

The user can also cause the Safe bitstream to be applied at any time during device testing by using the in-built SAFE statement.

Warnings and Errors

The most common problem to see relating to the Safe bitstream is a Warning that two conflicting disable values have been set on the same net. In this case XJEase will pick one of the two values. The warning message states which value has been chosen. As with all warnings the project can be run with the warning present but it is best practice to resolve these Safe bitstream conflicts so that the disable values for a net are uniform. It is not safe to rely on the same value always being chosen – updates to XJTAG or modifications to the project may cause it to change.

Calculating the Safe bitstream can also cause an error when you try to run the project (typically at the start, when the safe bitstream is calculated) and testing will stop at this point. The most common cause for the errors is a mistake when defining logic devices in the circuit, causing XJTAG to default the net to a value which is unreachable. If this happens then the error message will list the pins involved in the error and the values they are being set to, so that you can track down the source of the error.

The process of programming the internal flash memory uses the IR path of the JTAG state machine to select or address specific registers in the flash controller and then uses the DR path to read or write the selected register.

The programming algorithm for a MSP430 does have one extra complication.  It uses the TDI pin to perform two different functions depending on which state the TAP controller state machine is in.

In all but the Run Test Idle state the TDI pin performs its normal function, allowing 1s and 0s to be shifted into the DR and IR registers, but in the Run Test Idle state the TDI input  becomes the TCLK input.  The TCLK input is used to clock the internal flash controller, causing data to be written to memory, and should not be confused with the standard TCK input used to clock the JTAG state machine.

The TCLK input has another restriction in that it has to be clocked at 350 kHz.  This can be achieved by setting the JTAG system’s TCK frequency to 700 kHz. Any pin on the XJLink can only be changed once per TCK period so this results in a 350 kHz TCLK signal.

If you are interested in using the MSP430 code we have developed, please, contact support@xjtag.com for more information.

Main features

Layout Viewer

New in version 2.5 is our Layout Viewer tool. Instead of providing a simple text netlist, you can use an ODB++ job exported from a CAD tool; this contains both netlist and layout information.  If you’re using an ODB++ job, then wherever XJDeveloper has the option to use its Netlist Explorer you can now also choose to view the layout graphically. You can also superimpose that layout view on a photo of the relevant side of the board if you wish to.

XJRunner users are not left out – when you pack a project which has layout information in it, you can choose to include an embedded version of the Layout Viewer, so that the user running tests can click on Connection Test errors and be shown the exact locations of faults.

Categorising Devices

XJTAG no longer requires all JTAG-accessible devices to be categorised before you can start running tests. This change in behaviour means you can dive much quicker into board bring-up. Don’t forget to finish the board setup properly later though – as obviously until you do you don’t get full test coverage.

Test Summary

XJRunner now includes a brief summary of the test results at the end of testing in an easy-to-read table. It’s a small feature but we’re getting lots of positive comments about it!

Usability Enhancements

We’re constantly listening to our customers about their experiences using XJTAG. Based on this feedback we fixed a long list of requested usability issues and minor enhancements. As always, we welcome your feedback on using XJTAG. Please feel free to contact us to let us know where you feel we could improve the tools.

(These tips assume the JTAG chain is already configured)

1. Start from the bottom of the Unassigned Devices list, i.e. with the series resistors, and work your way up.
2. As components are categorised and more are discovered go back to the bottom and work your way up again.
3. Once you have classified the first batch of series resistors it is worth checking any new Suggested Series Resistors that appear immediately.  It is unusual to have multiple series resistors on the same net.  If you get lots of new series resistors for classification is it likely that a power net has not been correctly categorised.
4. Classify all Suggested Resistor Packs as pull resistor packs and then use the errors to identify which ones should really be classified as series resistor packs.
5. In general capacitors go in the ignore list.  The only time they do not is if they happen to be on a net between two 1149.6 devices.
6. Unused connectors and headers go in the ignore list.
7. When classifying a Suggested Device use the Explorer to check there is enough access to a device to test it before spending the time locating the right XJEase script.
8. Test points go in the Unfitted category.  This stops them having an effect on the DFT coverage report.  Uncheck “Only Show Accessible Devices” to make sure they are all found.
9. Classify any fuses, ferrite bead, or inductors with a PDD file so that all the power nets on the board are correctly identified.  Again, uncheck “Only Show Accessible Devices” to make sure they are all found.
10. Make sure you read any BSDL file warnings (before you disable warnings on those devices). Reading them is likely to explain why the JTAG chain didn’t run the first time you tried it…

First, it will expect one end of the resistor to be attached to a net that has been classified as a Power or Ground net.

Second, during the Connection Test it will expect to be able to drive the non-power/ground side of the resistor to the opposing value.  So, if it is a pull-down resistor the connection test will check that it can drive the non-power side of the resistor high.

If you have a strong pull resistor, say 50 Ω, then it is not unusual that the JTAG device will be unable to supply enough current to oppose the pull resistor.  In these cases where it is not intended for the pull of the resistor to be opposed, e.g. configuration strapping resistors, the resistor should be classified as a series resistor.  The non-power net will still be covered by the connection test but instead of driving the net it will be checked that at no point does the net take the opposite value to its pulled value.

If a BOM is imported as part of the setup or if the net list contains the resistor values, e.g. the net list is in the RINF format, then the XJTAG system will not suggest low ohmic value resistors as pull resistors but instead will put them in the “Other Resistors” category so the user can assign them appropriately.

The good news is that the OMAP processors do support boundary scan testing. The bad news is that it does not work straight out of the tin.

TI do provide the instructions that are required to enable the boundary scan registers:

http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Components.PostAttachments/00.00.10.29.73/OMAP343_5F00_BSDL.pdf

http://processors.wiki.ti.com/index.php/Boundary_Scan_on_OMAP35x

Unfortunately these do not give the whole story and the boundary scan register still will not function correctly:

http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/35977/130644.aspx

If you need to do boundary scan testing with a OMAP 35xx contact XJTAG Support (support@xjtag.com) and we will complete the story for you.

Did you ever attempt to diagnose, understand or repair a mechanical or electro-mechanical mechanism (perhaps a toaster that won’t toast or even a gearbox from a car or motorbike)? Once you’ve removed the covers and are able to look at what you have, if you are lucky you may immediately see a broken component, but more than likely it will be hidden from immediate view. That’s when the engineers’ instinct to start moving the parts of the mechanism will become difficult to resist. Say you turn an input shaft and it gets stuck, you can use that as a starting point and ask “why is it stuck?” That’s a new track that may well lead to the answer you are looking for. Interacting with a problem, not simply observing is much more powerful as a problem solving method.

XJAnalyser is an ideal engineers’ tool that will allow you not only to observe, but also to interact with your board to debug or fault-find problems. Because it’s a “plug and play” tool, it’s always there when you need to explore board level issues in an intelligent, interactive and inspirational way. It won’t hold back your natural problem solving instincts by requiring a lengthy set-up.

The tool allows you to make use of the inbuilt JTAG test access. XJAnalyser allows you to not only to control circuit nets with a click of the mouse, but also show you the result on a clean graphical view. Just like the mechanical fault analogy, you are able not only to observe, but also to manipulate.

You can quickly put your circuit into a state that will test your hunch. This might be impossible (or just very time consuming to achieve) within the “mission mode” operation of the circuit, perhaps requiring board mods or even special fault finding software to be written. Just like being able to turn the shaft of a gearbox to answer instinctive curiosity, with XJAnalyser you can either provoke some aspect of the problem or eliminate one of a number of possible explanations.

In fact, the analogy with mechanical systems understates the full power of XJAnalyser because it gives you visibility (and control) of circuit nodes which increasingly in modern electronics are entirely hidden from view and physical access. Once used XJAnalyser will quickly take its place alongside oscilloscope, logic analyser and multi-meter as an indispensable part of your work bench.

Logic between JTAG devices

In some scenarios both input and output of the logic gate/combination-of-gates can be read from JTAG. In this situation the connection test has it easy – it can ensure that the logic always ouputs the expected value given the state of the inputs. If one of the pins is shorted to another JTAG-controlled net, we will report that. In the event of an open-circuit error or a pin shorted to power/ground the connection test will detect an error but will probably not be able (currently) to diagnose the exact problem. However, it will say that an “unexpected value” was recorded on a net with logic on it, and output the data it has for the block. More on that below…

Logic only partially accessible from JTAG

We see a lot of logic in the situation where one side is driven from a JTAG-enabled device, and the other side goes to a Test Device.  Perhaps the obvious example is a buffer device going from a processor or FPGA to the address bus on a memory chip. Typically in XJEase projects, the chip select of the memory will be held high during the connection test. If this is the case, then the connection test will be free to drive the address bus. So during the logic part of the connection test it will do just that. In this case it will not pick up shorts between the (buffer-driven) address bus lines during the connection test – these will be picked up as failures by your RAM tests. But the buffers will be driven in the connection test, which will pick up any shorts to other JTAG-readable/writeable nets.

If you don’t wish the connection test to drive your bus via logic, you can set disable values on the test device as  in previous versions of XJTAG. In the example above, this would typically mean that the connection test will then hold the buffer’s *EN pin high, so that it can test the buffer inputs for shorts, without driving anything to the test device.

Once again in this situation, shorts are easy to diagnose – other unexpected errors will often get picked up as an “unexpected value” on a logic net.

Interpreting “unexpected value on logic net” errors

This error simply means that the values read back during the connection test did not match what XJTAG was expecting to read, given its calculations of the state of the logic blocks in the circuit.If you expand the error details on the output screen, generally you will be able to see in one or more of the rows that a pin has different values in its read and write columns (and the row should be highlighted in blue). This difference in value is what caused XJTAG to report the error.

The next step is to determine (possibly meaning you have to look at the state of all the OTHER pins in the block) whether that pin should be outputting or inputting in the state described by that row of the output text.  And here is the important bit: If the pin is an output in the row you’re looking at, the value in the W (write) column is the value that XJTAG expects the logic block to be driving. It’s not the value driven by JTAG. However, all R (read) values in the data are values actually read by JTAG devices.

Now, if the pin in question is an input, then the “write” value is set from a JTAG device, so the fault is most likely to be on that pin’s net – perhaps an open circuit on one of the JTAG pins or links/resistors/connections, perhaps a short to power/ground.

However, if the pin in question is an output, the “write” value on that net is an assumption because that value is assumed to be driven by the logic block – we have no direct observation of it. So, the fault may be on that net (open circuit, short to power/ground…) but it is also possible that the block is not driving the expected value (ie there’s a fault on one of the input nets or the wrong chip is fitted, etc). I’m afraid at this point XJTAG can’t tell you any more, you’ll have to figure it out! Some of the possibilities are easier to check than others, so go for those first.

We decided a long time ago that XJTAG should support “simple” logic devices in such a way that the logic is handled transparently when it comes to XJEase code, thus allowing the Test Device code to remain device-centric. We also decided that the built-in connection test had to support logic devices to the same extent. The work was on-going behind the scenes here at XJTAG for some time, and is a major part of the version 2.4 release.

So, in previous versions of XJEase if you had a memory chip with a data bus which was accessed through a buffer, you had to modify the chip’s device file so that the data bus pins were actually the buffer inputs rather than the chip’s own data pins. This will still work… but it’s no longer necessary – XJTAG will now realise (for example) that if you want to write to a particular pin on that data bus then it means setting the appropriate buffer direction, enable and input pins, and that if you later want to read the pin, XJTAG will stop driving the buffer, change the buffer’s direction and then read the value through from the memory.

Limitations

No Logic with State

XJTAG  version 2.4 does not support logic with state.  This does not only apply to individual gates – we also do not support the situation where blocks are combined to store state, for example constructing a flip-flop from NAND gates. XJTAG will attempt to spot such situations and object to them… but if you manage to be more cunning than our compile-time state detection algorithms it still won’t work correctly at runtime!

Wind-up of logic blocks

When you make SET statements in XJEase you are asking XJTAG to put the circuit in a state and leave it that way until told to do otherwise.  And with logic that gets complicated. For example, imagine a logic device with 2 outputs and a truth table set up such that they can’t both output a 1 (ie valid output states are 00, 01, 10 only). The user makes a SET statement that sets the first one high. Fine so far. But then later the user SETs the 2nd one high. Now we have a dilemma. Should we refuse? Or should we set the first one back low in order to comply with the 2nd request? The problem would be worse if there were 3 outputs and any two could be high – which one should we set back low in order to set the 3rd one high?

Because we can’t know what the user actually wants, we will stop and show an error if this situation arises. In general that’s easy for you to get around because having SET a value on a pin, you can always SET a different value on it – so you can SET the first pin back low once you’re done with it (or as you SET the 2nd one high)

If the situation gets far too complicated for you to work out what is causing the conflict, which may mean the SET causing the problem was made in some other test a long way from where you are, then we do have a (slightly drastic) get-out, which is to make a  SAFE; statement in your code. This resets all pins (and logic blocks) in the circuit to their default state.

We hope that the new logic features in XJTAG are useful to you – please give us feedback if you feel you have a situation that we should support and don’t, or if you have further suggestions as to how we can improve the products.