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’m shifting more and more of my CI/CD testing infrastructure using the LinkServer runner. One reason is the LinkServer runner can run the test on-target. It can also collect GNO gcov coverage information at the same time. LinkServer is a suite of software tools for launching and managing GDB servers for NXP debug probes.
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 GNU Coverage (gcov) is a source code analysis tool, and is a standard utility in the GNU gcc suite. It works great in a hosted environment (e.g. Linux or Windows), where you have plenty of resources and a file system. But the gcov tools is relevant and usable for restricted embedded systems too. I have used it for years with the help of debug probes and file I/O semihosting. But semihosting does not come for free, depends on a library with support for constructors and destructors, plus relies on file I/O.
Fortunately, there is a way to use gcov without debugger, semihosting, file I/O and special system initialization: using a freestanding environment:
This article explains how to collect coverage information using a data stream for example over UART or USB-CDC. Key benefits are less code side, no need for a debugger or on-target file system, improved performance, better automation and flexible data collection.
Continue readingIn “Touch & Build: Auto-Update of Firmware Date and Time” I’m using commands as ‘touch’ in a pre-build script with the NXP Eclipse based MCUXpresso IDE. That ‘touch’ command is not a Windows shell command, but common on Linux: it updates the time/date of a file.
Build Step Dialog in MCUXpresso IDE
As a Windows user you might wonder what is about this ‘Linux compatible shell’?
I admit: my work laptop machine is running a Windows 10 OS by default. But this does not prevent me running Linux in a Virtual Machine (VM). Each host platform has its benefits, and I don’t feel biased to one or the other, but I have started using Ubuntu more and more, simply because I have worked more on Embedded Linux projects. While I have used mostly Windows with Eclipse for NXP LPC, Kinetis and i.MX platforms in the past, I started using Ubuntu too from last year with the NXP MCUXpresso SDK. I did not find much documentation about this on the web, so I thought it might be a good idea to write a tutorial about it. So here we go…
Building NXP MCUXpresso SDK on Linux Ubuntu
For a next-gen course I’m evaluating different platforms, and one of it are modules based on the NXP i.MX ARM architectures. In this article I have a look a the Variscite DART-6UL development kit which includes the NXP i.MX6Ultralite ARM Cortex-A7 plus a 7″ capacitive touch LCD:
Variscite VAR-DVK-6UL_LO Kit
An interesting trend in the industry are SOM (System on Module): a high performance processor typically running Linux, Windows or Android with all the memory and necessary power logic gets put on a small module. The key benefit is that I don’t need to worry about the complex ball grid routing and the DDR memory connections/lines: all these problems are solved on a small module which then I can use in my design. It seems that NXP i.MX application processors are getting popular in this domain, and after looking at the Toradex Colibri modules, I have an i.MX6 module on my desk from e-con Systems:
eSOMiMX6-micro Top Side
The concept of Linux (Open Source, broad developer base and broad usage) is a success story. While there is a lot of diversity (and freedom) in the Linux world, Linux is Linux and again Linux :-). And the world has (mostly) standardized on Linux and its variants on the high embedded system side.
On the other side, the ‘middle and lower end’ Embedded world is fragmented and in many aspects proprietary. So it was no surprise to me when the Linux Foundation announced the ‘Zephyr’ project back in February 2016:
“The Linux Foundation Announces Project to Build Real-Time Operating System for Internet of Things Devices. Open source Zephyr™ Project aims to deliver an RTOS; opens call for developers to help advance project for the smallest footprint IoT devices.“
Ζεφυρος (Zephyros) is the Greek good of spring and the west wind. Obviously this inspired the logo for the Zephyr project:
The Raspberry Pi is a versatile mini computer: as such I can use it with USB keyboard, mouse and HDMI LCD monitor. But having multiple keyboards and mouse on my desktop is not my thing: somehow I always grab the wrong one. So what I prefer is to run the Raspberry with VNC (Virtual Network Computing). That way I have the Linux GUI as a window on my normal desktop, and no messing up with keyboards and mouse 🙂 :
Raspberry Pi on my Dekstop
MCU on Eclipse 