TI CC26XX Debugging

Hello

I have recently began working on a personal project with the cc26x family of devices from Texas Instruments, specifically the cc2650stk and cc2650 launch XL. I have limited knowledge on OpenOCD, I am unfortunately a slave to gui based proprietary debuggers. I have briefly used OpenOCD before with the EK-TM4C and the EL-LM4F family of devices, but with the configuration files already available for the board, little time was spent understanding the lower level concepts of OpenOCD.

I have searched quite extensively and have yet to find some information that satisfies my question. I saw that early last year the cc26xx cpus had been added as a target.

http://openocd.zylin.com/#/c/2232/

However I am a little confused. I have two debuggers, the XDS100v3 and the XDS110 both of which I believe are ICEPICK_C based debuggers. So I run the following command.

openocd.exe -f target/cc26xx.cfg -c init

However this errors with the follow output:

Debug adapter does not support any transports? Check config file order.

The full debug is as follows;

Open On-Chip Debugger 0.9.0 (2015-05-19-12:06)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.org/doc/doxygen/bugs.html

User : 13 2 command.c:546 command_print(): debug_level: 3

Debug: 14 2 options.c:98 add_default_dirs(): bindir=bin

Debug: 15 2 options.c:99 add_default_dirs(): pkgdatadir=

Debug: 16 2 options.c:100 add_default_dirs(): run_prefix=D:/Downloads/openocd-0.9.0/

Debug: 17 3 configuration.c:44 add_script_search_dir(): adding C:\Users\nicholas/.openocd

Debug: 18 3 configuration.c:44 add_script_search_dir(): adding C:\Users\nicholas\AppData\Roaming/OpenOCD

Debug: 19 3 configuration.c:44 add_script_search_dir(): adding D:/Downloads/openocd-0.9.0//site

Debug: 20 3 configuration.c:44 add_script_search_dir(): adding D:/Downloads/openocd-0.9.0//scripts

Debug: 21 4 configuration.c:84 find_file(): found scripts/target/cc26xx.cfg

Debug: 22 5 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_adapter_khz 100

Debug: 23 6 command.c:145 script_debug(): command - adapter_khz ocd_adapter_khz 100

Debug: 25 6 core.c:1629 jtag_config_khz(): handle jtag khz

Debug: 26 6 core.c:1596 adapter_khz_to_speed(): convert khz to interface specific speed value

Debug: 27 6 core.c:1596 adapter_khz_to_speed(): convert khz to interface specific speed value

User : 28 7 command.c:546 command_print(): adapter speed: 100 kHz

Debug: 29 8 configuration.c:84 find_file(): found D:/Downloads/openocd-0.9.0//scripts/target/icepick.cfg

Debug: 30 8 configuration.c:84 find_file(): found D:/Downloads/openocd-0.9.0//scripts/target/ti-cjtag.cfg

Debug: 31 9 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_transport select

Debug: 32 9 command.c:145 script_debug(): command - ocd_transport ocd_transport select

Error: 33 9 transport.c:283 jim_transport_select(): Debug adapter does not support any transports? Check config file order.

User : 34 10 command.c:689 command_run_line(): embedded:startup.tcl:21: Error:

in procedure ‘script’

at file “embedded:startup.tcl”, line 60

in procedure ‘jtag’ called at file “scripts/target/cc26xx.cfg”, line 22

in procedure ‘default_to_jtag’ called at file “embedded:startup.tcl”, line 167

in procedure ‘transport’ called at file “embedded:startup.tcl”, line 158

in procedure ‘ocd_bouncer’

at file “embedded:startup.tcl”, line 21

Some further searching of the limited information about the TI board I try the following:

openocd.exe -f interface/cmsis-dap.cfg -f target/cc26xx.cfg -c init

Which errors:

Error: session transport is “swd” but your config requires JTAG

So I set the transport to jtag with the following.

openocd.exe -c "transport select jtag" -f interface/cmsis-dap.cfg -f target/cc26xx.cfg -c init

Which again errors with the following.

Error: Debug adapter doesn’t support any transports?

The full debug dump:

Open On-Chip Debugger 0.9.0 (2015-05-19-12:06)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.org/doc/doxygen/bugs.html

User : 13 2 command.c:546 command_print(): debug_level: 3

Debug: 14 2 options.c:98 add_default_dirs(): bindir=bin

Debug: 15 3 options.c:99 add_default_dirs(): pkgdatadir=

Debug: 16 3 options.c:100 add_default_dirs(): run_prefix=D:/Downloads/openocd-0.9.0/

Debug: 17 3 configuration.c:44 add_script_search_dir(): adding C:\Users\nicholas/.openocd

Debug: 18 3 configuration.c:44 add_script_search_dir(): adding C:\Users\nicholas\AppData\Roaming/OpenOCD

Debug: 19 3 configuration.c:44 add_script_search_dir(): adding D:/Downloads/openocd-0.9.0//site

Debug: 20 3 configuration.c:44 add_script_search_dir(): adding D:/Downloads/openocd-0.9.0//scripts

Debug: 21 4 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_transport select jtag

