• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 56 subscribers
  • Views 10467 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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/LAUNCHXL-CC1310: 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 6.0.576.0)

Michael Moon
Expert 2050 points
Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC1310, CC1350, LAUNCHXL-CC2640R2

Tool/software: Code Composer Studio

Hi,

I frequently get errors when programming my launchpads: '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 6.0.576.0)'

Once this error occurs, no amount of retrying can get past it.

A simple powercycle of the board (unplug, wait 5s, replug) fixes it for a while, but since CCS is so incredibly slow to program things, this puts a fairly significant dent in my iteration time during development.

Usually this will occur after 5-10 programming cycles.

Apparently the XDS110 firmware gets into some sort of weird state and needs a reset to get out of it.

I'm using CCS 7.1.0.00016 for Linux and whichever version of XDS firmware it installs on the probe - it asked to update probe firmware on first run, which I allowed it to do.

Is this a known issue, and is there any fix available or upcoming?

  • 0
    TI__Guru**** 168267 points

    Hi,

    I am not extensively using CC13xx devices on Linux, but I haven't seen this issue happen yet on this OS. 

    The error 242 you are getting is shown in section 5.24 of the page below:

    http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems 

    Specifically for CC1310, the section above mentions how bad firmware loaded to the target can trigger this behaviour. I would try to see if there is a correlation with specific modifications to the code and the ability to connect. 

    Michael Moon said:
    A simple powercycle of the board (unplug, wait 5s, replug) fixes it for a while, but since CCS is so incredibly slow to program things, this puts a fairly significant dent in my iteration time during development.


    You can simplify this step by simply "disconnecting" from the core instead of terminating the debug session. When this error happens, most probably the Cortex M3 is not yet connected as shown in the screen below

    At this point you can simply power cycle the board, then right-click on the highlighted line above and select "Connect Target". This will cause CCS to re-connect to the Cortex M3 without having to restart the debugging session.

    I will keep an eye for other reports and try to find out if anything specific to Linux can be the trigger for this issue. 

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    Expert 2050 points
    OK I'll try reconnect and mass erase next time it happens and let you know.

    Fwiw, when it gets into this state, the UART (ttyACM0) still works fine, so it's almost certainly not a USB problem.
  • 0 in reply to Michael Moon
    Expert 2050 points

    When I right-click on the debug session item, "Connect target" and "Disconnect target" are greyed out, as are most of the other options.

    The only apparently useful option is "Relaunch" which triggers the "Router subpath cannot be accessed" error.

    Right-clicking on my ccxml and selecting "Debug As" -> "Code Composer Debug Session" has the same effect.

    Curiously, the 'Mass Erase' script that I recall being present in CCS 7.0 seems to now be absent in CCS 7.1 (my "Scripts" menu simply says "No scripts available"), so it seems that the only way I can get my board out of this state is to unplug/replug.

    I've just noticed that it sometimes does this when the board is deadlocked ala my other thread, I'll keep an eye out for a correlation from now.

  • 0 in reply to Michael Moon
    Guru 92251 points

    Michael Moon said:
    When I right-click on the debug session item, "Connect target" and "Disconnect target" are greyed out, as are most of the other options.

    Are you right-clicking on the top entry which is the name of the ccxml file, or the entry for "Texas Instrumennts XDS110 USB Debug Probe/Cortex_M3_0"?

    To see the "Connect Target" or "Disconnect Target" options you need to right-click on the entry for "Texas Instrumennts XDS110 USB Debug Probe/Cortex_M3_0" core.

    i.e. the right-click options are context sensitive:

  • 0 in reply to Michael Moon
    Guru 92251 points

    Michael Moon said:
    Curiously, the 'Mass Erase' script that I recall being present in CCS 7.0 seems to now be absent in CCS 7.1 (my "Scripts" menu simply says "No scripts available"), so it seems that the only way I can get my board out of this state is to unplug/replug.

    The Scripts menu is also context-sensitive to what has been selected in the Debug window. e.g. the "Mass Erase" script is only available when the "Texas Instruments XDS110 USB Debug Probe/Cortex_M3_0" (core) entry is selected in the Debug window. E.g.:

  • 0 in reply to Chester Gillon
    Expert 2050 points
    OK, I ran into this the other day, and hitting mass erase a couple of times seems to sort it out and allow me to flash new code without powercycling.

    Thanks for hints on the context-sensitive nature of CCS, my normal dev environment is a (rather nice) text editor and a terminal so this context sensitive stuff only serves to annoy me ;)
  • 0 in reply to Michael Moon
    Expert 2050 points
    Hmm, now I have a board here where CCS says this every time I try to connect to it - presumably it's going into some weird state too soon after boot for CCS to arrest it.

    Since CCS won't connect, I never have any opportunity to invoke the "mass erase" script since I can't enter the "debug connected context"

    How can I unbrick this board?
  • 0 in reply to Michael Moon
    Prodigy 60 points
    I am in a similar situation with a CC1350. I have a Retry or Cancel button on the error message dialog. Retry just redisplays the dialog. Cancel terminates the debug session and the Debug tab disappears.

    This same project will work on another LaunchPad CC1350 with no problems.

    Full Console output:

    Cortex_M3_0: GEL Output: Memory Map Initialization Complete.
    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 6.0.628.1)
  • 0 in reply to Doug Reese
    Prodigy 240 points

    I had a similar problem with CC2640R2: worked OK on LAUNCHXL-CC2640R2 demo board, but failed to connect to my target board with the same chip type (CC2640R2).

    In my case, it turned out to be different VDD levels on target and on XDS110.

    XDS110 works on 3.3V, while my target works on 3V (I used the XDS110 section of the LAUNCHXL-CC2640R2).

    On the XDS110 there is a provision to use the target VDD for the interface level shifters to address this issue. Unfortunately, I couldn't use this because I didn't have the VDD on my target board connector, so I worked around it by adding 100-ohm series resistors on all the interface signals (but not on the GND), on the cable that connects the target to the XDS110.

    Works OK now for me.