• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 51 subscribers
  • Views 975 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/CC2642R: Unable to access the DAP

Martin Boyd
Intellectual 810 points
Part Number: CC2642R


Tool/software: Code Composer Studio

I have a project that is based on Simple Peripheral running on a CC2642R, I'm using CCS9.3 on OS X. 

I am getting an "Unable to access the DAP" error after the code has been running for around 30 seconds. I have seen this error in the past and I know it's normally due to hardware issues, bad JTAG connection etc. But this time it is being caused by software. The code works fine in the debugger normally, but if I make a couple of changes to some settings it will consistently get this error.

I am trying to narrow down the issue by trial and error (the debugger is obviously not any help to catch it) but it is taking some time. Does anyone know what kind of software issue could cause this?

Cortex_M4_0: GEL Output: Memory Map Initialization Complete.
Cortex_M4_0: GEL Output: Board Reset Complete.
Cortex_M4_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 8.4.0.00006)
Cortex_M4_0: 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 8.4.0.00006)
Cortex_M4_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 8.4.0.00006)
Cortex_M4_0: 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 8.4.0.00006)
Cortex_M4_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 8.4.0.00006)
Cortex_M4_0: 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 8.4.0.00006)
Cortex_M4_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 8.4.0.00006)

  • 0
    TI__Genius 14845 points

    Hi Martin, 

    What code changes have you made to see this error?

    Are you trying to use the HW from another application at the same time, for example, BTool?

    Thanks, 
    Elin

  • 0 in reply to Elin W
    Intellectual 810 points

    I am using a launchxl-cc26x2r1 which is connected to our PCB as the debugging target, no other hardware.

    I haven't made any code changes to trigger it as such, the code is fairly involved and is basically like a small PLC, so it takes an instruction set that is executed on the CC2642 to define how it behaves. We have found that some of these setups trigger the problem. I am still trying to pinpoint it but it seems to be caused when the instructions are using Modbus over the serial port, we also have a Modem connected on the other serial port and my suspicion right now is that using 2 instances of the UARTCC26XX driver is somehow conflicting with each other.

    SDK version is simplelink_cc13x2_26x2_sdk_3_40_00_02

  • 0 in reply to Martin Boyd
    TI__Genius 14845 points

    Hi Martin, 

    Thanks for providing more information about your setup. Unfortunately, there are many factors in it that can be the cause of this issue which means that it's impossible for me to give a clear answer to the cause of this problem. 

    My suggestion is to keep on debugging by removing features one by one to see what's causing this issue. 

    Thanks, 
    Elin

  • 0 in reply to Elin W
    Intellectual 810 points

    It appears that the cause of the issue was some runaway code that was trashing ram, probably a significant amount. I am using 2 UART driver units one on each thread and somehow they seem to be interacting with each other. With one thread just writing some characters to the UART and another thread talking to a modem I found that sometimes the modem UART_read() call was returning -1 because a read was already outstanding. The call was in a loop that was adding the number of bytes read to a pointer and because its a negative value it was under-running the buffer.

    So the short answer is trashing RAM can cause this error.