• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 4227 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.

Using CC13XX / CC26XX launchpads with OpenOCD

Andrew G
Intellectual 900 points
Other Parts Discussed in Thread: UNIFLASH, CC1310

This is a rather a low-level question about the XDS110 debugger in the newer CC13XX and CC26XX launchpads. It's not about CSS, but I couldn't find a better subgroup under "Development Tools" to post it.

I would like to flash / debug the launchpads using OpenOCD. This is currently not possible because the CMSIS-DAP driver in OpenOCD is SWD only. Unfortunately, CC13XX and CC26XX only support JTAG and cJTAG.

I would like to understand the interaction between XDS110 and cJTAG enough to add support for the new launchpads to OpenOCD (or perhaps help someone else do it). As a start, I am trying to execute simple USB commands relying on ARM's CMSIS-DAP documentation: https://www.keil.com/pack/doc/CMSIS/DAP/html/group___d_a_p___commands__gr.html

1) Executing DAP_Connect (0x02 0x02) works as expected -- the debugger acknowledges a JTAG connection. However, the only documented connection types are SWD and JTAG. Is there a special magic value to request a cJTAG connection? I tried 0x03 as a guess, but that didn't work.

2) After establishing a connection to the debugger, the DAP_Info command works as expected. I am able to fetch the firmware version of the debugger, packet size, and other similar attributes.

3) My understanding is that next I need to configure the JTAG chain using DAP_JTAG_Configure. Here I send (0x15 0x02 0x04 0x06) to set the IR length of the ICEPick unit to 4 and the IR length of the Cortex M3 target to 6. I am not sure if this chaining is valid for cJTAG.

4) Next I try to fetch the IDCODEs via DAP_JTAG_IDCODE (0x16 0x1) or (0x16 0x0), which fails (returns 0xff in the status byte). Reading registers via DAP_Transfer also fails.

I guess I am unsuccessful because XDS110 is trying to talk to the ARM chip using JTAG, and the ARM chip is configured for cJTAG by default. I know there is a sequence to switch from cJTAG to JTAG, but I would rather use cJTAG if possible, as it requires fewer signal lines.

Am I missing something simple? What minimal sequence of CMSIS-DAP commands will allow me to read IDCODE via cJTAG? Are there extensions to CMSIS-DAP needed to accommodate cJTAG, and if so, are they documented anywhere?

I did look at USB packets sent from TI's tools (such as Uniflash) to the launchpads, but they didn't make much sense. Most commands started with 0x2a if I remember correctly. Perhaps these are vendor-specific CMSIS-DAP commands?

  • 0
    TI__Mastermind 36395 points

    Andrew,

    Have you looked at this document, it describes how to get GCC up and running on our devices.

    Regards,
    /TA

  • 0 in reply to TA12012
    Intellectual 900 points
    I did read that document. However,

    1) I am having issues with gdb_agent_console and a CC1310 launchpad board (latest versions of everything). Specifically, I get errors when I try to set breakpoints:

    e2e.ti.com/.../522869

    2) I would still prefer to use OpenOCD, if support for CC13XX / CC26XX launchpads can be added to it
  • 0 in reply to Andrew G
    TI__Intellectual 2515 points

    Currently the CMSIS-DAP firmware running inside the XDS110 contains no support for cJTAG.  The CMSIS-DAP code is supplied by ARM, and the only customization done is to show it which GPIOs are used for which JTAG/SWD signals. The ARM code directly bit-bangs the GPIOs itself and has no knowledge of how to do cJTAG support.

    The breakpoint issue is a known issue that is currently be diagnosed and corrected.  It should be resolved in the next official emupack release.

  • 0 in reply to Edward Fewell
    Intellectual 900 points

    Thank you Edward. Just to make sure that I understand, are you saying that XDS110 uses cJTAG to communicate with the MCU, but it does so by proxying bit bang commands from the PC host? In other words, is all of the complexity of cJTAG communication handled by the host, and not the debugger?

    Are there plans to extend CMSIS-DAP for cJTAG in XDS110?

  • 0 in reply to Andrew G
    TI__Intellectual 2515 points
    There are two separate software stacks inside the XDS110 firmware. The XDS stack which provides debug for CCS and other clients that can use our XDS drivers is capable of supporting JTAG, SWD, and cJTAG. The software in the firmware can directly support all three connection types. For DAP based devices, the firmware is capable of handle requests to read blocks of memory, converting those into the appropriate DAP register accesses and executing the low level communications via JTAG, SWD, and cJTAG as requested, all done inside the XDS110.

    The CMSIS-DAP code is completely separate from the XDS stack and is accessed via an HID endpoint of the USB device. That code exposes DAP register accesses and only handles JTAG and SWD. This code is supplied by ARM for creating CMSIS-DAP debug probes on Cortex M devices. We don't modify that code other than to supply some entries in the a header to map out our hardware for the CMSIS-DAP code. Because the CMSIS-DAP code does not interface with the other software stack at all, it has no ready way to gain cJTAG support. And we currently have no plans to add that support.