MCUX 10.2.1 - Debug launch freezes at 2% for about a minute

[dmarks_ls]

So this isn't a new problem with 10.2.1... to my recollection, this problem has existed for a few months at least.  The issue is that whenever I do a debug launch (green bug), on the bottom status bar, I see "Launching foo_bar ... Debug: (2%)" with a short green progress bar, and it just strobes away for a minute or two while the Console window is blank.  Nothing else seems to be happening in the IDE while it's at 2%.  After this lengthy delay, it finally jumps to 6%, does a build prior to launch, usually there's nothing to do for the build, and then it goes to launch GDB.  Happens with both PEMicro and SEGGER debug launches, and happens with each of two different Kinetis projects I'm currently working on.

The only time this doesn't happen is if this is the first time I've launched the debugger since starting MCUX.  In that case, clicking the green bug makes the progress go immediately to 6%, the pre-launch build happens, and then the debugger starts.  If I then terminate the debugger, and then click the green bug again, it sits at 2% for another minute or so, then goes to 6%, does the build, etc.

This is a bit of a productivity killer, having to wait a couple of minutes for no good reason each time I do a debug launch.  Any idea what's causing this pause where seemingly nothing is happening in the IDE?

(Win 10 Pro 1803 patched, MCUX 10.2.1, Kinetis K24 project)

[Ypi]

should be fixed in the version v11.0.1. We have version v11.5.0 and still have a problem. 

MCUXpresso freezes for minute when:

• open global variables (even without debugger)
• start debug when global variables window is open
• stop debug when global variables window is open

[lpcxpresso_supp]

The initial problem was surely fixed at that point. If I remember correctly, the original report was related to a C++ project with lots of global variables that required demangling. Looks like your use case is different. Is it a C or a C++ project? How many global variables are inside the app? Is there any chance we can have access to the ELF file?

Regards,

MCUXpresso IDE Support

[Ypi]

It's C and C++ project. I don't know how to easily find count of global variables, but if I add all variables in Expression window, there is 4000 rows of variables.

Yes I can send elf file, if it is used only to debug this problem. Where I can send it?

[lpcxpresso_supp]

Please attach the elf file in a new post on this thread.

Regards,

MCUXpresso IDE Support

[Ypi]

I don't want share it public.

-Janne

[lpcxpresso_supp]

Please give it a try with MCUXpresso IDE v11.6.0. There should be a visible performance improvement when ELF files with lots of globals are being debugged and Global Variables view is used. 

Regards,

MCUXpresso IDE Support

[ErichStyger]

Hi @Ypi ,

I don't use that window that often, but I see some lags (in the range of 5 secs or so) if opening that view. Not sure what is causing this, and why it is much longer for you.

I'm using Windows 10, just in case this matters.

Do you see that huge delay with a fresh workspace too?

[Ypi]

Hi @ErichStyger 

Good point. It happens only in large project. If I try smaller project in same workspace, the global variable window opens much faster.

[AndyCapon]

Ok, Here is the culprit:

 

[AndyCapon]

I know this is an old topic but I'm getting the issue with the Global Variables window here.

imxrt1170 EVK and MCUXpresso IDE v11.3.0 [Build 5222] [2021-01-11]

I was getting at least a minute of the spinning beachball on my mac with the IDE at 100%cpu or more, both on start and stop of debug.

Just making sure that the Global Variables window is not shown makes everything instant now.

Pleased I found this thread!

[lpcxpresso_supp · Accepted solution]

This issue should be resolved with MCUXpresso IDE v11.0.1:

• MCUXpresso IDE v11.0.1 Now Available 

Regards,

MCUXpresso IDE Support

[skearney]

Just wanted to mentioned that I had the exact same issue described in this thread, just stumbled upon this thread today and installing MCUXpresso 11.1.0 fixed it (I was on 11.0.0 before, so I skipped the patch). Thanks to NXP support for being very engaged with this thread and working to track this down and deliver the fix!

[lpcxpresso_supp]

We are still investigating this issue being triggered for you by the Global Variables view.

As part of this, we would be very interested to know whether you see any differences in behaviour at all with the recently released MCUXpresso IDE v11.0.0? There have been some subtle changes in the implementation used for accessing the symbols in this release, and we would like to know if these have helped (or not) in your particular case.

Regards,

MCUXpresso IDE Support

[dmarks_ls]

Also, it would be bloody useful if you had an announcement list for when new versions of MCUX are released.  I generally find out by accident, or if I just haven't looked in a while and decide to check out the download page.

[brendonslade]

Hi David,

Just wanted to comment that we are working on solutions for this(email notifications). Hopefully we will have something in place before the end of the year.

Regards,

Brendon

[dmarks_ls]

Thank you, this is something that's been sorely needed for some time.

David R.

[dmarks_ls]

It so happens that I have been busy reproducing my "C++ exceptions" issue today using a clean install of MCUX v11.0.0, and I can confirm that the debug launch delay issue still persists in version 11.0.0.  Killing the global variables tab before launching debug removes the delay, so the same mitigation strategy applies..

(And yes, the C++ exception issue persists as well.)

[lpcxpresso_supp]

Glad to hear that closing the Global Variables view helps - at least we now have a specific area to directly investigate. Have you actually got any variables added in the Global Variables view or is it empty?

I must admit, I wouldn't have expected the view to automatically reopen if closed, so we'll take a look into that too.

Regards,

MCUXpresso IDE Support

[dmarks_ls]

Nope, I've never used that view, I've never put any variables into it.  Couldn't have told you it was there before today.  And yes, what I see here is, I kill the GV tab, then start my debug launch.  I still have the automatic build disabled, so it skips right to loading the firmware into the device; since I'm using a SEGGER J-Link, the window with four bar graphs appears, showing compare, erase, program, and verify.  Once that window disappears, the call stack appears in the Debug tab, and at the same time, the Global Variables tab re-appears in the block of tabs it was in previously.

So yeah, if you can stop it from bringing itself back every time, that'd be handy.

[BlackNight]

Eclipse rememers the layout of the views and which views are open inside the perspective. That it always opens for you the Global Variables view even if you have closed is something I have not seen and I was not able to reproduce.

What perspective are you using for debugging? The 'Develop' or the 'Debug' perspective.

What might help is to reset the perspective to the default. See Help - Eclipse Platform 

If you are using the 'Develop' perspective: this one dynamically adopts depending on if you are editing or debugging and it changes the layout automatically. What might help (at least to try this) is to use a different (the normal Debug) perspective.

See Using a Custom Debug Perspective in Eclipse | MCU on Eclipse   how you can change the settings for this. Then make sure that you don't have the Global Variables view open in that Debug perspective.

I hope this helps,

Erich