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: Error connecting to the target: (Error -242 @ 0x0) A router subpath could not be accessed.

Part Number: CC2640R2F


Tool/software: Code Composer Studio

Hello.

I have a custom board using the 4x4mm QFN version of CC2640R2F, which I try to debug through the XDS110 of the CC2640R1 launchpad. The following error message is displayed every time I attempt to flash the ble5_simple_peripheral demo project :

IcePick_C: Error connecting to the target: (Error -242 @ 0x0) A router subpath could not be accessed. The board configuration file is probably incorrect. (Emulation package 8.1.0.00005)

Everything works fine when I attempt to flash the device located onto the launchpad, so it most likely doesn't come from my computer.

Also, when I run a test connection on the .ccxml target config file, it works once after reset, but the subsequent tests will return the same error message, until next reset. This makes me think it is probably not a hardware problem.

I am using the RCOSC configuration and the CC2640R2DK_4XS board file provided by TI (at least I set CC2640R2DK_4XS in the build predefined symbols, if there is something more to do to use the file, please tell me).

Most topic about this same error message speak of a problem occurring from time to time, or were caused by hardware problems, so I could not find any helpful information.

I guess the problem is somewhere in the board configuration firmware, but I don't know what it could be exactly, so my question is where should I look, or what should I try to change from the demo project?

Thank you.

  • Hi,

    Error 242 is shown in the Debugging JTAG page below:
    software-dl.ti.com/.../ccs_debugging_jtag_connectivity_issues.html

    The link contains tips to isolate the issue and workarounds to it.

    Combining your description and the error, I imagine the firmware loaded is causing the device to lock up or reset itself continuously, thus cutting the JTAG access to its Cortex M core.

    Therefore I would inspect the firmware itself and maybe disable the Auto-run to main and perform a step-by-step debug from the entry point _c_int00. Details to disable this are shown at the section "Debug Properties" of the Debug User's Guide at:
    software-dl.ti.com/.../ccs_debug-main.html

    Hope this helps,
    Rafael
  • Hello.

    I had already read the error description in the debugging JTAG page, but if it is explained how the error can be recovered from, there is not much about how to stop the error from happening.

    I tried replacing the main symbol in auto-run options by _c_int00, and to uncheck the boxes and leave the symbol field empty, with the same error as before. I also tried running a projectless debug session with the same result.

    I noticed that when I run a test connection after the error occurred, the error message is actually not exactly the same. The value is -242 (0xffffff0e) instead of -242 (0x0).

    I also noticed that when no MCU is connected to the XDS110, I also get the -242 (0xffffff0e) error in the test connection, but I still get the 0x0 error when attempting to flash. (I'm not sure if this is relevant, sorry if it's not.)

  • Hi,

    Robin Arbaud said:
    I had already read the error description in the debugging JTAG page, but if it is explained how the error can be recovered from, there is not much about how to stop the error from happening.

    As you suspect, that is one of the issues with the nature of the problem; the firmware itself is triggering this scenario, but this varies a lot among the various device families and even across SDK releases. I strongly suggest you to open a thread at the Bluetooth forum and share as much information as possible (even with your project if possible) as they will have more educated answers given their expertise about the device itself.  

    https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538 

    Robin Arbaud said:
    I noticed that when I run a test connection after the error occurred, the error message is actually not exactly the same. The value is -242 (0xffffff0e) instead of -242 (0x0).

    This is possible to happen, given the Test Connection and the actual connection from inside a debug session will access different registers on the device - the number inside the parenthesis is the address that failed to be properly accessed. In this particular scenario it will not matter much.

    Hope this helps,

    Rafael