• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 53 subscribers
  • Views 1387 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/LAUNCHXL-CC1352R1: Icepick error during debug session (linux)

Garry Blair34
Intellectual 410 points
Part Number: LAUNCHXL-CC1352R1

Tool/software: Code Composer Studio

Hi,

During a debug session with the CC1352R1 launchpad I periodically get the error message: 

IcePick_C: Error: (Error -261 @ 0xFFFFFEFB) Invalid response was received from the XDS110. (Emulation package 7.0.100.1) 

I am not using IcePick as far as I know (in the debug config it is written as Cortex_M4_0. I can fully debug the device, but when it shows this error code composer freezes for a few seconds which makes it a bit hard to work with. 

Would appreciate some help with this

Thanks

  • 0
    TI__Guru**** 171094 points
    Hi,

    Unfortunately I don't have such development board with me to test this, but this error is quite unusual and was reported only a handful of times with no conclusive answers.

    e2e.ti.com/.../516745
    e2e.ti.com/.../484513
    e2e.ti.com/.../2274843

    If this were a Windows host, I would suggest to close the SmartRF Flash programmer, but being in Linux I would double check if no other instance of CCS is running. Also, double-check if the install_drivers script was run after CCS install. Details at:
    processors.wiki.ti.com/.../Linux_Host_Support_CCSv7

    I will try to find additional relevant threads and report back.

    Hope this helps,
    Rafael
  • 0 in reply to desouza
    Intellectual 410 points
    Hi,

    I installed the drivers as in the link you sent me already. Like I said the debug session runs ok, occasionally disconnecting when I try and pause.

    A colleague ran a project with the same board on Mint Linux and it was fine. Running the same project on my Ubuntu machine has exactly the same problem, so maybe that rules out project or debug configuration.

    I would appreciate any help as code composer runs so much faster on Linux

    Thanks
  • 0 in reply to Garry Blair34
    TI__Guru**** 171094 points

    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.

  • 0 in reply to desouza
    Intellectual 410 points

    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?

  • 0 in reply to Garry Blair34
    TI__Guru**** 171094 points
    Hi,

    Thanks for the additional details; I have no other ideas at the moment as this scenario indicates an intermittent and rather random issue, and these are quite difficult to pinpoint.

    I usually work on a Linux host with similar targets as yours, therefore I can only promise to be on the lookout for anything that may contribute to a similar scenario. Sorry.

    Regards,
    Rafael