|
|
|
This chapter is a simple guide to understanding the more common issues you might encounter when configuring CPLDs with JTAG Programmer. These issues are likely to fall into three groups; communication, improper connections, and improper or unstable VCC.
This section describes several issues that involve the integrity of the bitstream that JTAG Programmer transmits to the target CPLDs, and the correct connection of the boundary-scan chain.
This section involves assigning configuration pins to invalid signals or voltage levels.
This section describes several causes of incorrect configuration sequences and incorrect responses from the target system.
If you experience a consistent error that identifies a break in your boundary-scan chain, go to this section.
If you experience intermittant problems characteristic of system noise, go to this section.
Observing the following guidelines should minimize the communication difficulties that can occur between the cable hardware and the target system.
Do not attach extension cables to the target system side of the cable; this can compromise configuration data integrity and cause checksum errors.
Attach the cable configuration leads firmly to the target system.
After connecting the target system, specify the chain configuration using the part command. Then use the "partinfo -id part_name" command to read the IDCODE from each part in the system. This will verify the integrity of the boundary-scan
chain. If you are using the Graphical User Interface:Operations
Get Device ID
Use the verify feature to assure integrity of the configuration data. You can do this from the command line with the -v option or in the interactive mode by specifying the verify command.
When using the JTAG Programmer software with the cable on a PC to download, the process may stop with data communications errors. This is caused by serial port communication inefficiencies in the Windows environment. To set your PC to better handle serial communications at 38400 baud, add (or modify) the following lines to the 386Enh section of your SYSTEM.INI file. This file is located in the Windows directory of your system.COM1Buffer=32768COM2Buffer=32768COMBoostTime=10240
Check the following:
Always make sure that cable leads are connected properly.
Connecting the cable leads to the wrong signal will cause permanent damage to cable internal hardware. On a parallel cable, you must connect VCC to +5 V, +3.3V or +2.5V, and GND to ground. On an XCHecker cable, you can connect VCC directly to 5V and GND to ground, but need an adapter to connect VCC to 3.3V or 2.5V. The part number is HW-XCH3V.
For workstations, you must have read and write permissions to the port to which you connect the cable. JTAG Programmer might issue a message stating that the cable is not connected to port ttyx. When you see this message, follow the check list below:
The board must have the power on, since the cable uses power from the board.
Check the device driver using the following command string:ls -l /dev/ttya /dev/ttybThe result should be the following:crw-rw-rw- 1 root 12,0 month date time /dev/ttyacrw-rw-rw- 1 root 12,1 month date time /dev/ttyb
Reconnect the cable to another valid port.
Read the /etc/ttytab file. There should be two lines, as follows:
ttya ``/usr/etc/getty std.9600'' unknown off local secure
ttyb ``/usr/etc/getty std.9600'' unknown off local secure
If you use a port to connect a modem or a remote login, you cannot use that port. The port must be on. Consult your System Administrator if the information the /etc/ttytab file is different than what is listed in the aforementioned list.
If you are having problems with unstable VCC, try the following:
Never connect the control signals to the cable before VCC and ground. Xilinx recommends the following sequence:
Turn off power to the target system.
Connect VCC ground, and then the signal leads,
Turn on power to the target system.
The XChecker Cable has an internal FPGA. As with any CMOS device, the input/output pins of the internal FPGA should always be at a lower or equal potential than the rail voltage to avoid internal damage.
Make sure VCC rises to a stable level within 10ms. Stable VCC should be between 4.75 V and 5.25 V.
In the event of power glitches, reset the cable by selecting:Output
Cable Reset
If you experience a consistent error that identifies a break in your boundary-scan chain but are unable to identify such a discontinuity then execute the following steps:
Create a command file to be used with the batch version of the JTAG Programmer (jtagprog). In this batch file specify your boundary-scan chain configuration using the part command and about 500 idcode queries as follows:
part xc9572:design72 xc95108:design108
partinfo -id design108
partinfo -id design108
partinfo -id design108
.
.
.
partinfo -id design108
quit
Save the file as test.cmd and then invoke the tool as follows:
jtagprog -batch test
The tool will execute the device id command 500 times before quitting. While this is going on use the oscilloscope to probe the pins of the boundary scan test access port (TAP) at the system entry point and at each individual part.
The boundary scan integrity check sequences the TAP through a TRST sequence (TMS set to 1, TCK pulsed 5 times) and then transitions all devices to the RunTest/Idle state (TMS set to 0, TCK pulsed once). Then, all parts are run through a CAPTURE -IR sequence while TDI is set to 1 (1s will be shifted in). If you look in the device BSDL files you will see the expected capture sequence defined in the "instruction capture" field. For all XC9500/XL/XV parts this sequence is a "1" followed by seven zeros. You should therefore see the "1" on TDO after the falling edge of the 4th TCK pulse after the TRST sequence. On the next TCK pulse TDO should return to zero.
The CAPTURE -IR sequence consists of the following (starting from RunTest/Idle), as illustrated in Figure C-1.
TMS set to 1; TCK pulsed twice.
TMS set to 0; TCK pulsed twice.
TCK pulsed (number of bits in instruction register -1) times.
TMS set to 1; TCK pulsed twice.
TMS set to 0; TCK pulsed once.
Check for the following:
The expected number of TCK pulses occur.
The same TMS sequence occurs for each part.
The TDO is not shorted or floating between parts, or floating at the system interconnect point.
Make certain that all 4 TAP signals are getting into each part (Note that both TDI and TMS have internal pull-ups on them which could keep the device in TRST mode if TMS is not properly connected).
You may also use the Debug Chain dialog and a logic probe or oscilloscope to transition the TAP state machine directly and observe results.
You can check for system noise by running the IDCODE looping instruction. The IDCODE should read correctly 100% of the time. If by test you find that the instruction is working less than 100% of the time, you may be experiencing system noise. To use IDCODE looping:
Operations
Idcode looping
This will display the Edit window. Enter the number of loops you desire and click OK.
To remedy a problem with system noise, select Use HIGHZ instead of BYPASS from the Preferences dialog box. This places devices into tri-state mode and reduces susceptibility to system noise. To find this box use:
File
Preferences
The Preferences dialog box will appear. Place a check in the box adjacent to Use HIGHZ instead of BYPASS.