• Locked Locked
  • Replies 17 replies
  • Subscribers 54 subscribers
  • Views 3638 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS v5.5.0 cannot connect XDS100v1 on Experimenter Kit F28335

Robert W
Mastermind 7100 points

Other Parts Discussed in Thread: AM3358, TMS320VC5505

Hi, 

I have a PC installed CCS v5.5.0 on Windows 7, 64 bits. It cannot pass connection test with Experimenter Kit F28335. It always stops at the same test pattern, see below please. I have tried to change (lower) the clock frequency of XDS100 v1 settings several times. It doesn't work. This PC is about 2 and half years old, AMD CPU.

On the contrary, another DELL new i7 PC (Windows 8, 64 bit) can pass the test, but I would use the old AMD PC for the F28335 project. 

Anyone can help diagnose the problem? Thanks a lot.

.............

[Start]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

[Result]


-----[Print the board config pathname(s)]------------------------------------

C:\Users\Jeff\AppData\Local\.TI\693494126\
    0\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 100- or 510-class product.
This utility will load the adapter 'jioserdesusb.dll'.
The library build date was 'Aug 20 2013'.
The library build time was '22:56:19'.
The library package version is '5.1.232.0'.
The library component version is '35.34.40.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '4' (0x00000004).
The controller has an insertion length of '0' (0x00000000).
This utility will 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 FTDI FT2232 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for FTDI FT2232 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).

-----[The log-file for the JTAG TCLK output generated from the PLL]----------

There is no hardware for programming the JTAG TCLK frequency.

-----[Measure the source and frequency of the final JTAG TCLKR input]--------

There is no hardware for measuring the JTAG TCLK frequency.

-----[Perform the standard path-length test on the JTAG IR and DR]-----------

This path-length test uses blocks of 512 32-bit words.

The test for the JTAG IR instruction path-length succeeded.
The JTAG IR instruction path-length is 38 bits.

The test for the JTAG DR bypass path-length succeeded.
The JTAG DR bypass path-length is 1 bits.

-----[Perform the Integrity scan-test on the JTAG IR]------------------------

This test will use blocks of 512 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.

The JTAG IR Integrity scan-test has succeeded.

-----[Perform the Integrity scan-test on the JTAG DR]------------------------

