• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 39 subscribers
  • Views 771 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.

RTOS/CC3220SF-LAUNCHXL: Changing Pin Config in SDK examples

Mike Basile
Intellectual 390 points
Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: CC3220SF

Tool/software: TI-RTOS

Hello All,

I am working on a project that needs more GPIO than the default configuration for the CC3220SF-LAUNCHXL board. To start testing some code, I want to take the the "empty" example for TI-RTOS in the SDK and edit the pin configuration. I have created the "CC3220SF-LAUNCHXL.h" and "CC3220SF-LAUNCHXL.C" files using PinMux, and have replaced the default files in the empty project. I am able to build this code fine, and start running it. When I get to line 92 of the file "main_tirtos.c" I get the following error:

Cortex_M4_0: JTAG Communication Error: (Error -242 @ 0x0) A router subpath could not be accessed. The board configuration file is probably incorrect. (Emulation package 6.0.628.3)
Cortex_M4_0: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

I've also tested the connection on the CC3220SF.ccxml screen and get the following output:

[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\Mike\AppData\Local\TEXASI~1\CCS\
    ti\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 'May 23 2017'.
The library build time was '19:37:36'.
The library package version is '6.0.628.3'.
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 '-233' (0xffffff17).
The title is 'SC_ERR_PATH_BROKEN'.

The explanation is:
The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.
An attempt to scan the JTAG scan-path has failed.
The target's JTAG scan-path appears to be broken
with a stuck-at-ones or stuck-at-zero fault.

[End: Texas Instruments XDS110 USB Debug Probe]

]

Can anyone give me some insight as to what is going on? Am I missing something else that needs to be changed? Is changing the pin configuration on the Launchpad board even possible?

Any input is greatly appreciated.

Thanks,

Mike

  • 0
    TI__Expert 3410 points
    Hello Mike,

    Line 92 is when the OS starts up, so it will be starting the threads that have been created, so the loss of JTAG comms could be happening later in one of the threads.

    Can you put a break-point in empty.c on the GPIO_init() function to first see if the code reaches this point, and then whether you are able to step in? During the GPIO_init() function, when the GPIOs that you configured in your new pinmux are initialised, one of them might be causing the JTAG communications to be lost.

    The following pins are used for JTAG communications.

    PIN 16 (TDI) (GPIO23)
    PIN 17 (TDO) (GPIO24)
    PIN 19 (TCK)
    PIN 20 (TMS)

    If you have re-assigned GPIO23/24 to new functions, this will cause the debugger to lose connection. You can still use these pins if you need to, but would need to switch to SWD (serial wire (2 wire) debug) instead of JTAG.

    [ Of course, it might be something else, but worth a look for a quick check. ]

    Hope that helps,
    ~roger
  • 0 in reply to RogerMonk
    Intellectual 390 points

    Roger,

    Roger, thanks for the input. It looks like I am reassigning pins 16,17 and 20 so it looks like this is my issue. 

    Thanks again!
    Mike

    EDIT-

    Roger, I figure out how to get everything switched over and it's working great. At first when I switched to SWD mode, I was having the same issue, but it was because I was still using pin 20 which I believed is used for SWD. After I changed the pinmux to avoid pins 19 and 20, everything worked perfectly.