Problem with FreeRTOS heap usage view

[biafra]

Hi everyone,

I'm using a custom board based on K66 and MCUXpresso 11.4.0.

In my project I use memory scheme 5 (#define configFRTOS_MEMORY_SCHEME 5 in FreeRTOSConfig.h), but when I stop execution no block is displayed in the FreeRTOS heap usage view:

How can I be able to display memory blocks in the FreeRTOS heap usage view?

Additionally the FreeRTOSDebugConfig array is not linked and it is optimized away at the end of the build process, it is linked only if I use it anywhere in the code (e.g.  PRINTF( "%d", FreeRTOSDebugConfig[ 0 ]);).

But it is irrelevant if the FreeRTOSDebugConfig is linked or not for the memory blocks to be displayed in the FreeRTOS heap usage view: they are never displayed.

I noticed that the declaration of the FreeRTOSDebugConfig array is:

const uint8_t FreeRTOSDebugConfig[] __attribute__((section(".rodata")))

Maybe should it be the following?

const uint8_t FreeRTOSDebugConfig[] __attribute__((section(".rodata"), used))

Many thanks

Biafra

[ErichStyger]

Hi @biafra ,

regarding

Maybe should it be the following?

const uint8_t FreeRTOSDebugConfig[] __attribute__((section(".rodata"), used))

To my understanding the used attribute only applies for static object, so won't help here. There are other implications with using LTO optimizations too. What I have done for years is maintaining a FreeRTOS port which avoids such problems (and others). For the one above the port is explicitly using the debug information struct in port as below:

This has been the most reliable way for me across all the different gcc and ld versions, including the latest one and including if using the LTO (Link Time Optimization).

Erich

[biafra]

Hi @ErichStyger,

Just for my curiosity: in the code snippet you posted in the image, I don't recognize any part of the code, which device port does it come from?

Many thanks

Biafra

[ErichStyger]

Hi @biafra ,

it is part of the 'McuLib' FreeRTOS port we maintain and use at the university.

It is a FreeRTOS port covering many devices and architectures, including M0, M4, M33, M7 and many more. It is part of a whole abstraction library and driver suite, which includes support for multiple SDKs, IDEs and build environment including the NXP MCUXpresso one. Switching the library between devices is a matter of setting a few defines. We use it for many courses, research projects and even commercial projects at the Lucerne University.

The library is open source and are available on GitHub.

I hope this helps,

Erich

[ErichStyger]

Hi @biafra ,

I just checked it with IDE 10.4.0, and it seems this is a regression: Heap5 with my example from

https://mcuoneclipse.com/2017/09/18/using-multiple-memory-regions-with-the-freertos-heap/

fails to display the heap too. So it seems to be a general problem, not related to your project and device.

Erich

[myke_predko]

Hey @ErichStyger 

I don't think any of the TAD features are working wtih 11.4.0.  For a project which works fine on 11.3.1 when I look at the task list I get:

java.lang.Exception
at org.eclipse.ui.internal.ViewReference.createErrorPart(ViewReference.java:115)
at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:101)
at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPart(CompatibilityPart.java:304)
at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:342)
at jdk.internal.reflect.GeneratedMethodAccessor88.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:58)
at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:999)
at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:964)
at org.eclipse.e4.core.internal.di.InjectorImpl.internalInject(InjectorImpl.java:140)
at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:405)
at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:332)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:202)
at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:91)
at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:60)
at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:42)
at org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer.createWidget(ContributedPartRenderer.java:132)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:999)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:659)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$1.run(PartRenderingEngine.java:544)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:528)
at org.eclipse.e4.ui.workbench.renderers.swt.ElementReferenceRenderer.createWidget(ElementReferenceRenderer.java:73)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createWidget(PartRenderingEngine.java:999)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:659)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.safeCreateGui(PartRenderingEngine.java:765)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$2.run(PartRenderingEngine.java:730)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.createGui(PartRenderingEngine.java:714)
at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.lambda$0(PartServiceImpl.java:109)
at org.eclipse.e4.ui.services.internal.events.UIEventHandler.lambda$0(UIEventHandler.java:38)
at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:236)
at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:133)
at org.eclipse.swt.widgets.Display.syncExec(Display.java:5895)
at org.eclipse.e4.ui.internal.workbench.swt.E4Application$1.syncExec(E4Application.java:219)
at org.eclipse.e4.ui.services.internal.events.UIEventHandler.handleEvent(UIEventHandler.java:38)
at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:205)
at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:203)
at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151)
at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:132)
at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:75)
at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:44)
at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:55)
at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:63)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:424)
at org.eclipse.e4.ui.model.application.ui.impl.ElementContainerImpl.setSelectedElementGen(ElementContainerImpl.java:170)
at org.eclipse.e4.ui.model.application.ui.impl.ElementContainerImpl.setSelectedElement(ElementContainerImpl.java:188)
at org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer.lambda$4(StackRenderer.java:975)
at org.eclipse.swt.events.SelectionListener$1.widgetSelected(SelectionListener.java:84)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:252)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5785)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1427)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1453)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1436)
at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1225)
at org.eclipse.swt.custom.CTabFolder.setSelection(CTabFolder.java:3241)
at org.eclipse.swt.custom.CTabFolder.onMouse(CTabFolder.java:1879)
at org.eclipse.swt.custom.CTabFolder.lambda$0(CTabFolder.java:330)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5785)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1427)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:5048)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4526)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1157)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1046)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155)
at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:644)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:551)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:156)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590)
at org.eclipse.equinox.launcher.Main.run(Main.java:1461)
at org.eclipse.equinox.launcher.Main.main(Main.java:1434)