This test will use blocks of 512 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.

  • Mastermind 7100 points

    I make it clear to previous post. The test is always not finished. The test should be finished with a succeed line.

    When I use it in debug, it also has connection problems now and then.

  • in reply to Robert W
    Guru 192875 points

    Hi Robert,

    Please check your device manager. Are the XDS100 drivers installed properly?

    Regards,

    Gautam

  • in reply to Gautam Iyer
    Mastermind 7100 points

    Hi,

    The AMD PC previously was used to connect AM3358 Starter Kit, which has XDS100v2. It still work well with AM3358 SK.

    I can see the USB serial port added when I connect F28335 Experimenter Kit. I don't know why it does not finish the test yet. Any other way to check device manager?

    Thanks,

  • in reply to Gautam Iyer
    Mastermind 7100 points

    The phenomenon is that the test stuck at the last test line. When I turn off the Experimenter Kit, the test message will finish, see below please. But the normal debug still does not work yet.

    ......

    [Start]

    Execute the command:

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

    [Result]


    -----[Print the board config pathname(s)]------------------------------------

    C:\Users\Jeff\AppData\Local\.TI\693494126\
        0\0\BrdDat\testBoard.dat

    -----[Print the reset-command software log-file]-----------------------------

    This utility has selected a 100- or 510-class product.
    This utility will load the adapter 'jioserdesusb.dll'.
    The library build date was 'Aug 20 2013'.
    The library build time was '22:56:19'.
    The library package version is '5.1.232.0'.
    The library component version is '35.34.40.0'.
    The controller does not use a programmable FPGA.
    The controller has a version number of '4' (0x00000004).
    The controller has an insertion length of '0' (0x00000000).
    This utility will 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 FTDI FT2232 with USB interface.
    The link from controller to target is direct (without cable).
    The software is configured for FTDI FT2232 features.
    The controller cannot monitor the value on the EMU[0] pin.
    The controller cannot monitor the value on the EMU[1] pin.
    The controller cannot control the timing on output pins.
    The controller cannot control the timing on input pins.
    The scan-path link-delay has been set to exactly '0' (0x0000).

    -----[The log-file for the JTAG TCLK output generated from the PLL]----------

    There is no hardware for programming the JTAG TCLK frequency.

    -----[Measure the source and frequency of the final JTAG TCLKR input]--------

    There is no hardware for measuring the JTAG TCLK frequency.

    -----[Perform the standard path-length test on the JTAG IR and DR]-----------

    This path-length test uses blocks of 512 32-bit words.

    The test for the JTAG IR instruction path-length succeeded.
    The JTAG IR instruction path-length is 38 bits.

    The test for the JTAG DR bypass path-length succeeded.
    The JTAG DR bypass path-length is 1 bits.

    -----[Perform the Integrity scan-test on the JTAG IR]------------------------

    This test will use blocks of 512 32-bit words.
    This test will be applied just once.

    Do a test using 0xFFFFFFFF.
    Scan tests: 1, skipped: 0, failed: 0
    Do a test using 0x00000000.
    Scan tests: 2, skipped: 0, failed: 0
    Do a test using 0xFE03E0E2.
    Scan tests: 3, skipped: 0, failed: 0
    Do a test using 0x01FC1F1D.
    Scan tests: 4, skipped: 0, failed: 0
    Do a test using 0x5533CCAA.
    Scan tests: 5, skipped: 0, failed: 0
    Do a test using 0xAACC3355.
    Scan tests: 6, skipped: 0, failed: 0
    All of the values were scanned correctly.

    The JTAG IR Integrity scan-test has succeeded.

    -----[Perform the Integrity scan-test on the JTAG DR]------------------------

    This test will use blocks of 512 32-bit words.
    This test will be applied just once.

    Do a test using 0xFFFFFFFF.
    Scan tests: 1, skipped: 0, failed: 0
    Do a test using 0x00000000.
    Scan tests: 2, skipped: 0, failed: 0
    Do a test using 0xFE03E0E2.
    Scan tests: 3, skipped: 0, failed: 0
    Do a test using 0x01FC1F1D.
    Scan tests: 4, skipped: 0, failed: 0
    Do a test using 0x5533CCAA.
    Scan tests: 5, skipped: 0, failed: 0
    Do a test using 0xAACC3355.
    Scan tests: 6, skipped: 0, failed: 0
    All of the values were scanned correctly.

    The JTAG DR Integrity scan-test has succeeded.

    [End]

     

  • in reply to Robert W
    Mastermind 7100 points

    Excuse me. I forgot to say that the JTAG CLK frequency is 100KHz in last post.

    For default JTAG CLk (1 MHz), it still does not finish even after turn off the kit.

  • in reply to Robert W
    Guru 192875 points

    Robert, F28335 Experimenter's kit has a XDS100v2 and not XDS100v1. Can you once check by modifying your target configuration to XDS100v2?

    Regards,

    Gautam

  • in reply to Gautam Iyer
    Mastermind 7100 points

    Hi,

    I have tried XDS100v2. The problem is still there for the default JTAG CLK configuration. Or JTAG CLK is set to fixed CLK frequency (100K, 500K, 1MHz) Test connection only shows:

    [Start]

    Execute the command:

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

    [Result]


    -----[Print the board config pathname(s)]------------------------------------

    C:\Users\Jeff\AppData\Local\.TI\693494126\
        0\0\BrdDat\testBoard.dat

    -----[Print the reset-command software log-file]-----------------------------

    This utility has selected a 100- or 510-class product.
    This utility will load the adapter 'jioserdesusb.dll'.
    The library build date was 'Aug 20 2013'.
    The library build time was '22:56:19'.
    The library package version is '5.1.232.0'.
    The library component version is '35.34.40.0'.
    The controller does not use a programmable FPGA.
    The controller has a version number of '4' (0x00000004).
    The controller has an insertion length of '0' (0x00000000).

    When it is set adaptive JTAG CLK to 1K, 100K, 500KHz, it gives more info but still not finished.

    [Start]

    Execute the command:

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

    [Result]


    -----[Print the board config pathname(s)]------------------------------------

    C:\Users\Jeff\AppData\Local\.TI\693494126\
        0\0\BrdDat\testBoard.dat

    -----[Print the reset-command software log-file]-----------------------------

    This utility has selected a 100- or 510-class product.
    This utility will load the adapter 'jioserdesusb.dll'.
    The library build date was 'Aug 20 2013'.
    The library build time was '22:56:19'.
    The library package version is '5.1.232.0'.
    The library component version is '35.34.40.0'.
    The controller does not use a programmable FPGA.
    The controller has a version number of '4' (0x00000004).
    The controller has an insertion length of '0' (0x00000000).
    This utility will 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 FTDI FT2232 with USB interface.
    The link from controller to target is direct (without cable).
    The software is configured for FTDI FT2232 features.
    The controller cannot monitor the value on the EMU[0] pin.
    The controller cannot monitor the value on the EMU[1] pin.
    The controller cannot control the timing on output pins.
    The controller cannot control the timing on input pins.
    The scan-path link-delay has been set to exactly '0' (0x0000).

    -----[The log-file for the JTAG TCLK output generated from the PLL]----------

    There is no hardware for programming the JTAG TCLK frequency.

    -----[Measure the source and frequency of the final JTAG TCLKR input]--------

    There is no hardware for measuring the JTAG TCLK frequency.

    -----[Perform the standard path-length test on the JTAG IR and DR]-----------

    This path-length test uses blocks of 512 32-bit words.

    The test for the JTAG IR instruction path-length succeeded.
    The JTAG IR instruction path-length is 38 bits.

    The test for the JTAG DR bypass path-length succeeded.
    The JTAG DR bypass path-length is 1 bits.

    -----[Perform the Integrity scan-test on the JTAG IR]------------------------

    This test will use blocks of 512 32-bit words.
    This test will be applied just once.

    Do a test using 0xFFFFFFFF.
    Scan tests: 1, skipped: 0, failed: 0
    Do a test using 0x00000000.
    Scan tests: 2, skipped: 0, failed: 0
    Do a test using 0xFE03E0E2.
    Scan tests: 3, skipped: 0, failed: 0
    Do a test using 0x01FC1F1D.
    Scan tests: 4, skipped: 0, failed: 0
    Do a test using 0x5533CCAA.
    Scan tests: 5, skipped: 0, failed: 0
    Do a test using 0xAACC3355.
    Scan tests: 6, skipped: 0, failed: 0
    All of the values were scanned correctly.

    The JTAG IR Integrity scan-test has succeeded.

    -----[Perform the Integrity scan-test on the JTAG DR]------------------------

    This test will use blocks of 512 32-bit words.
    This test will be applied just once.

    Do a test using 0xFFFFFFFF.
    Scan tests: 1, skipped: 0, failed: 0
    Do a test using 0x00000000.
    Scan tests: 2, skipped: 0, failed: 0
    Do a test using 0xFE03E0E2.
    Scan tests: 3, skipped: 0, failed: 0
    Do a test using 0x01FC1F1D.
    Scan tests: 4, skipped: 0, failed: 0
    Do a test using 0x5533CCAA.
    Scan tests: 5, skipped: 0, failed: 0
    Do a test using 0xAACC3355.

    From previous experience with XDS100, it seems that it cares about slow PC speed. But for this not too old PC (2 more years old), it should not be a problem. BTW, this PC works well with other TI EVM with the same XDS100v2 (Sitara SK, eZDSP 5535 kit).

    Any clue with specific to F28335 Experimenter Kit different from the above two Kits?

    Thanks,

  • in reply to Robert W
    TI__Guru 57255 points

    Robert,

    The F28335 Experimenter's Kit actually does have an xds100v1.

    I am going to move this to the CCS forum to see if they have any ideas.  My assumption is that this is some type of driver issue, but I cannot be sure.


    Thank you,
    Brett

  • in reply to Robert W
    Guru 92251 points

    Robert W said:
    The phenomenon is that the test stuck at the last test line. When I turn off the Experimenter Kit, the test message will finish, see below please. But the normal debug still does not work yet.

    I have noticed similar problems on my main development PC running Windows XP 32-bit when using boards with built in XDS100v1  emulators. Whereas on the same PC boards with built in XDS100v2 emulators don't suffer the hangs / debug problems. 

    On a slower notebook also running Windows XP 32-bit both the XDS100v1 and XDS200v2 emulators don't show the hangs / debug problems.

    Never got around to diagnosing why the XDS100v1 has problems on one PC, but wondering if enabling debug server logging, or any other logging could be used to track down the problem?

  • in reply to Chester Gillon
    TI__Guru**** 486331 points

    Chester Gillon said:
    Never got around to diagnosing why the XDS100v1 has problems on one PC, but wondering if enabling debug server logging, or any other logging could be used to track down the problem?

    Yes, please. Robert, please reproduce the issue while generating a debug server log. Zip it up and attach it to this thread.

    http://processors.wiki.ti.com/index.php/Troubleshooting_CCSv5#Debug_Server_Logging

    Thanks

    ki

  • in reply to Ki
    Mastermind 7100 points

    Hi,

    I enable the debug server logging dump as in your link. This is the screen shot of that settings:

    I create a XDS100v1 target file. Then, I run test connection. It stops at:

    [Start]

    Execute the command:

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

    [Result]


    -----[Print the board config pathname(s)]------------------------------------

    C:\Users\Jeff\AppData\Local\.TI\693494126\
        0\0\BrdDat\testBoard.dat

    -----[Print the reset-command software log-file]-----------------------------

    This utility has selected a 100- or 510-class product.
    This utility will load the adapter 'jioserdesusb.dll'.
    The library build date was 'Aug 20 2013'.
    The library build time was '22:56:19'.
    The library package version is '5.1.232.0'.
    The library component version is '35.34.40.0'.
    The controller does not use a programmable FPGA.
    The controller has a version number of '4' (0x00000004).
    The controller has an insertion length of '0' (0x00000000).

    The only operation I can do is to turn off the Experimenter Kit now. Then, the message in Test Connection window is:

    [Start]

    Execute the command:

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

    [Result]


    -----[Print the board config pathname(s)]------------------------------------

    C:\Users\Jeff\AppData\Local\.TI\693494126\
        0\0\BrdDat\testBoard.dat

    -----[Print the reset-command software log-file]-----------------------------

    This utility has selected a 100- or 510-class product.
    This utility will load the adapter 'jioserdesusb.dll'.
    The library build date was 'Aug 20 2013'.
    The library build time was '22:56:19'.
    The library package version is '5.1.232.0'.
    The library component version is '35.34.40.0'.
    The controller does not use a programmable FPGA.
    The controller has a version number of '4' (0x00000004).
    The controller has an insertion length of '0' (0x00000000).
    This utility will 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 FTDI FT2232 with USB interface.
    The link from controller to target is direct (without cable).
    The software is configured for FTDI FT2232 features.
    The controller cannot monitor the value on the EMU[0] pin.
    The controller cannot monitor the value on the EMU[1] pin.
    The controller cannot control the timing on output pins.
    The controller cannot control the timing on input pins.
    The scan-path link-delay has been set to exactly '0' (0x0000).

    An error occurred while soft opening the controller.

    -----[An error has occurred and this utility has aborted]--------------------

    This error is generated by TI's USCIF driver or utilities.

    The value is '-151' (0xffffff69).
    The title is 'SC_ERR_FTDI_OPEN'.

    The explanation is:
    One of the FTDI driver functions used during
    the connect returned bad status or an error.
    The cause may one or more of: invalid emulator serial number,
    blank emulator EEPROM, missing FTDI drivers, faulty USB cable.
    Use the xds100serial command-line utility in the 'common/uscif'
    folder to verify the emulator can be located.

    [End]

    I go back to "Coder Composer Studio Support", highlight "Debug Server Dump File" bar, then click View. The folder shows the old dump file.

    What am I wrong?

    Thanks,

  • in reply to Robert W
    TI__Guru**** 486331 points

    Debug server logging applies to a debug session. It won't record anything from the "Test Connection" button. Start a debug session and try to connect to the target.

    Also, I don't see a path specified for log. You may want to specify one.

  • in reply to Ki
    Mastermind 7100 points

    3463.debugdmb.zip

    Here is the log file. The debug can run, but it cannot finish. It stuck there when halt debug process.

  • in reply to Robert W
    TI__Guru**** 486331 points

    Robert W said:
    Here is the log file. The debug can run, but it cannot finish. It stuck there when halt debug process.

    Thanks.

    Is that the main issue you have? That the debugger runs but you cannot halt? The reason I ask is because I thought your original problem was that you cannot connect to the target.

  • in reply to Ki
    Mastermind 7100 points

    Maybe this is the main problem. I forget the beginning syndrome now. I quickly switched to Test Connection. Then, it always does not finish.

  • in reply to Robert W
    Guru 92251 points

    Robert W said:
    Here is the log file. The debug can run, but it cannot finish. It stuck there when halt debug process.

    With a TMS320VC5505 eZDP using the on-board XDS100V1 I get getting a hang when either:

    - Attempted to terminate a debug session. The debug server logging showed the hang was occuring in a call to GTI_QUIT, which is the same as your attached log file.

    - Attempted to test the connection.

    As a work-around I found that once the "hang" had occured, could get the CCS debug session to terminate or the test connection to complete without error by either:

    - In the Windows XP Device Manager performing a "Scan for hardware changes" action.

    - In the Microsoft USB Device Viewer performing a refresh.

    Not sure if the problem is in CCS, the FTDI driver or Windows...

  • in reply to Chester Gillon
    Mastermind 7100 points

    Even for XDS100v2, I find it needs to tweak the JTAG CLK frequency with adaptive mode to find an appropriate value on slower PC. XDS100v1 can work with an i7 PC. It looks like some internal timing/delay related parameters are too narrow for slower PCs.