• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 53 subscribers
  • Views 577 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/TMDXLCDK138: How to connect an XDS110 debug emulator of Launchxl-CC1350-4 to a LCDKOMAPL138

Dmitry Kinyov59
Prodigy 245 points

Part Number: TMDXLCDK138

Tool/software: Code Composer Studio

May be "Tools" forum is a more appropriate place to post a question but I can't reach it :) 

Is it possible to connect an XDS110 debug emulator of Launchxl-CC1350-4 to a LCDKOMAPL138?

I've made wire connections between these two boards but I'm still receiving an error -233 while "Testing connection" and  error -2131 when trying to start a debug session. EMU0/1 & RTCK are left unconnected. I also tried to alter a TCK rate from 100kHz to 2.5MHz.

Thanks in advance

  • 0
    TI__Guru**** 168884 points
    Hi,

    Unfortunately no. The connection itself is perfectly possible from a HW standpoint, but the issue is that ARM9 cores require Adaptive clocking on the JTAG communications but the XDS110 class of Debug Probes does not support it.

    In this case, you will need either a XDS200 (TMDSEMU200-U) or a XDS560v2 (TMDSEMU560V2STM-U or TMDSEMU560V2STM-UE). The old XDS100v2 also supports Adaptive clocking, but its performance on ARM9 cores is too slow.

    Hope this helps,
    Rafael
  • 0 in reply to desouza
    Prodigy 245 points

    It's weird to hear this especially from you. About 2 years ago you posted a video on how to do it:

    Moreover, I saw somewhere on this forum that XDS110 & XDS110v3 could connect to the omap and XDS110v2 couldn't.

  • 0 in reply to Dmitry Kinyov59
    Prodigy 245 points

    Finally, I've managed to connect the Launcpad's XDS110 debug probe to the omap's JTAG. The problem was connected to the RESET output signal which was in Hi-Z state when deasserted. But on the LCDKOMAPL138 board the respective RESET input tied to GND through 4.7kOhm resistor.

    Probably, the special adapter has a pull-up resistor to 3.3V for this pin. But I did't have such an adaptor and connected these two boards with simple wires. That's why I have to add a pull-up circuit to the RESET pin.

    I hope, this info can be usefull to others who want to use a Launchpad's XDS110 debug functionality.

  • 0 in reply to Dmitry Kinyov59
    TI__Guru**** 168884 points
    Hi,

    Thanks for sending the additional details.

    If you look carefully to the problem at the other thread, there are simply too many steps to connect to the C674x core of the OMAPL138. Connecting to the ARM9 requires those steps plus the possible JTAG instabilities when changing the core's PLL frequency - steps that proved too frail and error prone when additional tests were done since then.

    Given all this, to prevent developers from running into problems that can delay their designs, our official stance must be on the conservative side. Adaptive clock cores are not properly and reliably supported by the XDS110 Debug Probe.

    Also, the XDS100v2 Debug Probe fully supports Adaptive Clocking and has been used at large over the years on this platform. The only report I recall seems to be restricted to an Olimex debug probe.
    e2e.ti.com/.../1613284

    Regards,
    Rafael
  • 0 in reply to desouza
    Prodigy 245 points

    Hi,

    I didn't face the problem connecting to the DSP core. Probably, the evolution of debug probes' firmware for the last 2 years played the role (I'm using CCSv9.0.1 & XDS110 fw ver. 2.3.0.18). There was an issue with the ARM core connection though. But I've managed to overcome it. I can connect to these two cores with a single button press ("F11" - start a debug session).

    But what really makes me pain is the debug pace on the ARM core. Unlike the debug of the DSP core (each step executes almost instantly), stepping over (F6 key) a program on the ARM core is taking few seconds per each step.

    I've compared it to the XDS100v2. The debug pace of the ARM core with this debug probe is much faster than with the XDS110 probe. Not as fast as the DSP core though but decent. I don't notice the difference in debug speed when changing the TCK clock limit. 

    For now we're considering purchasing an XDS100v3 debug probe. We expect to get a performance not worse than with the XDS100v2.