CCS/LAUNCHXL-CC1352R1: Icepick error during debug session (linux)

Hi,

Sorry, somehow I skipped the part where you were able to connect to the target. One question: when this message is shown, does the debugger still maintain control over the device? Or you need to Terminate or reconnect to the core?

I haven't seen this happen with my CCSv7.4.0/TI Emulators 7.0.100.1 and my XDS110 Debug Probe in Ubuntu 16.04/64 (thus ruling out something intrinsic to this combination), but I would be extremely suspicious of two things:

1) Either flaky connections between the device and the debug probe, which could be responsible for malformed packets of information between the ICEPICK router (a JTAG router inside your device) and the probe. In this case I would thoroughly inspect the connections and their length.

You can also run the low-level utility dbgjtag in repeat mode and move around the cables to see if the connection is broken at a certain point. The command and the results when there are cable breakage are shown at the bottom of this post.

2) The code loaded to the target may be changing the pin assignment of the JTAG pins - that or keeping the device hanging for too long during a peripheral or memory access operation, which can fool the Debug Probe into believing the connection was disrupted. If the code you are debugging on the Mint host is different, that could explain what you are seeing in the Ubuntu host.  If the code is the same, then that theory is not applicable.

At any rate, please give this a try.

Hope this helps,

Rafael

user@host:/opt/CCS_7_4_0/ccsv7/ccs_base/common/uscif$ ./dbgjtag -f @xds110 -rv -o -S brokenpath,repeat=10000

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

xds110.i

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

This utility has selected a 100- or 510-class product.
This utility will load the adapter 'libjioxds110.so'.
The library build date was 'Nov  6 2017'.
The library build time was '10:26:29'.
The library package version is '7.0.100.0'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '5' (0x00000005).
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 XDS110 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for XDS110 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).

-----[Perform the Broken Path scan-test on the JTAG IR]----------------------

This test will use blocks of 64 32-bit words.
This test will be applied 10000 times.

Do a test using 0xFFFFFFFF.
Do a test using 0x00000000.
Test 16777 Word 18: scanned out 0x00000000 and scanned in 0xFFFFFC00.
Test 16777 Word 19: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 16777 Word 20: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 16777 Word 21: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 16777 Word 22: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 16777 Word 23: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 16777 Word 24: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 16777 Word 25: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
The details of the first 8 errors have been provided.
The utility will now report only the count of failed tests.
Some of the values were corrupted - 15.9 percent.

The JTAG IR Broken Path scan-test has failed.

-----[Perform the Broken Path scan-test on the JTAG DR]----------------------

This test will use blocks of 64 32-bit words.
This test will be applied 10000 times.

Do a test using 0xFFFFFFFF.
Do a test using 0x00000000.
Test 10001 Word 0: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 10001 Word 1: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 10001 Word 2: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 10001 Word 3: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 10001 Word 4: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 10001 Word 5: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 10001 Word 6: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 10001 Word 7: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
The details of the first 8 errors have been provided.
The utility will now report only the count of failed tests.
Some of the values were corrupted - 49.2 percent.

The JTAG DR Broken Path scan-test has failed.

Hi,

I dont think its a cable issue as I have actually been using the same board with the same project in windows for quite a while now. Only recently moved to linux. 

Generally the debugger maintains the connection, and I can debug ok. Sometimes it barely happens at all, sometimes it happens every few seconds. 

I have seen once or twice that I paused and the connection was lost, but it doesn't happen that much. 

The broken path tested was succesfull...

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

xds110.i

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

This utility has selected a 100- or 510-class product.
This utility will load the adapter 'libjioxds110.so'.
The library build date was 'Nov 6 2017'.
The library build time was '10:26:29'.
The library package version is '7.0.100.0'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '5' (0x00000005).
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 XDS110 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for XDS110 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).

-----[Perform the Broken Path scan-test on the JTAG IR]----------------------

This test will use blocks of 64 32-bit words.
This test will be applied 1000 times.

Do a test using 0xFFFFFFFF.
Do a test using 0x00000000.
All of the values were scanned correctly.

The JTAG IR Broken Path scan-test has succeeded.

-----[Perform the Broken Path scan-test on the JTAG DR]----------------------

This test will use blocks of 64 32-bit words.
This test will be applied 1000 times.

Do a test using 0xFFFFFFFF.
Do a test using 0x00000000.
All of the values were scanned correctly.

The JTAG DR Broken Path scan-test has succeeded.

Any other ideas?