CCS/CCSTUDIO: C55xx: Error connecting to the target: (Error -151 @ 0x0)

Hi Charles.

Charles Manning said:

I am using CCS5.4.0 on Linux with an Olimex XDS1000V3 and a custom board with a 5535.

CCS 5.4 is quite old and unsupported. Any reason why you need to stay on this old version?

Also, what Linux distro are you running CCS on.

Charles Manning said:

I have used the connectivity test tool and that works fine.

Are you referring to the xds100serial utility? Or the JTAG connectivity test tool in CCS? Regardless, can you prove the results of the test?

Thanks

ki

Yes, I do understand that this is old, but this is what the project is already set up to use.

I am using Ubuntu 18.04

I ran both those tests and they are fine. It is only running the debugger that gives a problem.

$ ./ccs_base/common/uscif/xds100serial
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
Scanning for XDS100 emulators...

VID/PID    Type            Serial #    Description
0403/a6d1  XDS100v3        FT4XK52W    Texas Instruments XDS100 Ver 3.

$ echo $?
0

[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)]------------------------------------

/home/charles/.TI/1524211065/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 'libjioserdesusbv3.so'.
The library build date was 'Apr  2 2013'.
The library build time was '01:37:27'.
The library package version is '5.1.73.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]----------

  Test  Size   Coord      MHz    Flag  Result       Description
  ~~~~  ~~~~  ~~~~~~~  ~~~~~~~~  ~~~~  ~~~~~~~~~~~  ~~~~~~~~~~~~~~~~~~~
    1    512  - 01 00  500.0kHz   O    good value   measure path length
    2    512  + 00 00  1.000MHz  [O]   good value   apply explicit tclk

There is no hardware for measuring the JTAG TCLK frequency.

In the scan-path tests:
The test length was 16384 bits.
The JTAG IR length was 38 bits.
The JTAG DR length was 1 bits.

The IR/DR scan-path tests used 2 frequencies.
The IR/DR scan-path tests used 500.0kHz as the initial frequency.
The IR/DR scan-path tests used 1.000MHz as the highest frequency.
The IR/DR scan-path tests used 1.000MHz as the final 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]

Charles Manning said:

Yes, I do understand that this is old, but this is what the project is already set up to use.

I am using Ubuntu 18.04

Note that CCS v5.x is not officially supported on Ubuntu 18.04. 

Surprised to hear that the JTAG connectivity test passes but you are getting that -151 host connection error. Have you been able to use that Olimex XDS100v3 probe successfully at all in the past with this environment?

Thanks

ki

I have never used the Olimex of a C55x before.

I do also have an EZDSP and that works a bit better.

I am trying to migrate to the a new CCS. I am trying 10.10 but I am having other issues (tconf not found)

Can you please suggest:

1) Which is the best CCS version for me to be using for C55x with Linux?

2) Where I can find a how-to document that takes me through the process?

Thanks

Charles Manning said:

1) Which is the best CCS version for me to be using for C55x with Linux?

Normally we would recommend using the most recent version of CCS. Note that you will need to download the C55x compiler separately (from the App Center) since later versions of CCS does not ship with it.

One potential issue is that DSP/BIOS support has been deprecated. There is no DSP/BIOS RTA support in later versions of CCS. If that is not a concern, then I would recommend the latest version of CCS

Charles Manning said:

2) Where I can find a how-to document that takes me through the process?

There is not any migration document from moving from v5 -> v10. However, the migration should be fairly straight forward. The only issue is needing to manually install the compiler and the DSP/BIOS deprecated support. Please see my reply to your other thread regarding xdctools and tconf.

Thanks

ki

Thank you for that info

If DSP/BIOS has been depricated then what replaces it?

My intention is to migrate to a newer toolset and if DSP/BIOS is part of the old toolchain then it quite likely makes sense to migrate off that.

Are there some "Howtos"/example projects to facilitate this? In addition to custom hardware I also have an EZDSP 5535. Is there a document describing how to use something like this with the new toolchains?

Thanks

Charles

Charles Manning said:

If DSP/BIOS has been depricated then what replaces it?

SYS/BIOS. However, it is not supported on C55x. You will likely need to stay on DSP/BIOS. 

Charles Manning said:

Are there some "Howtos"/example projects to facilitate this? In addition to custom hardware I also have an EZDSP 5535. Is there a document describing how to use something like this with the new toolchains?

This is a question best suited to the device experts. I suggest starting a new thread in the Processors forum.

Thanks

ki