CC2640R2F: Cannot program CC2640R2F: Unable to access the DAP

Part Number: CC2640R2F
Other Parts Discussed in Thread: LAUNCHXL-CC2640R2, , UNIFLASH, SYSCONFIG

Hello,

we have developed a custom board featuring the CC2640R2F SoC that can be programmed via a XDS110 on the LAUNCHXL-CC2640R2 board.  A while ago, I could program and debug the chip without any problems. This was valid for the newest revision of the board as well as the previous one. Now, suddenly, I'm not able to program any of the custom boards anymore. When I write the program into the on-board CC2640R2F on the launchpad by using jumpers to connect the same signals used on our board (+3.3V, GND, TCK, TMS, RESET) involving the same target configuration (CC2640R2F.ccxml), it works without problems. But when I attach our board, it won't work and displays a repeating error that it cannot access the DAP:

Flashloader: Verbose output enabled.
Writing Flash @ Address 0x00000000 of Length 0x00007ff0
Loading flashloader to target: FlashLoaderCC26x0.out 
  Chunk 1: addr=0x00000000, length=4096, crc=0x1938B2EE (using block 0)
Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 20.3.0.3656) 
Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 20.3.0.3656) 
Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 20.3.0.3656) 
Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 20.3.0.3656) 

 

Flashloader: Verbose output enabled.
Writing Flash @ Address 0x00000000 of Length 0x00007ff0
Loading flashloader to target: FlashLoaderCC26x0.out
   Chunk 1: addr=0x00000000, length=4096, crc=0x1938B2EE (using block 0)
   Chunk 2: addr=0x00001000, length=4096, crc=0x1FAA55EF (using block 1)
   Chunk 3: addr=0x00002000, length=4096, crc=0x508BA633 (using block 0)
   Chunk 4: addr=0x00003000, length=4096, crc=0xB74B9D9B (using block 1)
   Chunk 5: addr=0x00004000, length=4096, crc=0x747317C8 (using block 0)
   Chunk 6: addr=0x00005000, length=4096, crc=0x1BECAEA5 (using block 1)
   Chunk 7: addr=0x00006000, length=4096, crc=0x410894F7 (using block 0)
   Chunk 8: addr=0x00007000, length=4080, crc=0xEACB68DE (using block 1)
Writing Flash @ Address 0x00007ff0 of Length 0x00007ff0
   Chunk 1: addr=0x00007FF0, length=4096, crc=0xA10FBAB4 (using block 0)
   Chunk 2: addr=0x00008FF0, length=4096, crc=0x1FECFA8B (using block 1)
   Command=20 -- addr=0x00008FF0 -- length=0x00001000
Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device
status. Reset the device, and retry the operation. If error persists,
confirm configuration, power-cycle the board, and/or try more reliable
JTAG settings (e.g. lower TCLK). (Emulation package 20.3.0.3656)
Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device,
and retry the operation. If error persists, confirm configuration,
power-cycle the board, and/or try more reliable JTAG settings (e.g.
lower TCLK). (Emulation package 20.3.0.3656)
Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device
status. Reset the device, and retry the operation. If error persists,
confirm configuration, power-cycle the board, and/or try more reliable
JTAG settings (e.g. lower TCLK). (Emulation package 20.3.0.3656)

Sometimes, the error number is different (as seen above), and a part of the code gets loaded. But even then, it stopped at the same point on every single try.

The weird thing is - when I connect to the interface manually, I don't experience any problems. I can connect to the board, show all cores, and connect to the Cortex M3, the DAP as well as the IcePick. 

I also tried unplugging and re-plugging all cables, lowering the TCLK to 1.5 MHz, and did various JTAG connectivity tests. Those work without a problem:

