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/CC2650STK: Failed to launch debug session for CC2650STK

Part Number: CC2650STK
Other Parts Discussed in Thread: TEST

Tool/software: Code Composer Studio

Hi

I am on linux 18.04, CCS 9, and I imported the uartecho_CC2650STK_TI project in the IDE (on the PC):

I can build the project, but when I launch a debug session, I get :

Cortex_M3_0: GEL Output: Memory Map Initialization Complete.
Cortex_M3_0: Failed to retrieve the Wait in Reset Mode: (Error -6311) PRSC module failed to write to a register. (Emulation package 8.2.0.00004)
Cortex_M3_0: Error connecting to the target: (Error -6311) PRSC module failed to write to a register. (Emulation package 8.2.0.00004)

here is the screenshot. When I click on TestConnection, I get a success:

.....

The JTAG DR Integrity scan-test has succeeded.

[End: Texas Instruments XDS110 USB Debug Probe]

I am not sure if I have hooked up the board the right way, here is a photo ( with the XDS110):

Thanks

Peter

  • Peter,

    Can you retry in JTAG mode? I get the exact same error when the configuration is set to its default cJTAG (the sensortag may boot in this mode)

    Hope this helps,

    Rafael

  • Rafael

    I get a step further, but rather than dropping into the debugger perspective and stopping at main, its goes back in the C++perspective and I get:

    [Cortex_M3_0] This example does not attempt to minimize code or data footprint
    Starting the UART Echo example
    System provider is set to SysMin. Halt the target to view any SysMin contents in ROV.

    What does this mean ?

    Thanks

    Peter

  • Peter,

    Interesting. I am not entirely sure which example you are running, but the information you are seeing is being output by the console. Since these are not error but informative messages, I suspect the debug session is still active and the code is halted - only the perspective changed. 

    Can you switch back to the Debug Perspective and go to menu Window --> Perspective --> Reset Perspective and see if you get a more sensible arrangement of views?

    Regards,

    Rafael

  • Rafael

    The example is uartecho_CC2650STK_TI.

    I think I have still JTAG issues.

    When I click on "Test Connection" I get (colors are mine):

    [Start: Texas Instruments XDS110 USB Debug Probe]

    Execute the command:

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

    [Result]


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

    /home/p/.ti/ccs910/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 'libjioxds110.so'.
    The library build date was 'Jun  3 2019'.
    The library build time was '15:03:57'.
    The library package version is '8.2.0.00004'.
    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 Integrity scan-test on the JTAG IR]------------------------

    This test will use blocks of 64 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 64 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: Texas Instruments XDS110 USB Debug Probe]

    So far, so good.

    But when I click again, I get this:

    [Start: Texas Instruments XDS110 USB Debug Probe]

    Execute the command:

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

    [Result]


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

    /home/p/.ti/ccs910/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 'libjioxds110.so'.
    The library build date was 'Jun  3 2019'.
    The library build time was '15:03:57'.
    The library package version is '8.2.0.00004'.
    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).

    An error occurred while hard 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 '-275' (0xfffffeed).
    The title is 'SC_ERR_SCAN_POLL_BUSY'.

    The explanation is:
    The attempt to poll a target device exceeded its timeout limit.
    The utility or debugger has requested that a target device be
    repeatedly accessed for a specific data or status value.
    This has failed because the built-in limit for the maximum number
    of attempts when polling the JTAG scan-path has been exceeded.

    [End: Texas Instruments XDS110 USB Debug Probe]

    When I press button one on the SensorTag (the one on the right side when looking on the lithium coin side), Test Connection succeeds again.

    I can reliably repeat this problem.

    I noted that you set PowerSelection to Target Supplied power and Voltage Level to default. I assume that you have the coin cell inserted.

    Do I have the right init files ? Do I need to run some js script when loading the program ( like on Sitaras) ?

    Thanks

    Peter

  • Peter,

    Please apologize for the delay; I have done some testing and occasionally got some errors while connecting to the Sensortag as well - it seems it may be dependent on the software pre-loaded or perhaps the battery voltage (the one I have here is hovering around 2.6V).

    I couldn't reproduce the same behaviour as what you are seeing - the button does not make any difference for me. 

    One aspect that helped me was to enable the option to reset the target on a connect - something shown in section 7.2.4 of the CCS User's Guide, available at the Help menu if you have CCSv9.1 or at the link below. 

    http://software-dl.ti.com/ccs/esd/documents/users_guide/index.html 

    This option will not influence the "Test Connection", but will certainly influence the Debug Launch. 

    I will keep investigating this and see if I find something a bit more conclusive on my side. 

    Regards,

    Rafael

  • Hi Rafael

    Thanks for getting back to me. I continue my tests tomorrow with your feedback. In the meantime I have noticed that the Lithium coin has been complety empties ( 0.3 V) simply by being hooked up to JTAG debugger ( thats what I presume anyway because I inserted a new coin when I received the board a week ago or so). So I wonder if there is a problem with the power supply.

    Is the lithium coin meant to be inserted during debugging ?

    Is the power provided by the XDS110 or by the board ?

    Thanks

    Peter

  • Peter,

    The XDS110 draws a minimal current from Vcc through the VTRef pin, but given that it has other pull ups and pull downs on the JTAG signaling pins, it probably drains the battery a lot faster. 

    No Debug Probe powers the device, therefore the battery must be inserted (or an external power source applied to the BAT- and BAT+ pads) 

    Regards,

    Rafael

  • Rafael

    Thanks, good to know.

    Just to rule out basic connection mistake, could you please validate the JTAG connection I have shown on the photo at the beginning of this thread ?

    Thanks

    Peter

  • Peter,

    The connection on the photograph is fine; it matches with what I have here. 

    Regards,

    Rafael

  • Rafael

    I followed your advice to set this option (reset target) and it worked - but only once !

    Then I always get:

    Cortex_M3_0: GEL Output: Memory Map Initialization Complete.
    IcePick_C: Error connecting to the target: (Error -275 @ 0x0) The attempt to poll a target device exceeded its timeout limit. The utility or debugger has requested that a target device be repeatedly accessed for a specific data or status value. This has failed because the built-in limit for the maximum number of attempts when polling the JTAG scan-path has been exceeded. (Emulation package 8.2.0.00004)

    No matter what I do: unplugging the battery,, the JTAG connector, the XDS110 , I can't get a second debugging section - weird.

    Developping .....

    Regards

    Peter

  • Rafael

    I think I have solved the problem: In debug settings I had to check both :

    - Reset Target on Connect

    - Reset the target on a program load or restart

    The out-of-the box experience with this product is much less overwhelming than for my MSP432 products.

    There seems to be a lack of love  (;- A pity, because these tags are awesome.

    Thanks anyway !

    Peter

  • Peter,

    Thanks for reporting back your findings; I will certainly keep this thread in mind for future developers. 

    Regards,

    Rafael