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/CC2640R2F: CC2640R2F

Part Number: CC2640R2F
Other Parts Discussed in Thread: UNIFLASH, , CC2650, LAUNCHXL-CC1352R1

Tool/software: Code Composer Studio

Hi,

I use the SDK "simplelink_cc2640r2_sdk_1_35_00_33" and "simple_peripheral" project under blestack.

I tried to flash both the application and stack binaries using SmartRF Flash Programmer 2 Ver. 1.8.0 and UniFlash (ver. 4.5.0.2056).

Used Debugger - XDS110.

JTAG to the CC2640R2F (Connected JTAG pins TMS, TCK, TDI, TDO and RESET to the BT Chip).

1) In SmartRF Flash Programmer 2,

It detected the target device as CC2640R2F. And connected successfully by right clicking to it (JTAG_Conn_Success_Serial_RF_Flash.jpg).

Then I tried to read the memory from Edit->Address->Read option. And waited some time. Nothing came. It shows the status as "Start reading Flash..." and it went idle. (Mem_Read_Hang_JTAG_Conn_Serial_RF_Flash.jpg)

2) In UniFlash,

Connected device with XDS110 Debug Probe. Tried to read the target device memory from Memory option.

Got error as "(Error -1170 @ 0x0) Unable to access the DAP". (Mem_JTAG_Conn_UniFlash.jpg)

Why it is not reading the memory even the target connected successfully? Is the connection not healthy? If so what could be the reason and how can rectify this?

Thanks and Regards,

Arun

  • Hello Arun,

    I can't comment on SmartRF Flash Programmer as that tool is developed outside the CCS group.

    But regarding UniFlash:

    Arun MP said:

    Got error as "(Error -1170 @ 0x0) Unable to access the DAP". (Mem_JTAG_Conn_UniFlash.jpg)

    Why it is not reading the memory even the target connected successfully? Is the connection not healthy? If so what could be the reason and how can rectify this?

    The target was not connected successfully. It was in the process of connecting to the target and failed with that error.

    The details of the error are described in the link below:

    http://software-dl.ti.com/ccs/esd/documents/ccsv7_debugging_jtag_connectivity_issues.html#cannot-access-the-dap

    A mass erase of the device can help. But based on your screenshot, it looks like one was done but still the error persists.

    Are you able to connect using CCS?

    Thanks

    ki

  • Hi Ki,

    I've tried the Mass Erase of the device and it didn't workout.

    Thanks,

    Arun

  • Yes, I saw that mass erase didn't work. Can you connect via CCS? What happens when you run the JTAG connectivity test?
  • I tried to connect via CCS, and getting the report as:

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

    C:\Users\arun.mp\AppData\Local\TEXASI~1\
    CCS\ccs900\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 'jioxds110.dll'.
    The library build date was 'Mar 13 2019'.
    The library build time was '21:38:07'.
    The library package version is '8.1.0.00005'.
    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 has occurred and this utility has aborted]--------------------

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

    The value is '-232' (0xffffff18).
    The title is 'SC_ERR_PATH_DR_MEASURE'.

    The explanation is:
    The measured length of the JTAG DR data path is invalid.
    This indicates that an error exists in the link-delay or scan-path.

    [End: Texas Instruments XDS110 USB Debug Probe]

  • I forgot to add few more things here.

    I'm using XDS110 Debugger from CC2650 launchpad development kit. And the JTAG lines from the same board connecting to the CC2640R2F chip, and is powering externally.
  • Arun MP said:
    I'm using XDS110 Debugger from CC2650 launchpad development kit. And the JTAG lines from the same board connecting to the CC2640R2F chip, and is powering externally.

    Thanks. This is quite an important piece of information about your setup. It is an environment that I am not too familiar with. I will bring this thread to the attention of a colleague who is more experienced.

    Thanks

    ki

  • Hi,

    Please apologize for the delay; do you have a photograph of your setup, showing the connections between the Launchpad and the target board? This can help reveal any potential issues.

    That said, last week I experienced something similar as you, but on a different device: my LAUNCHXL-CC1352R1 board was refusing to connect via CCS with the same error after I loaded one of the example codes to it. Also, any attempts to perform the Mass Erase required the Cortex M core to be connected (a catch-22 scenario).

    In this case, I did the following trick: using CCS, I kept pressing the reset button on the board, launched the Debugger Manually and only released it until immediately before I clicked the "connect" button. This prevented the pre-loaded code from reaching the routine that disrupted the JTAG communications. That may or may not work for you, but it is certainly worth a shot.

    From Uniflash, I would do the same procedure but immediatelly before pressing the Mass Erase button.

    Hope this helps,
    Rafael

  • Hello,
    I haven’t heard back from you, hence this issue is being closed. If you wish to continue the discussion, please post a reply with an update below (or create a new thread).

    Thanks,
    ki