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.
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 readingThe 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.
This is the second part describing how to use DevContainer for embedded applications with VS Code.
In Optimizing Embedded Development with VS Code and DevContainer I use VS Code with a docker ‘development’ container. The container is created with a recipe to install the development tools and SDK. With VS Code and DevContainer I have the same developer experience as I would develop locally on the host.
One thing not addressed in that earlier article is debugging. Using USB debug probes like a SEGGER J-Link or NXP MCU-Link is a challenge inside a container. This applies to any other debug probe as well.
The solution is to transform an USB based debug probe into one with a network connection:
In this article, I show how to do this.
Continue readingNXP has released a new LinkServer software. It includes an interesting feature. The LinkServer test runner has been extended with a Semihosting console. This is not only very useful for on-target testing. With the Semihosting console, I have a bidirectional communication channel with the target. And I do not need any hardware pins or to run a debug session. All what I need is the CMSIS-DAP connection with the NXP LinkServer runner to have a command line shell:
The release 24.9.75 of LinkServer software and tools includes interesting feature: the ability to use the debug probe for automated on-target testing. It includes a ‘runner’ which can program, launch and run the application on the target through a debug probe. While the target is running, it uses semihosting or UART for communication. This makes it a perfect tool for automated testing, especially in a CI/CD environment. One such environment is running automated tests with CMake and CTest in VS Code.
NXP has released a new version of the LinkServer software. This is a utility for debugging and using scripting for a wide range of devices and debugging probes. It includes support for the MCU-Link, LPC-Link2, on-board and CMSIS-DAP based debug probes with the ‘LinkFlash’:
With the new release, it includes a graphical user interface (GUI) for flash programming. It also includes erasing, verifying, recovery, and saving the memory to a file.
Continue readingA new eclipse-based NXP MCUXpresso IDE v11.10 is available With this new release, it includes an even easier firmware update mechanism for the MCU-Link (LinkServer) debug probes.
Need to debug your robot or drone? In a HSLU university research project I’m using a Pixhawk and PX4 based drone hardware. Pixhawk and PX4 is an open standard for drone hardware and firmware and runs with NuttX RTOS. It is mainly used for drones, but is very capable for any other kind of mobile robots.
With the Pixhawk 6x-RT there is a powerful flight controller, using the NXP i.MX RT1176 dual-core processor. While this and other controller hardware do offer a hardware debug probe, it is not a simple task as there are different pin-outs and connectors, making debugging a mess with different cables and adapters. To simplify this, I have now a unified debug CMSIS-DAP debug probe using the NXP LPC55S69 as processor, with all the different headers and UART adapters included: the MCU-Link-MR (Mobule Robots) debug probe.
Who needs a debug probe, if you have printf()? If doing serious development, you most likely want a hardware debug probe. We at the HSLU IET use different hardware, boards and kits, and for many of the classroom equipment it is very useful to have the debug probe embedded on the target board: less cables, easier to use. For this we have developed a new Open Source Hardware (OSHW) debug probe in KiCad which can used in different ways: as external debug probe, integrated and soldered on top of the target board, or fully integrated and embedded into a custom design.
MCU on Eclipse 