NXP has released a new LinkServer v26.9.130. And it comes with a major new feature: it now includes power and energy measurement:
Additionally, it has a command line interface for this, making it ideal for AI agent usage or for automated tests in a CI/CD environment.
Continue readingSetting up the correct tools for a development environment can be complex and time consuming. I’m using DevContainers with Docker for almost all of my projects. Because that way I get an isolated development environment. For this I spend time to craft dedicated docker files, to have everything installed correctly with the the right versions.
Outside a docker or DevContainer environment, I’m using the NXP MCUXpresso installer. It is a standalone application which can be used from VS Code to check and install all the necessary tools.
In this article, I show how to have the NXP MCUXpresso Installer installed in a DevContainer so it can be used with VS Code.
Continue readingIn 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.
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.
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.
Sometimes, all what I have is a ELF/Dwarf binary, and I need to debug it. I don’t want to build it, only debug it. The NXP VS Code extension makes that possible. I simply import the binary and start debugging.
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?
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 readingUsually, 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.
Remote debugging an embedded target is very useful: I don’t need a direct debug probe or USB cable connection. Instead, I’m using a network connection (wired or even wireless) over TCP/IP to talk to the debug probe and target. That way I can place the debug probe and target system away from my desk.
In Debugging ARM Cores with IP based Debug Probes and Eclipse I have used IP-based debug probes. This is a logical path, but expensive.
In Remote Debugging with USB based JTAG/SWD Debug Probes I showed how normal USB based debug probes can be used. This approach uses a remote host machine (e.g. desktop machine or notebook). This approach is still expensive, not scalable and the host machine needs a lot of space too.
So what if I use a Raspberry Pi instead? The RPi is small, inexpensive and ideal for such a task. Additionally, I can easily use it to build a test or debug farm. In this article, I show the use of the Raspberry Pi for remote debugging. A sub $20 or embedded target debug probe can be employed.
The MCU-Link-MR from NXP is a CMSIS-DAP debug probe. It includes dedicated connection headers found on mobile robotic systems. These systems include the Pixhawk/PX4 drone and robotics hardware.
