• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 359 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.

CODECOMPOSER: Unresponsive GUI (CCS 20.3)

Lars Stein
Prodigy 60 points
Part Number: CODECOMPOSER


Hello experts,

I'm using Code Composer Studio V20.3 for our firmware project.

Unfortunatly I'm facing some very annoying performance issues while working with the tool.
I was able to reproduce the following issue:

1. "Clean" restart of CCS
    - Removed "CCS" and "tirex" folder/cache from users appdata folder
    - Opened workspace/firmware folder
2. No performance issue is observable
3. Build system project and all dependencies

-> Now the performance issue is observable. 
By clicking on a project in the workspace explorer (to expand it) the GUI is unrespondable for multiple seconds! This happens also when clicking again to collapse it.

I did a performace recording with CCS developer tools which show the function which seems to block the IDE.

PerformanceRecord.png

The "refreshTree" task refers to "memory-allocation-view.tsx679:30" which is the following:
Code.png

The recorded task runs for ca. 7 seconds which matches the unresponsive time of the GUI.

Workaround attempts:

  • Restart IDE: Task runs now only for 3 seconds but GUI is still unresponsive for this amount of time
  • Delete all build artefacts (release, debug folder...) by hand without restarting the GUI: Task runs 7 seconds

Working but unacceptable workaround:

  • Delete all build artefacts AND restart IDE

 

This happens without ever using the "Memory Allocation" view which (I assume) uses the linkInfo.xml.

 

Is this a misconfiguration on my side? If yes, how can I fix it?
Is it a bug? Is there a better workaround?

 

Thanks for your help and best regards

Lars 

  • 0
    TI__Guru**** 473501 points

    Hello,

    Lars Stein said:
    This happens without ever using the "Memory Allocation" view which (I assume) uses the linkInfo.xml.

    I assume the memory allocation view is not open in the IDE.

    Do you notice this hang during the linking phase of the build for each project?

    If you build outside CCS from the command-line, do you notice any slowness in the build?

    https://software-dl.ti.com/ccs/esd/documents/users_guide_ccs/ccs_project-command-line.html#build-a-code-composer-studio-project

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 60 points

    Hi Ki,

    thanks for your quick response.

    Ki said:
    I assume the memory allocation view is not open in the IDE.

    You are right: the memory allocation view is not open.

    Ki said:
    Do you notice this hang during the linking phase of the build for each project?

    I removed all build artefacts and restart the GUI (workaround from previous post). During the build (invoked compiler) I expanded and collapsed various projects in the explorer view without a delay which is noticeable.
    When the linker was invoked the GUI slowed down and browsing in the explorer view was delayed. At this moment the perfornce recording revealed the "refreshTree" task again with runtimes between 3 and 7 seconds.

    Ki said:
    If you build outside CCS from the command-line, do you notice any slowness in the build?

    In general I don't observe any slowless in the build process via GUI. Nevertheless I did a command-line build (with removed build artefacts from previous build) which worked as expected without any slowness.
    In some rare cases I observed a complete linker hang-up which I even can not cancel via GUI. But I was not able to link this observation with described issue in this thread.
    In some other rare cases we observed a issue with the post build script which I also can not link with this unresponsiveness issue of the GUI.
    This both issues seem to be independant from this thread.

    After the command-line build I started the GUI again. Opening and collapsing the projects is slowed down again. The performance records says 2.7 seconds for the "refreshTree" task.

    New Info:

    Disabling the generation of the linkinfo.xml files via the project settings solves the issue. Cleaning the old build artefacts and rebuild the firmware without the linkinfo files leads to a GUI which works as expected.

    Obviously some functions are not working without the linkinfo files so this is just the best workaround for the moment...

  • 0 in reply to Lars Stein
    TI__Guru**** 473501 points

    Engineering informed me that this is a known issue. There is a plan to optimize this is a future CCS release (currently scheduled for 20.5.0). 

    Thanks

    ki