An important part of every CI/CD pipeline is having a testing phase. In this article I show how to use GNU gcov (coverage) with an embedded target, using Visual Studio Code as front end:
With this, I can run the code on the embedded target which stores the coverage data on the host.
Continue readingI’m working recently on a new lecture module using the Raspberry Pi Pico (RP2040) board, which highlights several aspects of modern software engineering, including DevOps and CI/CD. An important part of any CI/CD pipeline is testing. For a host application, one could pass arguments to the application, e.g. ‘myapp --test=module1‘, or let it read such information from a configuration file which describes the tests. Or write GNU gcov data to a file to collect coverage information.
Unfortunately, a normal embedded application has no argv[], and many system have no file system. A solution to this problem would be using semihosting with file I/O. Unfortunately for the Raspberry Pi Pico SDK 1.5.1 for the RP2040, there is no semihosting file I/O implemented :-(.
I have now implemented and added file I/O to the SDK, making it possible for the RP2040 to access and use files on the host, among other things. This greatly extends the capabilities of the device, and is very useful for testing, including gathering test coverage information.
For systematic debugging, an engineer needs a debug probe. For the Raspberry Pi Pico (RP2040) device there are plenty of debug options with VS Code.
In this article I show different options, from professional tools to DIY solutions and the settings in VS Code I’m using.
Continue readingWith semihosting I can use standard I/O function like printf() and I can read and write data on the host through the debug connection. If used with care, this is a great feature especially for unit testing.
“Our highest priority is to satisfy the customer
Agile Manifesto, https://agilemanifesto.org/principles.html
through early and continuous delivery
of valuable software.”
It is interesting to see that modern tools and agile development workflows are getting more and more into the embedded world. CI/CD is a strategy where code changes to an application get automatically integrated, tested and released automatically into a production environment.
I have lots of hardware and debug probes on my desk, and I discussed using nicknames for debug probes to better identify them.
So far so good. At that time of the previous article, it was possible to assign nicknames to J-Link debug probes, but not to use the nickname instead of the USB serial number. Well, SEGGER was fast again, and responded with a new J-Link software pack version 7.92d which implements that features: I can now use the nickname to connect to a debug probe :-).
Continue readingSometimes I have a wish. Not every time it gets fulfilled. But this time I’m lucky and happy developer. A few days ago I wrote about the LPC4322-based SEGGER OB (on-board) J-Link firmware. It works great, but the board requires another USB cable to power the target board.
Rolf Segger contacted me, and a few days later I had a J-Link firmware with a ‘power-on’ feature:
That way, only one USB cable is needed. All what you need to do is to update the firmware.
Continue readingGoing with the factory default can be fine. But an upgrade could give a performance boost plus added functionality. Many of the NXP i.MX RT evaluation boards have an LPC4322 based debug circuit on it. One example for this is the i.MX RT1010 board.
On such boards, one of the first steps I do is: upgrading the firmware and change it to a better option: improved speed, SWO support plus avoiding issues with the USB MSD device.
Continue readingIn my previous article I showed how to import, build and debug MCUXpresso SDK projects in VS Code. In my lectures and labs we are using a robot based on the NXP Kinetis K22FX512 ARM Cortex-M4F microcontroller, and there is only the v2.13.0 SDK available.
The software on the robot uses the latest NXP MCUXpresso SDK v2.3.1. The he Eclipse based MCUXpresso IDE 11.8.0 works fine with all the 2.x SDKs, up to the latest 2.13.0 one.
Continue readingUpgrading to a newer GNU toolchain always has its risks. That’s why I always recommend to stay on a given toolchain for production code.
But sometimes one needs to upgrade, or gets a code or project that works in one environment, but not in another. Today I have run into a problem with code read-out projection:
Well, the code read-out protection is not the root of the problem, but a good example why problems could occur.
Continue reading
MCU on Eclipse 