My usual workflow is: edit – build – debug and repeat. And this for the same project again and again. So here are a few tips how to make these iterations faster with Eclipse. One thing is to use the F11 shortcut to debug the last launched/debugged application:
Debug Last Launched
Especially working with multiple projects I don’t have to select the project I want to debug: it always will launch and debug the last one I was using. This setting is available with Eclipse Oxygen (e.g. MCUXpresso IDE 10.2).
That F11 shortcut might be different for you (check your menu entry). You can change/check the available shortcuts in the Eclipse workspace preferences, under General > Keys:
Key Shortcuts
Note that I still have to terminate a running debug session. There is a ‘Terminate and Relaunch’ setting in Eclipse CDT, but this one does not work reliable (at least not in CDT of Eclipse Oxygen, I have not checked this in Eclipse Photon yet).
But the MCUXpresso IDE (I’m using 10.2) has nice extension to do the ‘terminate-and-debug-again’ with a button in the Quickstart panel:
Terminate, Build and Debug in MCUXpresso IDE
Note that this is using the currently selected project (marked in yellow above) and includes a build phase. I can skip the build part with the ‘Build (if required) before launching’ setting workspace setting:
Disabled Build before Debug
Of course, with that setting I’m responsible to build before I debug if I have changed the sources.
In earlier Eclipse versions (e.g. Kinetis Design Studio 3.2.0, Eclipse 4.4 Luna) I have used the ‘always launch the previously launched application’ to stick to the last launched application:
Always launch the previous launched application
These tips and tricks help me to work faster with less mouse clicks. I hope you find these tips useful.
Happy Debugging 🙂
Links
MCU on Eclipse 
F11 is how I launch a debug session 99% of the time. The quickstart panel doesn’t work reliably for me, even in today’s brand-new MCUX 10.2.1 release – my ‘Terminate, Build, and Debug’ button is always grayed out. At the moment, the blue ‘Debug’ button detects no debug probes, even though my Cyclone is working fine. I have to rely on the normal (green) debug configuration controls, which was difficult until I figured out a few bugs – most importantly, that you can’t launch from the debug configuration dialog if you’ve selected the executable using the ‘browse’ button – it acts as if the executable is missing. Once you get it to run once, though, you can use F11.
When the blue debug button is working, it likes to create duplicate debug configurations, so I don’t use it even when it is detecting probes.
And Erich, normally I think Twitch is a silly platform, populated by younger siblings who grew up watching their older siblings play video games, but if you ever feel like setting up a stream, I would watch it! I spend many hours each day in MCUXpresso and when I run into problems like this it makes me wonder what is so different about my configuration or workflow that MCUX has so much trouble. It’d be interesting to watch someone else do non-trivial things with it in a real-world setting, and not just run a few example apps with a completely vanilla installation and a single LPC-Link2.
LikeLike
I just received this morning a notification email that there is the 10.2.1 available. I will check it out this morning.
As for ‘Terminate – Build – Debug’: this one is enabled for me only if I have an active debug session, otherwise it is grayed out too.
If the blue debug button does not find the probes, this might be a firewall setting problem? Not sure if you tried it out, but I would disable virus scanner/firewalls to see if this is a problem. Whenever I install a new IDE, the Windows firewall is asking me for each probe if I want to allow access to the local network (which I allow).
The other thought I have: I had recently a discussion where someone ‘overinstalled’ the IDE (installing the new IDE into an existing IDE folder): all kind of strange things did happen. So I assume you have installed say the 10.2.1 into a fresh/new directory, right?
As for the blue debug button creating new configurations: it does this if it does not detect the ones it would have created. That creation works fine for me, and compared to creating new launch configs by hand there are less chances for a novice to make mistakes. I will try to reproduce what you say about the browse button and report back.
Twitch: oh, I knew that something like this exists, and I think too that this is silly. Maybe youtube videos are a better way, but doing videos is soooo time consuming. But you are right, maybe recording a few things could be very helpful for other users.
LikeLike
This morning the terminate, build, and debug button is working, AND the blue debug button is showing all of my debug configurations. It makes me choose one ever time and it shows my Cyclone twice and it’s much slower than F11, but it’s working. I just restarted MCUX and tried again, and now it doesn’t make me choose the probe each time, just the configuration. It’s weirdly inconsistent. I’ve reported some things to support that are very clearly UI bugs and 100% reproducible (at least for me) so I’ll wait to see what they come up with on those. It’s been slowly getting better with each release.
And yeah, I installed to a new directory. The most unusual thing about my configuration is that the projects (but not the workspace) are on a subst’d drive that’s replicated via Dropbox. The most common issue with that is that the drive letter is only visible to the logged in user and not admin, so occasionally installers won’t work. With previous Dropbox versions I’ve also occasionally run into problems with locked files (e.g, EAGLE used to have trouble auto-saving) but I’ve run with Dropbox disabled and using the true path of the project before. And really, if that IS a problem and the ability to use the blue debug button is all I lose, it’s more than worth it to have a consistent drive structure across machines and to have almost instant backups of every file that’s saved. It’s saved me a lot of pain.
Anyway, the prove discovery *does* work, sometimes. And sometimes it shows double for the Cyclone – both entries on Ethernet, I don’t have USB connected right now. Maybe two competing versions of the driver or something? It’s really not a big deal as long as I can get the initial launch config and then maintain it manually. I’m sure the configs I’m using now did originate with MCUX, it just took a bunch of flailing to get there, partly because of the UI bugs I mentioned (and that I’ve described on the forum). I can get where I’m going and I’m not too concerned with fixing it all right now, I’m mostly sharing for the sake of anyone else who’s running into similar problems.
I agree, videos are a pain. It’d just be nice if there was something out there geared toward a higher level than the Arduino crowd, that wasn’t even necessarily intended to be instructive. I’ve learned a ton about machining from Youtube, but also a lot about how to set up a machine shop just from seeing how others set up their work space. It’d be fun to see something like that in the embedded world. There’s a lot of the practical stuff that’s passed down through on-the-job training that isn’t covered in school, and despite the fact that I’ve been doing embedded stuff close to full time for about 15 years I’ve never worked for or with anyone else doing similar work, and most people in the field are not in a position to share details of their work. Just getting a peek at how anyone else sets up their work space (where do you like to position your test equipment? what are your tricks for avoiding the tangle of wires everywhere? what’s your workflow?) is difficult.
Web developers love to show off their battlestations with 15 monitors and glowing keyboard, and will vigorously debate the merits of the hot tool set of the week, but embedded developers are a quieter, more secretive bunch.
LikeLike
I had so many problems with files shared on DropBox that I have banned now that tool from my machine. This was all across different tools, not only Eclipse. And many, many weird problems reported by students were because of putting files on DropBox and using them in tools. In my opinion, this very likely could be the reason of your problems, especially if you have some client in the back syncing with DropBox. The worse thing is to share the workspace .metadata in DropBox which you are not doing (great!). It would be interesting to see if the same probem happens as well if you have the projects not in a DropBox location?.
I agree on the backup part, but I’m using proper version control systems (Git) for this. Yes, it is not automatic backup, but with ‘commit early and often’ as encouraged by Git this is solving all my ‘backup’ issues. And I can easily have the Git repo on my local machine, a local server or on a remote repository as GitHub.
As for having a consistent directory structure, I’m using subst as well, simply pointing to the folders I have cloned from the Git repository, and have not faced issues except the one you hav mentioned about it accessible by the user (not the admin).
Interesting thoughts about the embedded developers croud: I agree that they are probably more introverted, and their technology is more specialized and not applicable to many others out there? The hardware and tools ecosystem is much more fragmented.
LikeLike
I’m careful to test without Dropbox before I report anything to NXP. I’ve inadvertently had my .metadata in Dropbox and that did cause all kinds of problems, starting with the fact that it was constantly busy trying to sync everything. I keep my workspaces on c:\ now.
I use git (or SVN for projects I haven’t migrated yet) but I usually don’t check things in more than once a day. I don’t always check in if I’m in the middle of a bunch of changes. I take a belt and suspenders approach to backups – Dropbox for moment-to-moment, local backups nightly with weekly copies burned to DVD-R and stored off-site, Mozy for nightly off-site backups, and git for manual check-in of changes. All of them have saved me at least hours of lost work at one point or another. The local backups a particularly important for files that go missing and aren’t noticed for more than 30 days. Dropbox is the most invasive of all of those, but often the most useful.
You’re right that the embedded ecosystem is more fragmented, and embedded just isn’t seen as particularly sexy. There are also a LOT of freelance web, desktop, and mobile developers out there and not nearly so many in embedded. On reddit I once tried to get a ‘battle station’ thread going for embedded developers, and almost none of them were in a position where they could even share a photo of their physical work area.
LikeLike
Hi Scott,
I have looked into the launch config thing. Conclusion is that it is not easily possible to create a launch config from scratch in the launch config menu. The launch config created by the probe detection is vastly different from one I create from scratch: it uses different hooks and adds additional meta information to the launch XML file. Using such a launch config results in the IDE to complain about an incompatible launch config, unless all the extra data is added to the launch config. But what works is to ‘clone’ an existing MCUXpresso IDE launch config (there is the ‘duplicate’ button in the launch config dialog toolbar), so I recommend using that one. But of course you need first an existing launch config for this. I suggest that you use one of the many I have available in on GitHub (https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/MCUXpresso), copy a matching one into your project and use that one. If I can help you on that, let me know.
I realize that the IDE wants to prevent users from doing wrong launch configs (which I agree can be a complicated), but I’m still wondering why your probe discovery does not work?
LikeLike
Thank you!!!
LikeLike
I have another quality of life question.
When building and starting project, several c file tabs e.g. port.c get opened by MCUexplise. Then I have to close them manually with the mouse or Ctrl+w. Is there any way to stop this behavior?
LikeLike
Hi Frieder,
not sure if I’m following?
When building, it should not open any source files. Same when you open a project.
When creating a new project it opens the file with the main() which makes sense to me.
As a hint: you can close any open source files with the context menu on the file tabs and use ‘Close all’
LikeLike