MCUX 11.0.0 - Variables view has blank contents

[dmarks_ls]

(EDIT -- This thread was previously titled "MCUX 11.0.0 - 'this' not visible in Variables view", but it was eventually pointed out (derp) that static methods have no "this" pointer available.  However, in the course of investigating this issue, I discovered that the Variables view would often appear with blank contents.  The original thread appears below; the comments with screenshots show the issue with blank Variables view data.)

TL;DR - "this" no longer appears in the Variables view when debugging a C++ class.

So, I've pulled down MCUX v11.0.0 and installed it... I've also grabbed SDK v2.6.0 for the RT1050.  I created a brand new workspace, set my templates and code style, set my hotkeys, installed the SDK, created a new C++ application, picked all the middleware, merged in all my previous application code, merged in my preprocessor defines and include directories, and after a bit of fiddling, got my "new" application to build.  It even downloaded and ran the first time, which I'm thankful for.

However, my code got hung up during initialization, hmm.  So I drill in with the debugger:

Now, upon reflection, I understand why this function failed... I haven't yet gone in and re-arranged the heap, stack, and data segments, so they're still pointing to internal SRAM, and I'm pretty sure the heap just ran out of memory, thus yielding a null pointer.

But what concerns me is the Variables view.  I'm in the NxpLpi2c::CreateInstance() method, which means I'm inside the NxpLpi2c class.  When I've debugged with MCUX in the past, there's always been a "this" symbol automatically added to the Variables view when debugging C++ methods.  So... where did it go?  It is invaluable to have access to the current object in the Variables view.  Please tell me this is an easily remedied oversight.  Thanks.

[lpcxpresso_supp]

The problem with the Live Variables service that was triggering this issue should be resolved with MCUXpresso IDE v11.0.1:

• MCUXpresso IDE v11.0.1 Now Available 

Regards,

MCUXpresso IDE Support

[Keith4DSmith]

Thank you for the update.

When I go to the download page for V11, https://nxp.flexnetoperations.com/control/frse/download?element=11239507 , which lists Mac, Linux, and Windows version, the release notes for 11 are listed as a PDF. When I click on this file I get the release notes for 10.3.

MCUXpresso IDE

========================= Version 10.3.1 (Feb 2019) =========================

* Improvements to support for i.MX RT600 MCUs *

I cannot find 11.x anywhere in the document

Did I do something wrong?

[lpcxpresso_supp]

I wouldn't expect to find the release notes in Flexera (I'll ping the web team about this). The 11.0.1 release notes can be found on the IDE documentation page though : https://www.nxp.com/mcuxpresso/ide/documentation.

However the information on the v11.0.1 release in the release notes is just the same as contained in our  blog:

• https://community.nxp.com/community/mcuxpresso/mcuxpresso-ide/blog/2019/09/04/mcuxpresso-ide-v1101-n... 

Regards,

MCUXpresso IDE Support

[dmarks_ls]

lpcxpresso_support‌,

Thank you, looks like there's several quality-of-life fixes in this version.  Is there any way that I can get a notification of some kind whenever a new MCUX IDE or SDK version is released?  Some list I can subscribe to?  I've often gone weeks or months in development before randomly checking websites and discovering, oh, hey, new version released that could have made my life a lot easier had I known about it earlier.  Thanks.

David R.

[BlackNight]

Hi David,

one way is to follow the forum:

I hope this helps,

Erich

PS: Or you might follow my blog where I usually write about new releases (e.g. NXP MCUXpresso IDE 11.0.1 available | MCU on Eclipse), or about all and everything the Embedded end Eclipse world, or even beyond :-).

[dmarks_ls]

So the answer is "no", then.  I tried following one of the subforums, and now I'm getting emails for each individual post and comment in the subforum.  So either I turn on the fire hose of notifications for an entire subforum, or nothing.  I'll take nothing, thanks.

