Location of the Workspace, renaming projects and Viewing the Heap and Stack usage

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Location of the Workspace, renaming projects and Viewing the Heap and Stack usage

3,150 Views
laszlo
Contributor I

I installed the December 10, 2019 version (11.1.0_3209) of the MCUXpresso IDE over the previous version. I have some issues with it:

1. My documents folder is in drive D, as my drive C is a fast and small SDD for boot. Still, MCUXpresso created folders in my C drive:

C:\Users\<username>\mcuxpresso\02\SDKPackages

C:\Users\<username>\Documents\MCUXpressoIDE_11.1.0_3209

The actual workspace is in my Document folder on the D drive.

- How can I clean up this mess, and make sure future versions of MCUXpresso does not write to my C drive?

2. While debugging a project (SDK example), the Heap and Stack usage view is not available. It shows an error message:

Could not create the view: com.nxp.lpcxpresso.debug.ui.views.NXPHeapAndStackUsageView

The details show a very long list, starting with

java.lang.Exception
at org.eclipse.ui.internal.ViewReference.createErrorPart(ViewReference.java:114)
at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:100)
at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPart(CompatibilityPart.java:300)

- What is the problem and how can I fix it?

3. When I copy and paste a project in the workspace view, many generated project files still have their original names, which is confusing. I found a solution: delete all these files, edit the ".cproject" xml file (located in the project's workspace folder on the disk) to change all the occurrences of the old filenames to new ones,; save the ".cproject" file; and rebuild the project.

- I just wish these steps were not necessary, all the project files had their names changed properly.

0 Kudos
3 Replies

2,816 Views
lpcxpresso_supp
NXP Employee
NXP Employee

First of all, from what I understand, you're reusing a workspace created with a previous MCUXpresso version. While this approach is not completely wrong, if we add to the recipe a new Eclipse version and some internal plugins refactoring, we'll end-up seeing weird problems. Long story short is that we recommend starting with a fresh workspace given the update you performed.

To answer your questions:

1. You can always specify a custom location for the SDKs installation and then remove the one that's tied to the user profile.

pastedImage_2.png

2. This problem is caused by the fact that you're reusing a workspace created with a previous MCUXpresso version. The new IDE version does not contain anymore the same IDs for some views as the old IDE, thus the errors. You could simply close and reopen the problematic views or start with a fresh workspace.

3. I'm not sure I understand the problem. Would you please provide some steps to reproduce the reported behavior and also give an example of a generated file that should change its name? I'd like to understand what needs to change.

Greetings,
MCUXpresso IDE Support

0 Kudos

2,816 Views
laszlo
Contributor I

1. Relocating the SDK's this way worked nicely. Thank you!

  • Do I have to do this always, when I install a new MCUXpresso version?
  • It would be nicer if the SDK directory would not be automatically selected in a non-existent path, but asked, defaulting next to the workspace directory.

2. Closing and re-opening the Heap and Stack view resolved the problem. Thank you!

3. The steps:

  • Import the hello_world SDK example from the frdm_k28f SDK, keep its default.
  • A project is added to the workspace with the name: frdmk28f_hello_world
  • Try it out with "Debug", both in <Debug> and <Release> configuration
  • Rename the project to "my_hello", and debug the new project
  • We see a bunch of generated files with the old filenames "frdmk28f_hello_world*"
0 Kudos

2,816 Views
lpcxpresso_supp
NXP Employee
NXP Employee

Answers...

1. Actually, the change is linked to the workspace.

2. I'm glad it worked.

3. Thanks for explaining the problem. In fact, that behavior is in line with everything that you'll see in the Eclipse community, not being specific to MCUXpresso. We'll think about this and see if it's worth doing something.

Greetings,
MCUXpresso IDE Support

0 Kudos