My project uses Heap4.  I'm using your approach with the timer as set out in Tutorial: Using Runtime Statistics with Amazon FreeRTOS V10 

I probably would have discovered this on my own presently.  I'm trying not to make a snide remark about the grief 11.4.0 has caused me - this was not a well tested release.  

[ErichStyger]

Hi @myke_predko ,

FreeRTOS awareness seems to work for me (with the exception of Heap 5, as discussed here).

My project uses Heap4.  I'm using your approach with the timer as set out in Tutorial: Using Runtime Statistics with Amazon FreeRTOS V10 

I tried that older example mentioned, and I noticed that the linker removed the FreeRTOSDebugConfig[] as discussed in this thread too. This example is using the Amazon FreeRTOS port and does not have all the patches/updates applied (discussed above), and it seem that the new GNU ld in 11.4 is more agressive and removed the FreeRTOSDebugConfig[]. I solved that with referencing that structure, and everyhing works as expected, and the heap is shown too, along with the tasks, queues and timers. So good for that example.

I do believe that what you report here with your stack dump is likely not related to this and probably a different issue.

I hope that helps,

Erich

[lpcxpresso_supp]

I confirm the issue reported in the first post of this thread. Indeed, it is a regression that will be addressed with high priority.

Regarding the issue reported in this post, the stack frame I see is too generic to talk about what would cause the problem. Are you reusing an old workspace?

Greetings,
MCUXpresso IDE Support

[myke_predko]

@lpcxpresso_supp 

Thanx for looking into this.

Yes this is the same workspace that I've used for years.  

The problem appears in projects that were already in the workspace as well as new ones that were created in the last few days.

[lpcxpresso_supp]

Reusing workspaces created by different Eclipse versions is usually not a good idea. But in your case, it's not this what's making the TAD views not functional. Eclipse attempts to reopen the TAD views with the IDs from IDE v11.3.x. I won't go into details but, long story short, FreeRTOS TAD views have different IDs assigned in IDE v11.4.0.

Greetings,
MCUXpresso IDE Support

[biafra]

Hi @lpcxpresso_supp,

Many thanks for your answer.

This is my workflow:

• When a new MCUXpresso version is available, I install it
• I open my existing project with the new MCUXpresso version
• A massage box shows me that if I save the project, it can be unusable with the older MCUXpresso versions
• I save my project with the new MCUXPresso version
• From this moment on, I use only the new MCUXpresso version (and I uninstall the older one)

