• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 1386 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.

CCS/TMS320F28377D: Progress information window pop-up getting stuck, "Updating view contribution" hangs with no progress on progress bar.

Susan Beiter78
Intellectual 660 points
Part Number: TMS320F28377D

Tool/software: Code Composer Studio

Intermittently I get a pop-up window when in the Debugger in CCS v7 - the window title is "Progress Information", and it says "Updating Windows" above a progress bar, and below the progress bar it says "Updating view contribution."  This pop-up window continually comes and goes from the CCS screen, prohibiting any other activity but not clearly doing anything. I don't know what I am doing to cause this pop-up, but it sometimes goes away after flashing a few dozen times and sometimes gets stuck that way "forever" until I kill CCS and restart it.

I was willing to live with the behavior, but now I'm trying to Skype into a co-workers setup to set some breakpoints and do some debugging, and his is doing it, too.  Is this a known problem?  Is there a fix?  Is there something we can do differently to turn off the view contribution update?

  • 0
    Intellectual 660 points
    I should maybe also say that it seems to happen a lot more when playing with breakpoints?
  • 0
    TI__Guru**** 173310 points

    Susan,

    This has been reported previously a couple of times on the forums, but we were not able to reproduce locally and no definitive root cause was identified.

    In one thread a CCS reinstall fixed the behavior. In another, the behavior disappeared on its own. If you find this happening consistently, could you please send us the workspace .log file from your workspace .metadata directory?

  • 0 in reply to AartiG
    Intellectual 660 points
    Sure - how do I get you my .log file? If you mean can I post it here on the forum, I guess I need to know if there is anything in it that would be risky for me to share from an IT perspective? Or perhaps there is another way to share it?
  • 0 in reply to Susan Beiter78
    TI__Guru**** 173310 points

    Yes you can attach it to your reply. To attach files, click on the link to "Insert Code, Attach Files and more" when writing your reply. Then use the paper clip icon to attach files.

    You can view the .log file and decide for yourself, but there shouldn't be anything in it that is risky to share.  If you still prefer to share it privately rather than post here, you can send me a private message by hovering over my username. 

  • 0 in reply to AartiG
    Intellectual 660 points
    I couldn't find anything that I considered risky in the log file, but it is 10K lines and 3 months of logging. I tried to email it, but the message system gave me errors twice. Could the log be too big, and if so, would maybe just the last 30 days of it be enough to share?
  • 0 in reply to Susan Beiter78
    TI__Guru**** 173310 points

    Susan Beiter78 said:
    Could the log be too big, and if so, would maybe just the last 30 days of it be enough to share?

    Yes the last several days of logging should be sufficient, as long as you hit the issue today or in the last few days.

    Another suggestion (probably a better one) would be to open a new workspace, import your project into it and go through similar debugging steps (working with breakpoints etc) and see if you encounter the same behavior. If so, send us the workspace log for that workspace (should be much smaller as it would be newly created). If you do not see the issue, it was probably some corruption in the older workspace.

  • 0 in reply to AartiG
    TI__Guru**** 173310 points
    Susan,

    Since I haven’t heard back from you, I'm assuming you were able to move past this issue and will be closing this thread. If you wish to continue the discussion, feel free to post a reply with an update below (or create a new thread).
  • 0 in reply to AartiG
    Expert 1680 points

    Hello All:

    I want to add a "me too" paragraph.

    I am using Win7 SP1 (32bit). CCS 6.1.3. F28022.

    For me, this has been happening on and off since I started with CCS6. (I jumped straight from CCS3 so I can't speak about CCS4 or 5.)

    I find this happens when I have a lot of debugging windows open, and a lot of other stuff going on other then CCS.

    In my case, the debugger perspective has 6 windows open on other monitors (I have 5), and in CCS proper, there are a total of 10 tabs in 4 different windows.

    Also, I note this will happen more often when I have a lot of other stuff going on in Windows. For example, I may be viewing a PDF or 2, have 2 different Code::Blocks sessions, one may be actively debugging, and also Firefox with several tabs open.

    I do not know how CCS (Eclipse, really) works, but here is a "gut feeling" I have since I started playing with Python and Tkinter (I think Eclipse uses WX, but I'll bet it is very similar to Tkinter.)

    During compilation, when things change, some signal(s) gets sent to all the open windows to "repaint" themselves. If the repaint happens in a timely manner, the window telling you what is is doing it gets suppressed. But if it takes a long time for the window to repaint, the underlying code (WX, Tkinter, or other windows generator) will popup a window telling you what is going on.

    I note if I close a lot of the time/memory consuming other processors (mostly Firefox) the issue seems to go away.

    One thing, Since I am running a 32 bit Windows, I only have 4G of RAM (3 usable), and if left to it's own, Firefox is a real hog. I think some stuff gets paged out, even some of CCS code further slowing the compilation process.

    Of course, I may be way off, but I do know Tkinter will do things like repaint windows after some number of seconds to prevent the repainting after each and every byte. It cuts down on a lot of unnecessary monitor IO.

    Susan, Have you noticed if you have a lot of background stuff going on when this occurs? I suspect most programmers do.

    Mark.