All‑in‑One Docker Image for NXP MCUXpresso, VS Code and CI/CD Pipeline

Working with different toolchains, different versions and targets can be very challenging. To simplify the setup and distribution of the development environment I’m using the concept of containers.

I’m using different Docker images and containers for development and automated CI/CD integration. In the past weeks I have extended, simplified and consolidated my work flows. For example I have now an image with the MCUXpresso tools, with everything running in a container: both locally on my machine with Docker, with VS Code, and the same integrated in the CI/CD pipeline:

Running MCUXpresso Tools in Container
Running MCUXpresso Tools in Container

It not only simplifies my development flow: the same way I can easily deploy the installation and setup for a class room lab environment: basically everything is only one click away.

Continue reading →

Explore Freedom of Choice with Debug Extensions for NXP and Cortex-Debug

I’m using different MCUS from NXP with VS Code, and for this I’m mostly using the NXP MCUXpresso extension for VS Code.

At the same time, I’m using the cortex-debug extension for other ARM Cortex-M based MCUs, for example the Raspberry Pi Pico series.

Does it makes sense to use cortex-debug for NXP devices, and what would be the benefit? More precise: can I use the NXP MCU-Link (LinkServer based) debug probes with cortex-debug, to debug another NXP MCU?

MCU-Link (right) debugging a MCU-Link Pro (LPC55S69, right) with cortex-debug
NXP MCU-Link (right) debugging a NXP MCU-Link Pro (LPC55S69, right)
Continue reading →

NXP LinkServer Now Supports ARM 64-bit for Enhanced Development

The latest release of the NXP LinkServer supports ARM 64bit (Debian) besides Windows, Linux and MacOS. With this, I can now develop on an NXP i.MX board. Plus, this enables an inexpensive way for automated on-target tests and CI/CD.

LinkServer running on Raspberry Pi
Continue reading →

3D Printed Rugged Enclosure for MCU-Link Pro

The 3D Printed Rugged Enclosure for NXP MCU-Link Debug Probe has been very useful. I wanted to design something similar for the ‘MCU-Link Pro‘ version of that debug probe. There there is already a laser-cut enclosure for the probe itself. I used the same stack-able rugged box for the debug probe plus all the cables.

NXP MCU-Link Pro Enclosure
NXP MCU-Link Pro Enclosure
Continue reading →

MCU-Link-MR v0.5: Enhanced Debug Probe for ARM Cortex-M

The MCU-Link-MR debug probe has been updated :-).

MCU-Link MR v0.5
MCU-Link MR v0.5

The MCU-Link-MR is a CMSIS-DAP debug probe for ARM Cortex-M devices with extra features for mobile robot and drone debugging. The project is open source and available on GitHub with KiCAD files and BOM.

Continue reading →

3D Printed Rugged Enclosure for NXP MCU-Link Debug Probe

I’m using the NXP MCU-Link CMSIS-DAP debug probe in many of my projects. The debub probe from NXP does not come with an enclosure. I’m traveling to work by train, so I designed a new rugged box and enclosure. The box is small and I can keep all parts inside it.

Rugged boxes and enclosure for NXP MCU-Link debug probes
Rugged boxes and enclosure for NXP MCU-Link debug probes
Continue reading →

Using Windows USB Devices and Debug Probes inside Docker Dev Container

Docker or Development Container are great for isolation. And they work very well with things outside which are TCP/IP based. But most debug probes are USB only. Docker container don’t work well with USB. In Remote Debugging with DevContainer and VS Code, I showed how to use USB based debug probes. I demonstrated using them with an IP connection. In this article I show how Windows USB devices can be used from a container, with the help of usbipd.

usb shared between windows and linux container
USB shared between windows and Linux container
Continue reading →

rblhost: Exploring Rust’s Role in Embedded Development Tools

The Rust programming language is making its way into different areas: Rust gets added to the Linux Kernel. I see an increasing interest for using Rust in embedded projects. And Rust is used for embedded tools. I noticed this with the latest LinkServer v25.09 release: there is a new tool included in the package, rblhost.

rblhost on crates.io
rblhost on crates.io

The release note just mentioned:

- Switched to using rapid blhost (rblhost) utility.

This triggered my interest, and actually that utility is implemented in Rust :-).

Continue reading →

Using CAN FD for Remote Hardware Debugging of Cortex-M Devices

Today’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?

Cortex-M Hardware Debugging over CAN

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 reading →

Optimizing CI/CD with RAM Target Applications

Usually, I run applications in the micro-controller FLASH memory. But for a CI/CD or testing environment that is not the best choice.

It is possible to have a ‘RAM target’, where the application is running in RAM instead of FLASH memory. This has the advantage not to ‘wear-out’ the FLASH memory. Plus loading and running in RAM is faster. This makes having RAM targets especially useful for testing.

In this article I’m using the NXP LPC55S16-EVK board, but any other target or board is applicable.

NXP LPC55S16-EVK
NXP LPC55S16-EVK
Continue reading →