Is this workflow the proper way to work? Or instead should I create a new workspace and import my old project?

Many thanks

Biafra

[ErichStyger]

Hi @biafra,

here is what I do and recommend for any Eclipse (not only MCUXpresso), if you have a new version:

a) install the IDE into a new/fresh folder. Never over-install over an existing version

b) create a new/fresh workspace with the new IDE

c) import your existing projects into that new workspace.

d) Never 'share' a workspace with different version of Eclipse.Means use it with different Eclipse

e) Do not continue to use the old workspace with the new IDE. Keep it using with the old IDE, as that way you always can go back.

You can export/import your user settings from one workspace to another, see https://mcuoneclipse.com/2012/04/04/copy-my-workspace-settings/

Step c) is easy with MCUXpresso IDE: you can drag&drop projects into the new workspace, or copy (link) them from your old workspace to the new one (For this I keep the old IDE with the old workspace open, then drag&drop them into the new workspace, see https://mcuoneclipse.com/2020/07/12/eclipse-gems-tips-tricks-importing-projects/ )

I hope this helps,

Erich

[myke_predko]

Hi @ErichStyger & @lpcxpresso_supp 

I just spent a few minutes looking around on Eclipse updates and almost literally nowhere do I see the recommendation that you should create a new Workspace when you update Eclipse.  

The Eclipse FAQs (FAQ How do I upgrade Eclipse IDE?) says:

"When you start a new version of Eclipse IDE, you can use the same existing workspace folder that you were using with the older version. The workspace will be migrated to a newer version and the Eclipse IDE will reuse all configurations. The workspace is forward compatible, but might not be backward compatible."

I also found quite a few other references saying the same thing - I did find one case with a Python version of Eclipse saying if nothing seems to be working, create a new Workspace.  

You're both very definite on creating a new Workspace, I'm just wondering where you got that - did I miss on my search finding other references, is this some arcane bit of Eclipse knowledge or something else?  

[ErichStyger]

Hi @myke_predko ,

thanks for checking the references: I'm sure I have read that recommendation somewhere, but I admit I'm not able to find it right now.

So yes, this is how it should be in an ideal world. I still think it would be much more safe to use a new one, especially if I want to keep Eclipse versions side-by-side and don't want to accidentally open a 'migrated' one.

As for the view which does not open because of the ID change: I think that's something which should have been handed more gracefully: so imho this is something which should have been migrated by the plugin, but obviously did not.

Erich

[myke_predko]

Hey @ErichStyger 

Okay, I started a new workspace, created a couple of new projects with source files from the previous workspace and the TAD functions work.  Thank you for that tip.  

However, when I look at your list of five things to do when going to a new version of MCUXpresso I have to push back and say those are five reasons NOT to use the MCUXpresso. 

I also have to reject your assertion that they should be done for any version of Eclipse - I run three other versions of Eclipse (Java, C/C++ for Windows & C/C++ for Linux) on Windows, Mac and Linux OSes (for a total of five total installs besides MCUXpresso) not to mention keeping CodeWarrior around for product support and I update the various Eclipses all the time without having to do any of the points that you have listed with this being the first time I've had to create a new workspace because functionality was lost after an update.  

From my perspective, MCUXpresso 11.4.0 is a total disaster with it being incompatible with the previous versions of MCUXpresso, new problems introduced, undocumented changes in how projects are created/work and previous issues not addressed.  I would not recommend that people using MCUXpresso 11.3.1 upgrading to MCUXpresso 11.4.0 until the various issues that I and other people have reported are resolved.  

@lpcxpresso_supp sorry for being so blunt but I consider a successful update to be basically transparent with no issues with previous projects and new features/operating requirements clearly documented.  

[ErichStyger]

Hi @myke_predko ,

first, thanks considering my list of things and tips. These are things I have learned as long time Eclipse user, starting with the Eclipse Callisto release back in 2006 :-).

Maybe a longer (probably more philosophical) reply to this, with my 1 cent.....

