Not too sure if this is the correct forum for this thread, but as the problem is with debugging the 6455 this will do for a start.
We've recently respun our baseband board, and one of the changes was to include the XIO2001 in the JTAG chain. The chain now consists of a Xilinx ZYNQ Device (PS & PL as far as the JTAG chain is concerned), the 6455, and the XIO2001, in that order. With the previous spin we just had the ZYNQ and the 6455. Previously, using CCSV5 and the Blackhawk LAN560 I could happily run the emulator to load code, debug etc. But with the new configuration I get a "-232" error. I've modified the .ccxml file that is in use to add a bypass entry for the XIO2001 (5 bits), it already had bypass entries for the ZYNQ (4 & 6 bits).
CCSV5 is less than helpful with details of the problem, but using the dbgjtag utility I see:
======================================8< 8< 8<=============================================================
-----[Print the reset-command software log-file]-----------------------------
This utility has selected a 560-class product.
This utility will load the program 'bh560eth.out'.
The library build date was 'Jan 3 2011'.
The library build time was '22:36:59'.
The library package version is '5.0.281.0'.
The library component version is '35.34.29.0'.
The controller does use a programmable FPGA.
The old VHDL code has a version number of '0' (0x00000000).
The new VHDL code has a version number of '386336272' (0x17070610).
The controller has a version number of '5' (0x00000005).
The controller has an insertion length of '0' (0x00000000).
The cable+pod has a version number of '6' (0x00000006).
The cable+pod has a capability number of '8' (0x00000008).
This utility will now attempt to reset the controller.
This utility has successfully reset the controller.
-----[Print the reset-command hardware log-file]-----------------------------
The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the Nano-TBC VHDL.
The link is a 560-class version-D multi-purpose cable.
The software is configured for Nano-TBC VHDL features.
The controller will be software reset via its registers.
The controller has a logic ONE on its EMU[0] input pin.
The controller has a logic ONE on its EMU[1] input pin.
The controller will use rising-edge timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '3' (0x0003).
The utility logic has not previously detected a power-loss.
The utility logic is not currently detecting a power-loss.
-----[The log-file for the JTAG TCLK output generated from the PLL]----------
Test Size Coord MHz Flag Result Description
~~~~ ~~~~ ~~~~~~~ ~~~~~~~~ ~~~~ ~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
1 none - 01 00 500.0kHz - similar isit internal clock
2 none - 01 09 570.3kHz {-} similar isit internal clock
3 512 - 01 00 500.0kHz {#} bad command measure path length
In the first internal/external clock test:
The expect frequency was 500000Hz.
The actual frequency was 499110Hz.
The delta frequency was 890Hz.
In the second internal/external clock test:
The expect frequency was 570312Hz.
The actual frequency was 569214Hz.
The delta frequency was 1098Hz.
In the scan-path tests:
The test length was 16384 bits.
The JTAG IR length was 0 bits.
The JTAG DR length was 0 bits.
The IR/DR scan-path tests used 3 frequencies.
The IR/DR scan-path tests used 500.0kHz as the initial frequency.
The IR/DR scan-path tests used 570.3kHz as the highest frequency.
The IR/DR scan-path tests used 500.0kHz as the final frequency.
-----[Measure the source and frequency of the final JTAG TCLKR input]--------
The frequency of the JTAG TCLKR input is measured as 499.1kHz.
The frequency of the JTAG TCLKR input and TCLKO output signals are similar.
The target system likely uses the TCLKO output from the emulator PLL.
-----[An error has occurred and this utility has aborted]--------------------
This error is generated by TI's USCIF driver.
The value is '-232' (0xffffff18).
The title is 'SC_ERR_PATH_DR_MEASURE'.
The explanation is:
The measured length of the JTAG DR data path is invalid.
This indicates that an error exists in the link-delay or scan-path.
======================================8< 8< 8<=============================================================
Note, that this is running at the minimum speed of 0.5 MHz. We have tested 2 boards and have seen the problem with both.
Our design allows us to bypass the XIO2001 by connecting its TDI line to its TDO line, and isolating those lines from the device. If we do this (and modify the ccxml file to remove its bypass entry) everything is happy, and we can run at the maximum rate of 35 MHz. Nothing was modified on the TCK or RTCK paths.
We can use the JTAG in the original configuration (with the XIO2001 present) to run boundary scan tests with a JTAGLive pod. Also a Xilinx Platform Cable USB II pod will quite happily load the ZYNQ PL via vivado, it sees the 4 devices (ZYNQ PS and PL, unknown device - presumably the 6455, and unknown device - presumably the XIO2001), the IR lengths that it discovers for all 4 devices being correct.
The dbgjtag utility reports "This error is generated by TI's USCIF driver." But I can find no information about the USCIF driver, googling for it just gives me heaps and heaps of pages of people reporting errors of various codes, no -232s though as far as I can see.
I have also tried a Blackhawk USB510L JTAG Emulator and that gives the same "-232" error.
I've talked to Blackhawk about the problem, and after running some tests for them they seem to think that we have a physical issue (signal integrity, propagation delays, impedance or wrong series resistor values). However that doesn't feel correct to us, with the XIO2001 bypassed we can run at full rate (35 MHz), while with it in the chain it fails at a modest 0.5 MHz. It feels to us that the XIO2001 is not responding as the TI's USCIF driver expects.
Can anyone shed any light on my problem
best regards
Paul Bray