Debug: 22 4 command.c:145 script_debug(): command - ocd_transport ocd_transport select jtag

Error: 23 4 transport.c:314 jim_transport_select(): Debug adapter doesn’t support any transports?

User : 24 5 command.c:689 command_run_line(): embedded:startup.tcl:21: Error:

in procedure ‘transport’

in procedure ‘ocd_bouncer’

at file “embedded:startup.tcl”, line 21

I’m hesitant to submit a bug report as I feel like I’m doing something wrong.

Any help would be appreciated.

Sincerely,

Nicholas

I am running into the same issue with the TI CC1310 Launchpad. This board is identical to the CC26XX launchpad, except for the radio support.

The problem seems to be that:

  1. CC26XX and CC13XX chips do not support SWD, only JTAG and cJTAG. This is documented in chapter 5 of the reference manual:

http://www.ti.com/lit/ug/swcu117f/swcu117f.pdf

  1. The boards have an integrated XDS110 debugger. This debugger supports both JTAG and SWD, but, strangely, it appears that only SWD support has been implemented in OpenOCD (please let me know if this is wrong!)

As far as I can tell, the only solution at the moment is to use an external debugger or the proprietary / bloated TI tools.

Thanks for the reply

Yeah I had continued to look into the matter and you have confirmed what I suspected.

I would be careful to call it an integrated debugger, depending on the platform you are using. Technically the XDS110 is an external debugger.

It does seem that OpenOCD has only implemented the SWD interface for the cc13xx/c26xx family.

To make things even more interesting I am using the cc2650stk and cc2650launch xl, although it says it supports cJTAG, the physical layout is not setup to support cJTAG only JTAG hahaha. And two of the four JTAG lines are shared with the external flash, which means no debugging the flash…

I may potentially implement the JTAG icepick interfaces for the cc13xx/cc26xx family. But I have other high priority tasks at the moment. And to be honest, I am not the biggest fan of the contribution environment for OpenOCD. What’s frustrating is that the pull request was merged. I am wondering what kind of testing was done? From the commit comments, there seems to be no testing completed for the pull request, but I could be wrong. There was a comment referring to custom hardware, which I suppose could allow that use of cJTAG. But there is no mention of completed testing.

I have managed to setup a fairly efficient/stable development environment using the TI XDS emulation package provided through the UNIFLASH tools. It’s okay, but not the best. But it does provide me with the ability to debug though GDB.

I’m going to be working with the cc26xx family for my PhD and I am contributing as much resources as I can to the development of the RIOT OS for the Sensor Tag platform. If you’re interest, you can find information here https://github.com/RIOT-OS/RIOT

Nicholas

kff:
I am running into the same issue with the TI CC1310 Launchpad. This board is identical to the CC26XX launchpad, except for the radio support.

The problem seems to be that:

  1. CC26XX and CC13XX chips do not support SWD, only JTAG and cJTAG. This is documented in chapter 5 of the reference manual:

http://www.ti.com/lit/ug/swcu117f/swcu117f.pdf

  1. The boards have an integrated XDS110 debugger. This debugger supports both JTAG and SWD, but, strangely, it appears that only SWD support has been implemented in OpenOCD (please let me know if this is wrong!)

As far as I can tell, the only solution at the moment is to use an external debugger or the proprietary / bloated TI tools.

Theoretically, it should be fairly easy to add OpenOCD support for the new TI launchpads (CC2650 and CC1310). The integrated XDS110 debugger speaks CMSIS-DAP, which is protocol agnostic – the communication between the host and the debugger should be virtually identical for both SWD and JTAG. CMSIS-DAP’s documentation is available for free on ARM’s web site.

I may take a crack at this, but if anyone is already familiar with how OpenOCD and CMSIS-DAP work and knows how to switch on JTAG support on the debugger side, I would be very, very grateful for your effort.

To the original poster – cJTAG uses a subset of JTAG pins, so there shouldn’t be a physical layout problem.

cJTAG uses a subset of JTAG pins, so there shouldn’t be a physical layout problem.

Sorry I was thinking of implementation within the TM4C XDS110 firmware.

We are also working to get cJTAG support on the XDS110 debugger so it doesn’t conflict any more with other functionality on the SensorTag.

That was taken from https://e2e.ti.com/support/wireless_con … 8/t/449868. If I have time, I will take a look at it this week. Rather than waiting for TI to implement cJTAG.

Thanks for the Help.

The CC26XX / CC13XX launchpads already use cJTAG to communicate with TI tools. You can check this by removing the TDI and TDO jumpers from the board – everything still works fine, meaning that only two lines are used for debugging.

OpenOCD does not support cJTAG, but that doesn’t matter, because that side of the protocol is handled by the XDS110 debugger. The communication between the host and the debugger is via CMSIS-DAP.

I tried the TI debug server (gdb_agent_console), but it seems buggy, at least in Linux. In particular, I get error messages when trying to set any breakpoints in gdb.

Is this forum monitored at all by the main OpenOCD contributors? It appears that most of the recent questions got absolutely no attention from people who actually develop OpenOCD. Are the mailing lists a better place for technical discussions?