Okay, I started a new workspace, created a couple of new projects with source files from the previous workspace and the TAD functions work.  Thank you for that tip.  

However, when I look at your list of five things to do when going to a new version of MCUXpresso I have to push back and say those are five reasons NOT to use the MCUXpresso. 

My advise is really not about the MCUXpresso IDE, but about Eclipse in general. I don't blame Eclipse. It can work without following my advise for new workspace, but sooner or later you will run into exactly these issues you were running into. Believe me, I learned these things the hard way with Eclipse. Without following that rule, you might see all kind of strange things. I'm using Eclipse for years in my classes with 30-50 engineers, and these rules are one of the first I teach them using tools (not only Eclipse, but other IDEs too). Like you, I'm using 6+ different IDEs from different vendors, even IDEs from the pre-CodeWarrior age, and following that rule has saved me and others lots of frustrations. In my view you were lucky that you did not see it earlier.

In an ideal world, everything would be forward and backward compatible. As we all know, the world is not perfect. I know personally from my software project how painful it is to make things compatible, and even if you try hard, things can fail.Again, I don't blame the Eclipse community for it.  MCUXpresso IDE (and other IDEs) even offer for each new version to open a new workspace, exactly to avoid such problems. My rule with a new workspace simply avoids potential problems, that's it. And because it is an easy rule (for me), it just got a habit for me.

From my perspective, MCUXpresso 11.4.0 is a total disaster with it being incompatible with the previous versions of MCUXpresso, new problems introduced, undocumented changes in how projects are created/work and previous issues not addressed. I would not recommend that people using MCUXpresso 11.3.1 upgrading to MCUXpresso 11.4.0 until the various issues that I and other people have reported are resolved.

In my view this is a bit of a stretch statement. I feel the frustration, and from my perspective I always give new versions a kind of trial period. Nothing is perfect (nor I am). But what gives me confidence is that NXP is constantly updating and releasing new updates which is a good sign of a living product. And as you have noticed: @lpcxpresso_supp which to me are the engineers behind the IDE has been jumping in and looking into issues raised. In my view this is remarkable (so Kudos for having them here), because in many other product forums (this is a free-of-charge product!) I rarely see the engineers behind it listening and responding.

Sorry for the long reply/thread. As for myself, I'm glad this forum exists, as I'm always learning something new and useful from all the different discussions, forums and as well from you! So keep this going, as a very active user here

I hope this helps,

Erich

[myke_predko]

Hey @ErichStyger 

Rather than rehashing past exeriences, let's talk about expectations.  

When I do an update, I expect software to continue working with the existing files, with some bug fixes and some new features with maybe some UI changes but still behave basically the same.  It doesn't matter if it's MCUXpresso, Visual Studio, Microsoft Word or an OS update.  

When I received the attached email three weeks ago, I didn't see any functionality changes that would affect me.  This expectation seems to be validated by the Forum announcement (MCUXpresso IDE v11.4.0 Now Available) and reinforced by your post (MCUXpresso IDE 11.4.0). 

I had reported an annoying bug in the files generated by the New Project Wizard that I hoped was fixed which was why I immediately downloaded/installed MCUXpresso 11.4.0.  I'm guessing that I got an early/incomplete package as there were problems handling the .mex files and a day or so later, on the advice of NXP, I reinstalled and things more or less worked.  Since then there have been numerous problems that I and others have discovered and had to deal with culminating with me creating a new workspace and then spending a half hour resetting the editor and other preferences to the way I like working with Eclipse (I know I probably could have exported this from the previous workspace but I just wanted to get things working and I was tired).  

I have spent an honest 8 hours identifying, characterizing and reporting problems with this release of MCUXpresso as well as trying out different suggestions and doing other things that I don't expect to do with an upgrade.  

