Blue debug button irregular behavior

[scottm]

I've asked about this before, but it got buried.  I'm going to try to keep my posts to a single issue each and work through them one at a time.

The MCUX docs say I'm not supposed to use the green debug button.  I often haven't had a choice because the blue one hasn't always worked in the past.  It's working now, mostly, but this doesn't seem like it should be the standard behavior:

Dropbox - 2018-08-10 12-34-39.mp4 

The first issue is that it makes me choose the configuration I want each time, which is a little annoying.  Hitting F11 is a lot faster.  More annoying is the fact that the screen layout doesn't let me see which configuration is which - it can display about 9 characters for each name.

It pauses for a few seconds after that, and then asks AGAIN for the configuration, this time with only the P&E options shown.  After that it starts.  When I halt and run through the exact same thing again, it takes even longer and this time it comes up with the probe selection, too - which still shows two copies of the same P&E Cyclone ACP despite all of my efforts to get rid of the duplicate.

What's the deal?  Does it do this for everyone?

Scott

[lpcxpresso_supp]

We see MCUXpresso IDE being successfully used by customers with a team of 1 with maybe <100 source files. And we equally see it being used by customers with >100 seats and many thousands of source files.

But your usage at times does seem slightly different to what we commonly see, from what we see in your questions and comments - for instance the way you use launch configurations and installing lots of additional plugins. And sometimes you are also trying to use the MCUXpresso IDE in ways you have evolved from using older toolchains - and sometimes those naturally translate across to MCUXpresso IDE, and sometime they don't.

But at the end of the day you are obviously trying to explore every possible way of using the IDE to develop and debug your application. And that is all we meant by "power user". Lots of customers will be doing some of the things you do. But most won't don't seem to do everything you appear to have been trying.

With regards to Win8, we test on this platform but it is fair to say that it is no longer used as a mainstream development platform within the MCUXpresso IDE team (none of our engineers use it on their main personal machines any more). Our testing of the IDE in general hasn't really shown up any Win8 vs Win10 issues though. But as for whether you should upgrade, that's not something I feel we can answer. That is a much more general Windows question for which there is lots of info on the web.

With regards to most common debug probe we see being used - that really depends upon all manner of factors. For instance, customers who already have a J-Link or P&E probe from previous projects often just carry on using it. We see a lot of LPC-Link2's being used too, especially for customers from an LPC background. But increasingly also with Kinetis and i.MX RT too - as LPC-Link2 are cheap and much faster than the OpenSDA cmsis-dap (DAP-Link) probes currently built into FRDM boards.

And for us, LPC-Link2 is the most tightly integrated into the IDE because we have supported it for much longer and the IDE team are responsible for the whole debug chain from the IDE down to the target (including the NXP CMSIS-DAP firmware implementation used for LPC-Link2). But we are definitely striving to ensure that all probe types are supported to the same level wherever possible. Hence we added ETB/MTB instruction trace support for P&E and SEGGER in IDE v10.2.1, and we will be adding other functionality currently only possible with LPC-Link2/LinkServer connections in future releases too.

Regards,

MCUXpresso IDE Support

[scottm]

(Forgot some answers earlier...)

 installing lots of additional plugins

I'm always of two minds about this.  I don't want to complicate things unnecessarily and introduce compatibility problems, but one of the big attractions of MCUX (and it says as much in the manual) is that it does have lots of useful plugins available.  I'm trying to avoid things that touch the toolchain or debugger, but even then - the Darkest Dark theme breaking the gdb console was something I didn't expect.  There's always potential for things to go wrong and it's a trade-off between trying to work within the confines of the vanilla IDE and having to troubleshoot additional software interactions.  It's great that I can do my front-end web development for IoT devices within MCUX with the Eclipse web tools, but I understand it's unreasonable to expect NXP to explicitly accommodate that sort of thing and I'm going to be on my own with some of it.  It'd be nice if we had a little more active power user community to cover that stuff.  Erich's blog is still my top resource.

As for my launch configurations, I don't think my setup is unnecessarily complex.  I do have some duplication between the two probes, because they each have their strengths - and their bad days.  A single project might have three different variants with differences in pinouts and features compiled in to support three related products.  Each variant has build and launch configurations for debug and release, and sometimes a launch configuration for 'attach' mode.  And they all include a bootloader, so there's a flash range protection in use to keep from wiping that out, and sometimes an additional executable if I need to debug interactions with the bootloader.

That does seem more complex than a lot of applications, but not so much that it ought to be pushing the envelope.  And it's better than the alternative - I've taken over a formerly-competing project and for three production hardware variations there's a single build configuration (in Atmel Design Studio) and some mystery combination of DEFINEs to be set manually to build each variant.  I'll switch to plain Eclipse with gcc and make before I abandon good programming practice to that degree.

Scott

[scottm]

Thanks for the detailed reply.

Our testing of the IDE in general hasn't really shown up any Win8 vs Win10 issues though. But as for whether you should upgrade, that's not something I feel we can answer.

As long as Win 10 isn't worse for MCUX, that's good enough for me.  It's my least-favorite Windows since ME.

And sometimes you are also trying to use the MCUXpresso IDE in ways you have evolved from using older toolchains

That's fair.  And I seem to have a knack for picking the next IDE, SDK, or code generation tool to be abandoned.  I'm thrilled that MCUX has so far kept up with modern Eclipse releases, when CodeWarrior is stuck on a dead end.  Choosing to try to keep up with the current tools (and carry over old projects) does add some extra pain, though.

