A 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.

A 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.

The NXP i.MX RT685 is an interesting device: an ARM Cortex M33 with a Cadence Xtensa audio DSP. To explore the features of the device, I’m using the NXP EVK board:

I have used it so far with the on-board MCU-Link debug probe and LinkServer. This article describes how I have added pyOCD as debug interface for the RT685, as well how to patch and use custom DFP (Device Family Pack) files with pyOCD and Eclipse.
Continue readingEurope is currently facing an ‘Energy Crisis,’ and ‘Sustainability’ is a popular topic among companies. However, embedded engineers go beyond talking—they take action and make tangible changes in the world. With the increasing use of electronic devices, minimizing their energy and power consumption is crucial. Optimizing systems for deep low power or deep low energy is a challenging task. Nonetheless, as I will demonstrate in this article, it is possible to reduce energy consumption by a factor of 100 or more. This article provides a brief overview of the foundational concepts and then applies them step-by-step to an ARM Cortex microcontroller.

Eclipse includes many ways to build a project. One of it is the built-in builder which makes it super easy. And for more complex building needs I can use an external make (see Tutorial: Makefile Projects with Eclipse) or cmake or combination of multiple ways (see Building a Triumvirate: From Eclipse CDT to CMake, CMD and Visual Studio Code).
There is yet another use case how to easily tweak the build process in Eclipse: using a script file in the project to be used as the ‘compiler’:

That way I can do all kind of custom steps (analysis, re-formatting, static checkers, …) for each file compiled.
Continue readingThis week I have received the new PCBs for the MCU-Link MR for drones and robots and have populated the parts on the PCB, and it works fine as UART bridge and debug probe for the PixHawk i.MX RT:

The MCU-Link debug probes are versatile and very useful debug probes from NXP. This article describes how to update the firmware on it, both the ‘traditional’ way with using the ISP jumper, and the new way using a command line script without the need to use a jumper.

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.

Float and double data types area a bad choice for embedded applications. At least in most applications, and can or should be avoided, even with hardware FPU support present.
But how can I be sure that no floating point operations are used?

This article describes how to configure the GNU toolchain, so that no float or double operations are used, with the example of ARM Cortex-M. What I do? ‘Poisoning’ (!!!) the source code, force the gcc compiler to use software floating point operations and then catch them with the GNU linker :-).
Continue readingMany cost-sensitive ARM Cortex-M devices like the M0+ do not have a hardware floating point unit, and some like the M4 only has an optional single-precision floating point unit (FPU). As outlined in “Be aware: Floating Point Operations on ARM Cortex-M4F“, using floating point operations without a hardware unit can be costly.
Looking at the disassembly for sure will tell you if the hardware is handling the float or double operation or not:

But who wants check the all the disassembly? With the GNU tools there is an easier way: readelf.
Continue readingWho 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.
