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.
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 readingTest coverage is a very useful metric: it tells how much of your code has been covered by tests. Or the other way: it helps identifying areas of my code which has not been running tests. A new CMake extension in VS Code is available. It works with the new NXP LinkServer test runner to allow running tests on an embedded target. The really cool thing is: it collects and visualizes test data with coverage information in a single step:
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.
SonarQube from Sonar is a free static analysis tool for VS Code. It is able to analyze the source code and find issues. SonarQube does a similar job as other static analysis tools like CppCheck for VS Code.
Cppcheck is a static analysis tool for C/C++. I have used it a lot for my Eclipse projects. And it runs with VS Code as well.
With Optimizing Embedded Development with VS Code and DevContainer I showed the benefits of using development containers. And with Remote Debugging with DevContainer and VS Code I explained ways use hardware debugging using that concept.
One topic is still open: how to use semihosting with file I/O using development container? The challenge here is that we need to work with two different file systems.
In this article I show how semihosting file I/O can be used with DevContainer.
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.
The NXP SDK is git based which is great. If I create a project with VS code, it references the SDK cloned locally.
A standalone project structure is needed if you want to easily share a project with your team. It’s also necessary for sharing inside a classroom environment. This article shows how to use an NXP SDK project in standalone mode.
Continue readingFreeRTOS has a great performance measurement feature built-in: Performance counters. At each context switch, the RTOS can do a bookkeeping of time spent in tasks. With this, it can estimate the runtime distribution between the tasks. A very useful feature to get a feeling what the tasks are doing.
But I noticed that with recent FreeRTOS versions, VS Code extension have issues showing the correct runtime counter values:
MCU on Eclipse 