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.
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.
I recently upgraded from Win10 to Win11. Windows 10 was not great for building performance compared to Linux. And I feel that with Windows 11 things got worse too.
Dev Container in VS Code uses docker-based environments. This enables me using a full-featured development environment, with isolated dependencies. This is especially very useful for development in the embedded systems space. There I have to use many different SDKs, toolchains and libraries. Using Dev Containers is super easy. But file I/O operations with building etc/is not that great.
The solution is to use a Docker Volume with VS Code and Dev Container:
In “Getting Started with Rust on NXP LPC55S69-EVK” I demonstrated how easy it is to run a ‘blinky’ with Rust. I used the Embassy framework.
In this article, I show how one can create a standalone Rust project for an embedded target.
Continue readingThe Rust Programming Language makes its way into the Linux kernel, and is used for embedded tooling. What about using it for Embedded? In this article, I’ll show how you get started with Rust on the NXP LPC55S69-EVK:
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.
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 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 readingThe MetaClockClock is a clock made of clocks. It consists of multiple dual-shaft stepper motors, arranged as a matrix of 5×12 analog clocks. Each clock has two motorized hands that can move independently. The clock can tell the time, but in a unconventional way. The entire matrix creates a meta-display that shows the time or other information. Between the updates, the hand can do coordinated, choreographed movements.
The clock hands are laser cut acrylics with get light up with a LED ring around the clock.
This article describes the build with CNC cut oak enclosure, laser-cut parts and 3D printed items.
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.
In Using Raspberry Pi and MCU-Link for Remote Embedded Debugging I created a remote server for debugging. I did order the NXP FRDM-IMX93 a few weeks ago, and did not had a chance to use it. So why not doing the same?
Here is how it can be uses as remote debug server,
Continue reading
MCU on Eclipse 