XJTAG 3.3 Release Notes
New features and enhancements
Please see the Change Log for a list of new features and enhancements in XJTAG 3.3.
XJEase
The XJEase compiler has been rewritten and as a result there are a number of minor changes or improvements in behaviour.
Error when there is a mismatch for the width of a function parameter between definitions
It is now an error if a function’s forward declaration defines a different width for one of its parameters to the function definition. This includes the case where one definition has a width and the other doesn’t.
This code now produces two errors, one because x has no width specified in the declaration but has one in the definition, and a second because the widths of y differ.
DECLARE Function(INT x, INT y WIDTH 16)(); // ... Function(INT x WIDTH 8, INT y WIDTH 8)() // ... END;
LOCAL functions with the same name as INTERNAL/GLOBAL functions in device files
Previous versions of XJTAG incorrectly allowed a LOCAL function in a device additional code file to have the same name as another INTERNAL or GLOBAL function in a different device additional code file or in the device file preamble. This is now an error.
FWRITE with write-only files
There was a bug in how FWRITE behaved with write-only files, i.e. those opened passing “w” or “a” as the mode to FOPEN. Existing data could be lost in two situations:
- Overwriting existing data when the file was opened for writing, when the write was not writing values smaller than 32 bits or the write was not byte aligned.
- Appending data to the file when the end of the file was not byte aligned and a seek had been performed back to an earlier point in the file.
In both these cases existing data within the 32 bit word surrounding the value that was written could be zeroed out.
Invalid arguments to PRINT_FORMAT
Additional parser checking has been added to the arguments in PRINT_FORMAT, so now there will be warnings output at run-time where before it would have printed the text with the invalid formatting arguments ignored.
GET_PIN_STRING_INFO deprecated
GET_PIN_STRING_INFO is now deprecated and will generate a warning. Use GET_PIN_INFO instead.
Comparisons on strings
Previous versions of XJTAG had incorrectly implemented comparison operators (<, <=, >, >=) on STRING values, by treating the bytes of the string as an integer. This meant that longer strings would always be considered to be greater than shorter strings no matter what characters were in the two strings. When strings are the same length, the ASCII values of the characters were used for the comparison, meaning that comparisons are case sensitive. These strings would be in ascending order:
A, B, a, b, AA, bb
The comparison operators now compare character by character, and only if all the characters match does the length come into play. The sort order is now:
A, AA, B, a, b, bb
Note that comparisons are done on the ASCII byte value of each character so capital letters are always sorted before lower case letters. Internally, XJTAG uses UTF-8 for its string representation, so non-ASCII characters in a string will not sort in a particularly intuitive way.
Character selections on constant strings fixed
It was discovered that previous versions of XJTAG handled multiple character selections on strings differently depending on whether the string was a constant or not. For example, the two PRINT statements below would print two different values:
STRING s := "12345";
PRINT(s[4,1..0], "\n");
PRINT("12345"[4,1..0], "\n");
The first is evaluated at run-time, but since the value and its arguments in the second case are all constant, it is evaluated at compile-time. In v3.3, the compile-time case now evaluates in the same order as the run-time case.
Handling of CHAR(0) made consistent
It was discovered that previous versions of XJTAG were inconsistent in their handling of CHAR(0), sometimes resulting in an empty string and sometimes a single character string containing the ‘nul’ character. The behaviour has now been made consistent, and CHAR(0) always returns a string containing a ‘nul’ character.
The following code:
STRING s := CHAR(0);
PRINT("WIDTHOF(CHAR(0)): ", WIDTHOF(CHAR(0)), "\n");
PRINT("WIDTHOF(x): ", WIDTHOF(x), "\n");
used to print:
WIDTHOF(CHAR(0)): 1 WIDTHOF(x): 0
It now prints 1 for the width in both cases.
Strings containing nul characters
Strings containing nul characters (ASCII 0) are now printed in their entirety. Previous versions would interpret the nul character as the end of the string.
Runtime error if an integer shift larger than 2^32 is attempted
Previously if a number was attempted to be shifted left or right by a number greater than 2^32, then the shift value was silently truncated to 32 bits. A runtime error is now generated. XJEase had always displayed an error at compile-time if the shift value was a constant and greater than 2^32.
CHECKCHAIN inside HOLDOFF blocks
Previous versions of XJTAG erroneously allowed a call to CHECKCHAIN inside a HOLDOFF block. HOLDOFF blocks may only contain functions that write to the JTAG chain and not read from it, so CHECKCHAIN can not be allowed.
CONNTEST inside HOLDOFF blocks and raw JTAG blocks
Previous versions of XJTAG erroneously allowed a call to CONNTEST inside a HOLDOFF block or a raw JTAG block. HOLDOFF blocks may only contain functions that write to the JTAG chain and not read from it, so CONNTEST can not be allowed. Raw JTAG blocks cannot contain functions that access the JTAG chain apart from the raw JTAG functionality, since there is no guarantee about what state the chain will be in.
CONNTEST_RESULT inside raw JTAG blocks
Previous versions of XJTAG erroneously disallowed a call to CONNTEST_RESULT inside a raw JTAG block. Since CONNTEST_RESULT does not actually access the JTAG chain, there is no reason not to allow it inside a raw JTAG block.
RUNSTAPL inside HOLDOFF blocks
Previous versions of XJTAG erroneously allowed a call to RUNSTAPL inside a HOLDOFF block. HOLDOFF blocks may only contain functions that write to the JTAG chain and not read from it, so RUNSTAPL can not be allowed.
RUNSVF inside HOLDOFF blocks
Previous versions of XJTAG erroneously allowed a call to RUNSVF inside a HOLDOFF block. HOLDOFF blocks may only contain functions that write to the JTAG chain and not read from it, so RUNSVF can not be allowed.
XJRunner log file header changes
The user-defined header for the log file used to be generated before testing started, so did not reflect any generated serial number (via the %{Serial} format) nor the correct pass/fail status (the %{PassFail} format). The generated header was also printed to the output window at the start of testing. In addition, if serial numbering was enabled, any generated serial number was printed in the log file above the header.
The header is now correctly generated at the end of testing and inserted into the log file. It is no longer printed to the output window. In addition, if serial numbering is enabled, the serial number is reported, but after the user-defined header. The system also now adds a carriage return after the user-defined header if one is not present.
In some cases a second header that delimits where the test system output starts was omitted. This is now always included.
Maintenance Licensing
With XJTAG 2.4.9, the system now checks the maintenance status of the XJLink, and will not allow XJTAG releases available after maintenance has expired to run.
Supported Platforms
XJTAG is supported on both the 32 and 64 bit variants of the following operating systems: Windows XP® Service Pack 3, Windows Vista® Service Pack 1 or 2, Windows 7® Service Pack 1, Windows 8®, Windows 8.1® and Windows 10®. Please upgrade to one of these operating systems before attempting to install XJTAG, and then apply the latest Service Pack for your operating System. Service Packs are available from the Microsoft Support website.
Support for Windows 2000 was dropped in version 2.4.
XJTAG recommends a screen resolution of at least 1024×768.
Target Hardware
In order for XJTAG to interact with a circuit, the JTAG chain must be set up properly. To help with this, we have a produced a set of DFT guidelines. There is also a troubleshooting section in the help files.
Side-by-side installations
It is only possible to have one instance of each major release of XJTAG installed. It is possible, for example, to install any variant of version 2.5.x along side any variant of version 2.6.y; however it is not possible to install two variants of version 2.5, e.g. 2.5.6 and 2.5.7.
In order to allow users of the XJRunner COM interface to upgrade XJTAG without having to recompile their applications, the GUID for this component of XJTAG does not change with each major version of XJTAG.
Consequences: To use the XJIntegration COM object in side-by-side installations the correct version of the library must be selected when switching between versions. The Version Checker utility (XJVersion) that comes with XJTAG allows the registered version of the XJIntegration to be switched between installed versions.
Changing Project File Associations
By default, double-clicking on an XJTAG project file of any kind will open it in the most recently installed version of XJTAG. The Version Check utility (XJVersion) can be used to control these file associations. It is recommended to do this using the copy installed with the latest version of XJTAG that you have installed.
Previous versions
3.2 | 3.1 | 3.0 | 2.7 | 2.6 | 2.5 | 2.4 | 2.3 | 2.2 | 2.1 | 2.0 | 1.4
We welcome any suggestions for improving our products. Please contact us with any comments you may have and we will look into incorporating your ideas into a future version.