Test Connections
-----[Print the board config pathname(s)]------------------------------------ C:\Users\Arbeit\AppData\Local\TEXASI~1\CCS\ ccs2031\0\0\BrdDat\testBoard.dat -----[Print the reset-command software log-file]----------------------------- This utility has selected a 100/110/510 class product. This utility will load the adapter 'jioxds110.dll'. The library build date was 'Aug 12 2025'. The library build time was '02:44:21'. The library package version is '20.3.0.3656'. 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.
Compiler is TI v18.12.5 LTS
XDCTools 5.51.3.28_core
SimpleLink CC2640R2F SDK 5.30.0.03
 
I can't think of anything that could be wrong. I would be very happy for any help and hints - Please let me know if you need any more information. Thank you very much in advance! :)
 
best wishes,
Nico
  • Hello Nico,

    Sometimes, the error number is different (as seen above), and a part of the code gets loaded. But even then, it stopped at the same point on every single try.

    The weird thing is - when I connect to the interface manually, I don't experience any problems. I can connect to the board, show all cores, and connect to the Cortex M3, the DAP as well as the IcePick. 

    Can you expand on "when I connect the interface manually, I don't experience any problems"?

    What is the difference to the above statement vs the below? In both cases we are attaching them manually, no?

    using jumpers to connect the same signals used on our board (+3.3V, GND, TCK, TMS, RESET) involving the same target configuration (CC2640R2F.ccxml), it works without problems. But when I attach our board, it won't work and displays a repeating error that it cannot access the DAP:

    Flashloader: Verbose output enabled.

    Have you already had your custom PCB reviewed by TIs design review forum? 

    Thanks,
    Alex F

  • A while ago, I could program and debug the chip without any problems. This was valid for the newest revision of the board as well as the previous one. Now, suddenly, I'm not able to program any of the custom boards anymore.

    If you are programming using the P4 of the CC2640R2F Launchpad pins +3.3V, GND, TCK, TMS, RESET, you might need to scrape the pins using cutter to make sure there are no dirt or corrosion on the pins. You also need to check the wires if there is connectivity. Also make sure the wires are not too long.

    If this does not work then it is possible that your custom boards have developed a problem which would need to be investigated.

    -kel 

  • Hey Alex,

    thanks for reaching out!
    In the first statement, I was talking about manually connecting to the custom board. When I enter the debug workspace and just start the target configuration for our board, I can connect to all mentioned parts of the SoC:

    Still, when I want to load the program into the board, the error above occurs, saying it is not possible to talk to the DAP; still, this view shows that I am somehow able to connect to the DAP. Also, both of my two working prototypes of different design iterations "broke" at the same time, so I suspected that it is a fault that somehow might have to do with the launchpad used for programming or the CCS IDE.
    And yes, we had our design reviewed a while ago by your team, but via Mail :)

    best wishes,
    Nico

  • Hey Markel, 

    thak you very much for the hint! I will try that. Still, I doubt that it might help too much, because the on-board SoC gets connected to the programmer via the same jumpers. Shouldn't the same effect happen here, too? Will come back here and say if it worked :) 

    best wishes,
    Nico

  • Hello Nico,

    this view shows that I am somehow able to connect to the DAP.

    Correct, this seems like you can at least enter a debug session, as a double check can you open UniFlash and attempt to read the memory or see if you can manually completely erase the device? 

    both of my two working prototypes of different design iterations "broke" at the same time, so I suspected that it is a fault that somehow might have to do with the launchpad used for programming or the CCS IDE.

    The XDS is what programs the board, not the LaunchPad itself; what did you set your device permission settings in Sysconfig to? 

    Seeing as both of the board "broke at the same time" did you program the same image to both, or were these two completely separate images? 

    Again lets try to see if the UniFlash tool can first connect to the device, then do a full mass erase of the device and try to re-flash it to see it starts working again.

    Thanks,
    Alexander F

  • Hi,

    See, Cannot access the DAP Error -1170 from the link below. This is usually caused by either a hardware failure on the board or invalid code on the subcore that causes it to reset itself continuously..

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

    This should be not a problem if you use one of the example programs in the SDK as base for your program. 

    Also make sure the target board is set to CC2640R2F.

    -kel