Really, would it be that hard for NXP to set up a notification list for its software and tools?  ARM mbed does it.  TI does it.  Renesas Synergy does it.  IAR does it.  Silicon Labs does it.  This is a shortcoming on NXP's part.

EDIT: So it seems that NXP does have a notification mechanism for updates, but it is inconsistent and inadequate.  If I search for emails from "nxp@flexnetoperations.com", I see some Software Notification emails, including one for the 11.0.1 release.  The next previous MCUX email was for 10.2.1, then 10.1.1... I think I see the problem.  Your MCUXpresso IDE software appears in Flexnet under a main heading, say, MCUXpresso IDE 11.0.  If I go and download 11.0.0, and then you release an update in that same version family (e.g. 11.0.1), I get a notification that a minor update was released, because Flexnet sees that I previously downloaded 11.0 and you released an update against it.  But if you then release MCUXpresso IDE 11.1 at some point, I won't get a notification for that, because it's a new software item, i.e. it appears in its own heading.  So this doesn't solve the problem of announcing new IDE software releases, and doesn't address new SDK software releases, either.

[lpcxpresso_supp · Accepted solution]

Emphasizing that the problem can be replicated only on v11.0.0 is probably a very important aspect. And we're still looking into the issues reported. However, for everyone experiencing problems with Variables or Expressions views, please try disabling "Live Variables" service when using PEMicro/JLink probes. This can be achieved by going to Window => Preferences => Expand "MCUXpresso IDE" categoy => Select "J-Link Options" or "PEMicro Options => Uncheck "Enable Live Variables service".

Greetings,

MCUXpresso IDE Support

[nxp16]

