Struggling with MCUXpresso vor VSCode

[stejen]

Hey, I just can not get used to the VSCode extension. It's whole workflow does not seem logical for me. Here some things I just can not understand and maybe you can help me getting along.

New projects

There is a new project wizard. But it seems it is the same as importing the new_project example as a freestanding application. No other choices which components to use etc. This is something I could get used to, if there would not be issue 2:

Generated freestanding project

Wether I go with new project wizard or importing any example code, the generated project just feels incomplete. I have no startup code, no peripherals code, no drivers code, no configtool code, no board init code inside of my project files. Only a main.c file with some boilerplate code. I know, the extension tries to avoid copying unnecessary files, but looking for the files that are really used is very hard. Just an example, when trying to navigate to Board_Init function in main.c, IntelliSense proposes me 117 ! files where to look for that function because it is defined in every example project and I have to pick the correct one, which is really annoying.

Problem of that "forced deduplication"

When you want to change things you need to change them in the sdk repository. And when you ever want to create a new new_project, you inherit the changes which are probably rubbish for your new project. I could copy clean new_project examples, but this is not what I want to do or remember as a user of an IDE.

Working with Config Tools

This is also very disturbing to me. On opening config tools from the extension, it will load the mex file from the sdk repo. The config is not copied so it leads to the problem above. All that lands in my project are som json files. 

Enabling Experimental Copying of Board Files

Well, that seems to mitigate some of the problems. But again, it does not feel clean. It creates a file structure with <boardname> directory in the project root. This directory again contains a <boardname> dir and a <projectname> dir. It's just the copies of some folders but it does not really look integrated.

Enabling Experimental Standalone projects

Does not work at all. It always fails because clock config files can not be found in the example projects files. Because they do not exists.

Importing Repositories from SDK Generator

It will never work the first time. Reason is, that python dependencies are missing, which are available only after downloading the SDK, because therein the requirements.txt is stored. (My workflow is to create a new venv, install west there and then want the sdk to be loaded via the extention). It would be really more helpful if the import sdk feature would run a pip install of the SDKs requirements upfront, instead of telling me import failed because of missing dependencies.

The whole extension appears to me not very useful and full of manual needed steps. And even if those steps are made manually, the generated structure of the project is not very intuitive.

So, am I doing something wrong or is the extension still no good replacement for MCUXpresso IDE ?

[jrgert_work]

I too have tried to Import from Repository to build a Standalone project without success.  Using the FRDM-MCXN947 to test the FreeMaster USB example, the import left main.c and pin_mux.c in the repo?!

The statement copied from above is very troubling from a real world use case; "avoid copying drivers, startup code, and board files unless absolutely necessary by the customer."  It's actually not uncommon to have all the drivers, startup and board files in a local folder - because they may be tweaked or project specific.

I appreciate the effort of NXP to bring the SDK to VS Code, it's a lot of work.  Let us know when this gets fixed. 

[joseOcampoHernandez]

Thank you for taking the time to use the MCUXpresso for VS Code extension. Your feedback is very valuable to us. I would like to clear up the items you mentioned regarding the user experience.

I want to start off by highlighting the MCUXpresso Installer. The Installer handles the installation of all dependencies (python, pip, west, cmake, ninja, etc) needed for developing with MCUXpresso tools. The MCUXpresso Installer can be installed and launched from VS Code directly. The MCUXpresso Installer offers completely automated processes to install dependencies and other MCUXpresso tools. However, if you would like to install dependencies manually, we recommend following Development Tools Installation — MCUXpresso SDK Documentation.

New Projects

In its current state, the New Project Wizard does not provide information that communicates whether the project is created as freestanding or standalone. By default, the New Project Wizard uses the led_blinky example from the SDK and targets the .mex file (for use with Config Tools) for that project. We acknowledge that there is room for improvement here.

Config Tools

Projects created with the New Project Wizard do use the .mex file from the SDK. However, importing a freestanding project or a standalone project will create a local copy of the .mex file which will not conflict with the SDK.

Board Files

The modularity of the SDK allows for code reuse across many boards and examples. The current project structure also allows for files to be updated through Config Tools. Again, there might be room for improvement here.

Standalone Projects

The standalone projects’ experience is something our team has been actively working on. The latest versions of MCUXpresso for VS Code and MCUXpresso SDK import correctly with the clock config files.

Modifying files from the SDK

Modifying SDK files directly in the repository can be problematic for other projects. Users can modify files from the SDK (i.e drivers/middleware). However, making a copy of those files within a freestanding/standalone project is a cleaner way of doing so. Through CMake, users can target the modified files (now in the project) rather than the references to those in the SDK.

Clarification on Intellisense usage

Intellisense by default has a broad view on all files within a workspace. To limit the scope of intellisense to a specific project, build the project. When a project is built, a .vscode folder within the project should contain a c_cpp_properties.json file which limits the scope by referencing the entries in the compile_commands.json in the build folder. However, Intellisense may hang when there are several projects in the workspace; if Intellisense does not hang, then it shows the different sources for the component in question.

I want to reiterate that we highly appreciate the feedback. Feel free to reach out to our team if anything else remains unclear/unintuitive.

Our team is actively working to enhance the user experience with monthly improvements. MCUXpresso for VS Code v26.01 is available now, please review the changelog for more improvements. 

Regards,

Jose Ocampo Hernandez | Ecosystem Product Manager

[EdwinHz]

Hi @stejen,

Thanks for sharing your concerns. I understand that switching from the classing IDE to the VS Code extension can feel unfamiliar, since the workflow is completely different and it leverages distinct tools and methods to achieve the end goal. I understand how this can cause the transition to feel unintuitive and not seem like its currently a good replacement for the IDE. However, the new workflow is designed around deduplication, shared repositories, and lighter and more manageable project structures, to achieve a more scalable, maintainable, and flexible environment long‑term.

With respect to your specific pain points:

New project wizard and minimal project files:
You are correct in mentioning that the initial project structure looks lean, but it's intentional to avoid copying drivers, startup code, and board files unless absolutely necessary by the customer.

Shared SDK files:
The extension’s design avoids duplicating files so that updates and fixes in the SDK automatically propagate to other projects. That said, I understand that if you don't want specific changes to propagate, it can be counterproductive. This is an area we’re actively improving with clearer navigation and better filtering.

Editing SDK sources and project isolation:
This problem is exactly why the experimental features of "Copy board files" and "Standalone project" were introduced, since we understand that some developers might prefer self-contained projects for their specific applications. These features are still evolving, and your feedback is really helpful in shaping them.

Working with Config Tools:
Using the .mex files directly from the SDK repo is part of the deduplication model, but I understand how it feels disconnected from the project. This workflow is under active review.

SDK import and Python dependencies:
The dependency issue you experienced is known. The goal is to make SDK import smoother and more automated, so the first‑time setup doesn’t feel so manual.

That said, the extension is still undergoing extensive testing and continued development in order to improve and mature it to the level that our customers expect from us. We are focusing on better version control, more flexible project structures, and easier updates across projects, while reducing the footprint of the IDE, SDKs and projects as a whole. We really appreciate your feedback and invite you to continue reporting these insightful pain-points you encounter since these are exactly the king of insights that help us continue improve the tool.

BR,
Edwin.