Lots of customers will be doing some of the things you do. But most won't don't seem to do everything you appear to have been trying.

Well, most people probably have bosses that try to keep a handle on scope creep.  This is what you get when a programmer runs the company.  :smileywink:

For instance, customers who already have a J-Link or P&E probe from previous projects often just carry on using it.

I spent some time yesterday removing every debug probe driver from my system and starting from scratch, reloading MCUX as well.  Carrying over my old stuff is a source of some of my problems, I'm sure - to simplify things I'm keeping all of the older BDM and MON08 probes off of this machine. I also have IDEs from SiLabs, Atmel, and Altera and everything comes with its own drivers, it seems.

I see there's an 'Advanced Debugging with MCUXpresso IDE' session coming up in Irvine in a couple of weeks which I'd love to attend, but alas it's right in the middle of my vacation.  I really hope this comes back around again.  It'd help a lot to sit down with known-good hardware and software and get a baseline for how it's all supposed to work.

Thanks,

Scott

[lpcxpresso_supp]

Hi Scott,

thanks for reporting.

For "normal users", a particular project and its various build configurations will always be debugged with a particular debug probe, using a particular set of debug configuration options. And that is what the MCUXpresso IDE specific "blue" Debug button is intended to provide.

This is as described in the MCUXpresso IDE v10.2 User Guide - in particular chapter 4 ("Debug Solutions Overview") and chapter 11 ("Debugging a Project").

But basically this means that for normal users, all the need to do is connect their probe and click on the blue Debug button, and everything should just work - without any need for manual setup or configuration.

And in the case where you want to be able to debug with different probes at different times, you can still do this - by either using SHIFT combined with the blue debug button (to force probe discovery again), or potentially using the Debug Quickstart shortcut buttons to force the use of a particular probe.

So things get more complicated for "power users" such as yourself - where you appear to have generated multiple debug launch configurations for multiple probes for each build configuration. [In our experience this is not a common thing that users do.]

So what you are seeing happen when you click on the blue Debug button is that the IDE scans the available launch configurations (those with the id's that the IDE recognise) and determines that there are multiple possible launch configurations it could use for this build configuration. So it prompts you to select one.

Now the "problem" you are then seeing with it prompting you a second time is actually a real issue, that is actually to do with the binary to be used for the debug session - rather than the launch configuration per se. We will investigate fixing this, as well as clarifying the message displayed in such circumstances in a future IDE release.

Note that in your sort of circumstance, there is nothing stopping you using the standard Eclipse "green" debug button - as long as your launch configurations are correctly configured.

Regards,

MCUXpresso IDE Support Team

[scottm]

Thanks for the response.  Is there any official line on the intended scope and audience for MCUXpresso?  To me, what I'm doing doesn't seem like it should be power user territory - it's non-trivial, full-time embedded development work but nothing exotic - just low- to mid-range single-core MCUs.  And it seems like there aren't a lot of supported alternatives - just IAR and Keil, both in the $6000 neighborhood.  For a small company like mine that's a lot - we're still paying annually for CodeWarrior 11, just to be able to make bug fixes to legacy HC08 and ColdFire code, and even that stings a little bit considering how little it gets used.  It'd be worth paying for one of the alternatives if everything just worked and all of the parts and SDKs were supported across all of the devices we need and debugging support was perfect, but everything I hear about IAR and Keil (I haven't used either in several years) says that's not the case, so I certainly appreciate a no-cost alternative.

I've got both a Cyclone and an LPC-Link2 at my desk because we've always used Cyclones for production programming and it's a bit faster, but the LPC-Link2 is better supported by MCUX.  And right now it gives me a better chance of having *some* working debug probe.

I'm having other problems this morning, but we can deal with that in another post.  Right now, I'd like your help getting to the most stable and supported configuration I can.  My main development workstation is running Windows 8.1 Enterprise.  Is MCUX more stable or more thoroughly tested under another OS?  If so, which one?  I'm trying to avoid running Linux on this machine since I also need it for mechanical CAD/CAM that I can't do on Linux, but I'd be happy to ditch 8.1 and move to Windows 10, if it's at least no LESS stable.

I can refrain from loading any P&E drivers after the machine is reloaded, if the LPC-Link2 is the preferred debug probe and coexistence with P&E is a problem.  Are there any other hardware compatibility issues to be avoided?  Any Eclipse plug-ins that should not be used?  I've tried to keep my installation more 'vanilla' since I last wiped and reloaded it - I use the DevStyle 'darkest dark' theme to save some eye strain, the Overview plugin for navigation within source files, Eclipse Web Tools for some embedded web front end stuff, eclox for Doxygen integration, the git plugin, the PMD static analysis plugin, and EmbSysRegView for when Peripherals+ isn't working right.  That last one is the only one that seems like it ought to have any impact on debugging.

What is NXP's most common configuration, in terms of debug probe and host OS?

For the sake of keeping it vanilla, I've moved the major projects I'm working on off of Processor Expert and they're just using previously-generated static files from PEx and the toolchain is the default.  I do have a custom build of newlib-nano for the sake of optimization, but that shouldn't affect debugging.

Starting new projects from scratch based off of examples is not something we do often; I've got a junior developer learning the ropes by doing that with some minor projects, but mostly I'm working on two larger projects, each representing 3 or 4 physical products, with about 20,000 lines of unique code each and around 10,000 shared.  That means multiple build configurations and a little bit of directory structure complexity, and they're not using the SDK because there's no simple way to switch incrementally, but to me this doesn't seem like it should be a strain for a modern development environment.

Thanks,

Scott