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/LAUNCHXL2-TMS57012: Slow single-stepping when using XDS110?

Part Number: LAUNCHXL2-TMS57012
Other Parts Discussed in Thread: SEGGER, LAUNCHXL2-RM46, TMDSEMU110-U

Tool/software: Code Composer Studio

I can confirm that this problem still exists with CCS V8.

We have a 3rd party debugger (Segger J-link), that one works lightning fast.

I attached the debug server log.6661.ds.zip

  • Hi,

    Thank you for reporting this. Despite I wasn't able to reproduce the issue in the other thread with the Cortex M4F device, I found out the step operations on my LAUNCHXL2-RM46 board is somewhat on the slow side. I am using Windows 10 1709 and CCSv8.1.0.00011, but in my case we have an IT-mandated software that is known to slow down CCS operations.

    Expecting a different outcome, I then tested two versions on a Windows 7/64 (7.3.0 and 8.1.0) without the offending software. However, the results were not much different. 

    In this case, I will file an enhancement request soon and report back with its entry number. 

    I apologize for the inconvenience,

    Rafael

  • Hi,

    I filed today the enhancement request DBGTRC-4108. I a few hours, please check it status in the link SDOWP in my signature below.

    I apologize for the inconvenience,
    Rafael
  • Thank you, I am waiting for the issue to be resolved.
    However, I can not log into SDOWP...
    On your video, the debug speed seems fairly acceptable. In our case, every step takes about 2-3 seconds.
    We are also using corporate IT managed PCs (Siemens), so the cause might also be some shady IT software running in the background.
  • Hi,

    SDOWP was experiencing some difficulties. It is online now.

    The videos above were shot with quite good host PC configurations: one core i7-6820HQ (2.67GHz), one core i7-3770 (3.40GHz) and both with 16GB RAM. No Antivirus or another disk-intensive activity was taking place during the recording and there was no other process using the CPU significantly (apart from CCS and the video capture software). The second video may have additional lag due to being connected via a Remote Desktop session.

    Since you are experiencing even slower performance, I would check the items I mentioned above and see if you can get some improvement. Also, double-check if the Eclipse Indexer is running on the projects of your workspace to see if there are any potential problems.

    Regarding the indexer, you can try to disable some relevant options.
    e2e.ti.com/.../2441873

    Despite the step operations were faster in my system, the enhancement request for optimization may still be useful as I can see it performing better on other cores such as Cortex A or M.

    Regards,
    Rafael
  • Meanwhile I tested the Launchpad debugging on a "clean" machine (no antivirus, no corporate-IT, Win7, fresh install of CCS V8.1).

    Sadly, I could not see any difference with the debugging speed - it is the same, painfully slow, taking 3-5 seconds to hit a breakpoint, and 1-3 seconds to single step.

    So I really don't understand why it so slow, when I can clearly see on your video that it can work OK...

  • Hi,

    Let me confirm one thing: when you mentioned that Jlink is fast, is it debugging the same device under CCS? Or it is connected to a different board/IDE?

    Also, do you have only the built-in XDS110 on the Launchpad board or are you using a standalone TMDSEMU110-U pod? These should have equal performance, but  I wonder if something may be different enough to cause this added delay.

    One last question: I suspect the firmware version is updated, but it doesn't hurt to try. If you issue the command xdsdfu -e from the directory mentioned below, you should have version 2.3.0.14.

    Microsoft Windows [Version 10.0.16299.492]
    (c) 2017 Microsoft Corporation. All rights reserved.
    
    C:\ti\ccsv8\ccs_base\common\uscif\xds110>xdsdfu -e
    
    USB Device Firmware Upgrade Utility
    Copyright (c) 2008-2018 Texas Instruments Incorporated.  All rights reserved.
    
    Scanning USB buses for supported XDS110 devices...
    
    
    <<<< Device 0 >>>>
    
    VID: 0x0451    PID: 0xbef3
    Device Name:   XDS110 Probe with CMSIS-DAP
    Version:       2.3.0.14
    Manufacturer:  Texas Instruments
    Serial Num:    00000000
    Mode:          Runtime
    
    Found 1 device.
    
    

    Regards,

    Rafael

  • HI!

    I am debugging the same device with the J-link, under the same project in CCS. I soldered the JTAG header J1 onto the Launchpad, and I just changed the target configuration. I only have the built-in XDS110 on the Launchpad.

    My firmware:

    Microsoft Windows [Version 6.1.7601]
    Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
    
    D:\ti\ccsv8\ccs_base\common\uscif\xds110>xdsdfu.exe -e
    
    USB Device Firmware Upgrade Utility
    Copyright (c) 2008-2018 Texas Instruments Incorporated.  All rights reserved.
    
    Scanning USB buses for supported XDS110 devices...
    
    
    <<<< Device 0 >>>>
    
    VID: 0x0451    PID: 0xbef3
    Device Name:   XDS110 Embed with CMSIS-DAP
    Version:       2.3.0.14
    Manufacturer:  Texas Instruments
    Serial Num:    HL512000
    Mode:          Runtime
    
    Found 1 device.
    
    D:\ti\ccsv8\ccs_base\common\uscif\xds110>

  • I am the poster of the original thread:

    e2e.ti.com/.../660958

    Just wanted to chime in and say that based on your description, your slow debugging issue appears identical to ours. Unfortunately, to date, we did not resolve this issue and the XDS110 is sitting unused. It is not feasible to use it for single-step debugging when the process is so slow.

    Hopefully, with the additional information you were able to provide, TI will be able to reproduce and solve the issue.
  • Hi,

    Thanks for sending the additional details; I will try to get a connector soldered today on my RM46 Launchpad and compare with my Jlink here. I am trying to get a baseline for the performance on this board. 

    As twelve12pm mentioned, this happens in certain systems but unfortunately we couldn't fully reproduce this here to the point of complete usability hindrance. 

    Regards,
    Rafael

  • Any updates on this?
  • Hi,

    I was finally able to find the time to solder the connector to my launchpad and I can see a significant improvement in the step operations when using Jlink on Cortex R5. This speed is comparable to the XDS200 as well, therefore there is a possibility the XDS110 may not have the same performance by design but the enhancement report is still in the queue for evaluation.

    twelve12pm, in your case I really can't reproduce the problem - for Cortex M4s I can't notice a significant difference.

    At any rate, I will keep you posted for these developments.

    Regards,
    Rafael