Unfortunately, this still happens in MCUxpresso 11.1 using LinkServer debug (which doesn't have the option to turn off Live Variables), on an IMXRT1060 evk board.  Everything in the Expression view is blank until I click on one of the array elements.  No matter what I do the parent names never show up.

[lpcxpresso_supp]

First of all, your screenshot illustrates a problem with regards to some views. Note the red square icon associated with Global Variables and Heap and Stack views. It's a sign that you're reusing a workspace created with an older version of MCUXpresso. So those view cannot be used in their current state. I recommend switching to a new workspace.

Secondly, please mention the actual expression you added in the Expressions view. I tried to reproduce the problem with the same project but on an IMXRT1064-EVK board. Everything works as expected. Would you please try adding that expression in the Global Variables view and check if you still see the issue?

Greetings,
MCUXpresso IDE Support

[marcoh]

Unchecking "Enable Live Variables service" returned the functionality of the variables tab on my 11.0 installation. 

Marco

[Keith4DSmith]

I will also confirm that disabling Live Variables Service has gotten me past the debugging issue with 11.0

My projects were from 10.3

[dmarks_ls]

I can confirm that disabling "Live Variables" restores my debug functionality, which means I should be able to use MCUX 11 again.  Sounds like the Live Variables feature needs to go back to the lab; it's not ready for primetime.  My gut impression is that Live Variables was completely bogging down the debugger, to the point where single step commands would simply fail to execute.  I don't know what benefit that feature is supposed to provide, but clearly the feature is broken for many of us.

[jaylarson]

This workaround (disabling the Live Variables Service) has worked for me after a quick test on my FRDM-K66F board.  The Segger OpenSDA firmware I am using is the latest from 2019-06-03.  Enable the live variables checkbox, it doesn't work.  uncheck the option, and debug seems to be back to normal, just like version 10.3.  Hope you are able to reproduce this behaviour yourselves and that it will lead to a quick fix. 

Cheers,

-Jay

[Toe]

I have to say the same thing happened to me.  I switched back to 10.3 until seeing this post.  Unchecking "Enable Live Variables service" returned the functionality of the variables tab, Expressions tab, and hovering over expressions.

All of my projects are C (not C++) and all were initially created in an older version of MCUXpresso.

[lpcxpresso_supp]

I would just like to reassure you that we are actively looking into this issue of the Variables view being blank for some users. Once we know more, we will report back.

Regards,

MCUXpresso IDE Support

[dmarks_ls]

So, further update... on the advice of Harald Adolph and Jay Larson above, I created a new MCUX 10.3.0 workspace, pulled a fresh copy of my project from SVN, managed to get a pre-2.6.0 K66 SDK from my co-worker (fun fact: can't build older SDKs with MCUX), got my project compiled, shift-clicked the blue bug, launched the debugger, set my breakpoint, triggered the test routine, and...

Lookie there... the Variables tab works just fine.  Debugger is relatively snappy and responsive with step into/step over actions.  (The Global Variables tab still takes a very long time to draw if you click on it, and basically freezes the IDE while it does this.  I just middle-click it to close it without even switching to it.)

So, there's my workaround... stop using MCUX 11.0.0 and continue to use 10.3.0 until such time as NXP decides they want to get to the bottom of this.  We'll see.

[dmarks_ls]

One additional workaround that's required... MCUX 10.3.0 is afflicted by the bug where MCUX can no longer find the standard C or C++ headers, which breaks the Eclipse indexer (but still allows code to compile).  In order to fix the indexer, I added the include file paths directly to my project.  For "MCU C++ Compiler", add these include paths (for Windows):

"C:\NXP\MCUXpressoIDE_10.3.0_2200\ide\tools\arm-none-eabi\include\c++\7.3.1"
"C:\NXP\MCUXpressoIDE_10.3.0_2200\ide\tools\arm-none-eabi\include"
"C:\NXP\MCUXpressoIDE_10.3.0_2200\ide\tools\lib\gcc\arm-none-eabi\7.3.1\include"‍‍‍‍‍‍‍‍‍

And for "MCU C Compiler", add these include paths:

"C:\NXP\MCUXpressoIDE_10.3.0_2200\ide\tools\arm-none-eabi\include"
"C:\NXP\MCUXpressoIDE_10.3.0_2200\ide\tools\lib\gcc\arm-none-eabi\7.3.1\include"‍‍‍‍‍‍

I tried using the variable ${ECLIPSE_HOME} as a substitute for the "C:\NXP\MCUXpressoIDE_10.3.0_2200\ide\" portion of the path, but 1) that apparently doesn't resolve to anything in the include paths, and 2) Eclipse immediately wants to make such an entry workspace-relative, which defeats the purpose.  Anyway, with a working debugger and a working C++ indexer, I can actually get back to coding for a while.

EDIT: I discovered that this creates a CRAZY amount of warnings about "__NEWLIB__" being redefined.  Frankly, I don't understand why __NEWLIB__ is being emitted on the command line.  And if I delete __NEWLIB__ from the preprocessor defines, something in the IDE immediately reinserts it.  But, since the warning is always generated from the same source file, only one entry is generated in "Problems", so I can live with it until MCUX 11.0.0 gets fixed.

[dmarks_ls]

Look, I'm gonna go on a bit of a rant here... if you're not interested in that, please skip this reply.  NXP, I hope you take the time to read this.

I am frustrated as hell right now.  I have an application sitting here on my K66 FRDM board that I can't debug.  This is an SDK 2.6.0 C++ app built using MCUX 11.0.0.  I'm using the built-in J-Link OpenSDA adapter.  I have one, ONE breakpoint set in my code, a single test function for my DSPI driver.  I have the FreeRTOS plugin disabled, because the debugger seems to crawl even worse when it's enabled.  I download and start my app, then press a key on my serial console to trigger the test function.  The debugger lands and pauses on the breakpoint, and in the Variables window I see... nothing.  Well, not nothing... I see two right-chevrons, as if the IDE knows that there are two structures/objects to show, but it can't fill anything in.  I let the IDE sit there for about a minute or so, on the off-chance that it might decide to drawn the window contents after all.  Nothing.  So I press F5 to step into the function I'm stopped on.  Nothing.  I click the green Resume arrow at the top.  Nothing.  The debugger has silently died.  I shut down MCUX, fire up Chrome, and log into the NXP forums to write this response.

What exactly am I supposed to do here?  NXP, you say you can't reproduce it on your end.  I CAN.  EVERY TIME.  Frankly, I don't care that you can't reproduce this, because this is happening to ME, RIGHT NOW, on my Saturday where I was hoping to get caught up on things.  Instead, I'm sitting here with a driver that... mostly works? but isn't quite right, and I can't get into my code and actually see what's happening.  An IDE without a debugger is just an editor, and that's not doing me any good right now.  And as you've seen in the replies to this thread and other related threads, I'm not the only one encountering this issue.

I can imagine some folks saying "Hey, MCUXpresso is free, it works for most everyone, lay off."  I don't agree with that at all.  NXP is in the business of selling chips, yes, but like many other chipmakers they realize (rightly so) that they need to provide an ecosystem of drivers and tools to facilitate the design of those chips into products, instead of leaving that to third parties.  The MCUXpresso IDE and SDK is a useful evolution of their toolchain, and NXP needs MCUXpresso to be a strong and stable toolchain... I mean, it has to work, otherwise what's the point of putting out a toolchain?  So when crippling issues like this arise, it doesn't do me one bit of good for NXP to shrug and say "sorry, we don't see it", with the implication being "we can't help you".

You can always help.  It just depends on how willing you are to work with a given customer.  And this is where I feel really small, kinda microscopic.  I don't work for a big OEM.  I'm not designing a widget that's going to sell five million units next year.  I can't have my boss call your boss and say "hey, these tools aren't working, why are we buying your chips again?"  I work for an independent design firm with five engineers on staff.  So the amount of pull I have with NXP is basically nil.  My only recourse is to jump on the forums, write something up, and hope that someone out there has some idea what the solution might be.

NXP, I'm right here.  I have an installation of MCUX 11.0.0 on my machine and a FRDM-K66F kit, and I can reproduce this issue every. damn. time.  Do you want to work with me to resolve this?  Then contact me, you know how.  Because right now, this is kinda killing me.  I don't have many practical alternatives.  Yes, we have a seat of IAR Embedded Workbench for Cortex-M, but oh do I hate their editor (Eclipse is king for C++ development), and of course there's no integration with MCU Config Tools or SDK examples or any of that.  So as my project presently stands, I'm limited to simple breakpointing and debugging via printf().  I can't meet my milestones if that's all I can rely on.

Do you want to work with me to investigate this issue?  Or do I simply pray that the next MCUX release somehow fixes this issue?  I'll help you make MCUXpresso better, but you've got to work with me here.  Thank you for reading this.

David R.

[jaylarson]

Hi David,

For what it's worth, I'm seeing the same issues with the non-displaying variables tab.  On a simple hello World app on the FRDMK66 board it shows the same symptoms.  3 auto variables are present, but won't display.  I can select the 3 rows, but when I tried to copy them with a right click copy the tab display hangs with a spinning wheel.  

NXP should definitely be escalating this issue to try and understand what is happening.  Saying, "we can't reproduce here" is not helpful at all.

They should be making sure that they are using all the same versions of the many components as we are.  They should be offering to have a developer try to remotely debug one of these machines.  

Luckily, I still have the previous version installed and can use that.

Good Luck!

-Jay

[dmarks_ls]

"They should be offering to have a developer try to remotely debug one of these machines."

EXACTLY.  That's really what I meant by "You can always help.  It just depends on how willing you are to work with a given customer."  We've been developing with NXP/Freescale for 10+ years, and I've been engaged with their support for all of that time... yes, trying to get our stuff fixed, but also making sure that the toolchain and libraries are improved for everyone else.  I lamented the day when they terminated ticket-based support for MQX and CW for MCUs, but I can see the utility of these forums.  To their credit, NXP does engage well with the forums; the situation would be a lot worse if it were just a bunch of users complaining with no NXP engagement.

MCUX is shaping up to be a great IDE and library solution, but an unstable and inoperative debugger just kills any benefits.