I've been using MCUXpresso since version 10.1.0 - at least that's the earliest version in my /usr/local folder (yes, I know that's one of your five things not to do) and the lack of issues with updating since then has lead me to the expectation that installing a new version of MCUXpresso would be no big whoop.  

If I had been told to expect these problems would I have updated to version 11.4.0?  Definitely yes, but I would have waited until my work schedule would have better suited the distraction of dealing with the various issues and I probably wouldn't have reacted so angrily so often.  

Now that I've had some time to cool down and seeming to have everything working the way I did in 11.3.1 would I still call the 11.4.0 release as a "total disaster"?  Yes I would although I should point out that the term that came to mind would probably have gotten me banned from the forums so "total disaster" is actually a significant softening of my characterization.  Nothing in the release announcements gave me an expectation of what I would experience.  

@lpcxpresso_supp has done a good job of responding in a timely manner to issues and I appreciate your help as well.  

[ErichStyger]

Hi @myke_predko ,

Maybe not directly related:

The problem appears in projects that were already in the workspace

Just for clarification: I never 're-use' a workspace (workspace folder, .metadata) between Eclipse version. I share projects, but never let different Eclipse use the same workspace folder. I hope this is not the case for you. What do is to maintain a different workspace for each IDE (e.g. wsp_IDE_11.3.1 and wsp_IDE_11.4.0) and reference from there the projects (which are itself under git control).

The reason for this is that the .metadata format might not be backward compatible, so 'sharing' metadata is not a good thing.

The Eclipse CDT projects usually can be shared across different Eclipse versions. The NXP config tools are different, they are usually not backward compatible (you get a warning about this), just FYI in case you are not aware.

So, if this is not already the case: use a different workspace for every IDE version.

I hope this helps,

Erich

[danielholala]

Hello, 

@ErichStyger wrote:

The reason for this is that the .metadata format might not be backward compatible, so 'sharing' metadata is not a good thing.

The Eclipse CDT projects usually can be shared across different Eclipse versions. The NXP config tools are different, they are usually not backward compatible (you get a warning about this), just FYI in case you are not aware.

As you mention config tools and metadata, I wonder how you handle config (pins, clock) changes between workspaces and corresponding IDE versions.

Further, as all project files that are under revision control (e.g., git) are shared between workspaces, which metadata files do you exclude from revision control? According to your statement above, I assume that you exclude the *.mex file from it. But if you change, e.g., pins configuration in one workspace (and the related IDE version), how do you propagate that change to a different workspace and corresponding IDE?

Thanks.
Dan

[ErichStyger]

Hi @danielholala ,

Further, as all project files that are under revision control (e.g., git) are shared between workspaces, which metadata files do you exclude from revision control?

My .gitignore (placed into the root of each project) usually ignores following:

/.settings/
/Debug/

I assume that you exclude the *.mex file from it

I could ignore it too, but usually I don't. The .mex is more of a convenience and not a need, as all the settings are in YAML format in the source files. Usually I use the .mex and the associated tools at the creation of the project and delete it (and not using the tools any more), as I prefer just to look at what it generates and then either never change it or do it my way in my firmware code, not relying to the tools. That way I don't have any migration issues too, because it usually does not get touched any more.

But if you change, e.g., pins configuration in one workspace (and the related IDE version), how do you propagate that change to a different workspace and corresponding IDE?

If a project is shared between different IDE versions, I don't have to propagate as the project is the same. As noted somewhere else, the CDT settings are usually compatible and not an issue at all. Where things get tricky is with the config tools and the SDK (the IDE usually has a dependency to the SDK if you want to add/remove/change SDK components). To my understanding this is related to the SDK manifest which might come with changes which are not compatible. The config tools part I solve like I said above. For the SDK part I solved this mostly with that 'McuLib' layer which has an SDK configuration item, telling which API it shall use. Not perfect, but it works for my cases.

As last resort I have the ability to make a git branch, but I avoid this if not absolutely necessary. Instead I simply mark a project ("keeps at tool version x.y.z") and leave it like that. What we have recently some discussions about it is using docker containers, but this has not been hashed out.

Note: I want to be clear here: just telling how we are dealing with these things, and this might or might not work for you. Different environments ask for different solutions ;-).

I hope this helps,

Erich

[myke_predko]

Hi @ErichStyger 

I'll give it a try.

Thanx.