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)
Solved! Go to Solution.
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!
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!
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.
MCUXpresso IDE Support
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.
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.
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.)
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.
MCUXpresso IDE Support
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.
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,
So, I tried resetting the Debug perspective (yes, that's the perspective I use when debugging). I then started a debug session, it went right into debugger launch, SEGGER programming window came up, chugged, then went away, and the Debug tab then showed the GDB hierarchy. But also, tabs immediately appeared in the lower tab group (console, etc) for:
And in the top-right tab group (breakpoints, etc) for:
So something is actively stuffing those modules into the Debug perspective when a debug session is launched. I tried what you suggested... I reset the Debug perspective, then saved the perspective as "Debug (Custom)". Then I went into Preferences / Run/Debug / Perspectives, and I set "C/C++ (NXP) MCU Application", "GDB PEMicro Interface Debugging", and "GDB SEGGER Interface Debugging" to use "Debug (Custom)" instead of "Debug" when launching. And hey, how about that, MCUX didn't add those extra tabs to my custom perspective the next time I launched.
So that's the issue mitigated, for me at least. Now we just need to figure out why launching the Global Variables tab is so damn slow with C++ projects, to make sure it doesn't affect any other users.
Well done, I think you've isolated it. It's the Global Variables view that's mucking things up.
I did all three of those items above (breakpoints window was already empty, closed all unneeded views, and recreated my launch file) and launched a debug... went straight into debug, great. Terminated, then immediately restarted... and it sat at 2% again. While it was sitting there, I saw that the "Global Variables" view had re-inserted itself into the lower tab group, so I clicked to look at it... the cursor went into a spin-wait and the GV window contents didn't draw until the 2% delay was done. Hmm. Terminate, kill the GV tab, relaunch... no delay. BUT, the GV tab re-inserted itself into the lower tab group again. So, kill the GV tab, relaunch, no delay. Terminate, kill the GV tab again, relaunch... no delay. Terminate, leave the GV tab in place, relaunch... long delay. So it's definitely the Global Variables tab creating the delay.
On some level, I guess I can understand why the GV view would take a long time to initialize. My C++ program is currently 550 KB in size, so there's a lot of C++ symbols to sift through. We haven't done any large C-only projects recently, so I really don't have a comparison to see what a ~500 KB C program would do in the same situation.
So... how do we solve or mitigate this? It's annoying that I now have to remember to kill the GV tab every time I debug, or suffer the time penalty on my next launch if I forget to do so, since the GV tab re-opens itself during every debug launch. One mitigation would be to suppress the re-launching of the Global Variables view each time; not sure if that's selectable in Preferences. The fix, if it's possible, would be to somehow make launching the Global Variables view much quicker, without spending 1-2 minutes invoking the C++ name demangler. Ideas?
@David - The thing about "arm-none-eabi-c++filt.exe" (the C++ name demangling tool) is interesting. We'll investigate. But this does make it sounds like your issue may actually be different to Harald's.
One other thing to try in the meantime might be to turn off the IDE's automated "build before debug" functionality. And then build manually yourself before you then click Debug. The easiest way to do this is untick the "Build (if required) before launching" option in:
Does this make any difference to the behaviour that you see?
MCUXpresso IDE Support
OK, tried that, and the only thing that changed is that the IDE bypasses the build and goes straight to debug launch. The delay at 2% is still there, and "arm-none-eabi-c++filt.exe" is still being invoked for the duration of that delay. The console is empty during the 2% delay, and only fills when the build starts or the debug launch begins. And can again confirm, it doesn't happen on the first debug launch after starting the IDE, only on the second and subsequent launches.
I'm glad to hear that things are now at least working better for you.
When you do see the problem again, then if you are able to supply any of the information we asked about in our previous post (https://community.nxp.com/thread/488000#comment-1149907), or else try to narrow down what other things in your system **might** be contributing, then that might gives us some clues as to what exactly is happening in your particular setup.
MCUXpresso IDE Support
Hi there, OP here... I've been busy in development, but I have some time to come up for air and see if maybe we can figure this out.
My test setup is Windows 10 1803, with a SEGGER J-Link Pro running the latest firmware as of J-Link v6.46, and MCUX 10.3.1. Target is an RT1050 EVKB (yes, I have the OpenSDA debugger disconnected from the chip). I'm running ESET Endpoint Antivirus, but for the test below, I had real-time protection disabled.
So, first up... I tried turning off debug probe detection for all probe types. No effect... second and subsequent debug launches still take a lot of time. Then I started snooping the Task Manager to see if there were any lingering debug processes, as you suggested. I did find it peculiar that mcuxpressoide.exe was coming and going from the Processes / Apps listing while the debug was launching, and was absent from the list during one particular run, even though the IDE was clearly still running.
Then I switched over to the Details tab so I could get a proper alphabetical listing of all running processes. And while the IDE was showing 2% for the debug launch, I saw one particular process appearing, disappearing, and changing process number for the entire time that the progress was stuck at 2%:
That "arm-none-eabi-c++filt.exe" process seemingly launched dozens of times while the IDE was stuck at 2%. Once the value ticked up to 6%, that process went away, the IDE did one final "make", and then the J-Link GDB server process launched.
So maybe I've answered the question of what is taking up time during the debug launch, and perhaps why it's only afflicting my C++ projects. Can you help with the answer of why this process is running? What is it actually doing? And why does it only run on the second and subsequent debug launches after starting the IDE?
Hi all, so after many trials and buying a JLink basic adapter, I can say that this configuration is the most stable up to now.
It's not 100% stable, but you can start and really use the debugger maybe about 50 times without interruption.
If it stops at 2% - yeah, it happens with this box, too - it helps to close MCUXpresso, and after a restart you can go on with the next 50 trials.
This is a method I can "survive" with. So, PEMicro - both debuggers, the standard as well as the FX - seems to be the second solution at least in my case.
Thanks for the support.