In Tutorial: Getting Started with MCUXpresso SDK – Repositories with VS Code and Tutorial: Getting Started with MCUXpresso SDK – west I showed how to get the MCUXpresso SDK. In this article it is about tweaking and streamlining the project.
The result is a clean, portable and self-contained MCUXpresso SDK project.
In “Tutorial: Getting Started with MCUXpresso SDK – west“, I demonstrated the ‘west’ tool’s usage. It helps in acquiring an SDK repository. Instead using the command line tool, I can use the NXP VS Code extension to do the same.
In my earlier tutorial I showed how to install the necessary SDK tools. In this article I’m going to install the SDK sources. For this I’m going to use west. This is a command-line ‘meta-repository’ tool.
The engineering and development landscape is constantly changing. This includes the embedded tooling and SDKs.
Back in the year 2017 I have used the version 2 (see Tutorial: Using Eclipse with NXP MCUXpresso SDK v2 and Processor Expert). Back then, it was Eclipse with make. Now we are in 2026 and things have changed to VS Code, cmake, ninja, python and west.
Luckily, although more and different tools are needed these days, the installation experience has improved significantly. It has shifted from installing multiple different tools to a streamlined installation process.
Continue readingToday’s projects and systems get more and more complex. Many systems include multiple MCUs, connected with a field bus or network, for example CAN. For example there can be up to 70 CAN nodes in modern cars. Such larger and connected systems are a challenge for debugging.
Traditional hardware debugging requires a hardware debug probe, connected with a dedicated SWD/JTAG debug cable to the target device. This needs dedicated pins on the target device plus physical access to the device itself. In many cases, this is not possible in the final product. The hardware debug probes, cables, pins and high speed signals are costly. And worse they can introduce new problems and are prone to interference.
If there is a field bus like CAN connecting all the MCUs, why not use it for hardware debugging? Hardware debugging meaning programming the FLASH memory, halt the MCU, inspect the memory and registers, and step through the code?
Yes, we can! With the help of a rather unknown hardware feature on ARM Cortex-M devices. We can use the ARM DebugMonitor Interrupt to control and debug the target system. As we would use a JTAG/SWD connection. Instead, we use the CAN bus :-).
Continue readingIn CI/CD for Embedded with VS Code, Docker and GitHub Actions, I used GitHub to build a pipeline. This setup supports continuous integration within a CI/CD environment.
This time, let’s do a similar thing. But instead of GitHub, I use GitLab with VS Code. And I use it for a project where three different MCUs are used: the Raspberry Pi Pico-W, an Espressif ESP32 plus the NXP K22FX512 on the Sumo robot:
The year 2024 is coming to its end, time for a Year-End-Processor-Expert-Component-Release.
Also, this is now the 10th anniversary of the releases on Sourceforge, starting with https://mcuoneclipse.com/2014/10/21/mcuoneclipse-releases-on-sourceforge/ back in 2014.
Continue readingThe new year 2024 is coming, so time to close the current year with a new release: I’m pleased to announce a new release of the Processor Expert components, available on SourceForge and GitHub.
In my previous article I showed how to import, build and debug MCUXpresso SDK projects in VS Code. In my lectures and labs we are using a robot based on the NXP Kinetis K22FX512 ARM Cortex-M4F microcontroller, and there is only the v2.13.0 SDK available.
The software on the robot uses the latest NXP MCUXpresso SDK v2.3.1. The he Eclipse based MCUXpresso IDE 11.8.0 works fine with all the 2.x SDKs, up to the latest 2.13.0 one.
Continue readingThe Freescale K20DX128 MCU was one of the first ARM Cortex-M devices of that company (now NXP) back in 2012, and the FRDM-K20D50M board was the first ‘FRDM‘ board of a long and successful series of boards, starting back in 2013. I still have the K20 present in many of my designs. The challenge with ‘early’ or ‘legacy’ devices is that after a while, they are ‘not recommended’ any more, and it is hard to get support for them. So for example in newer tooling and software from NXP, there is no support for the K20.
So if you still have the K20 around, and need some newer tooling, then I have good news for you: It is possible to add that good-old-Kinetis to the list of supported LinkServer devices, so you are not stuck and can use newer debugging solutions for the K20.
Continue reading
MCU on Eclipse 