A few days ago NXP has released a new version of their Eclipse IDE flagship: the MCUXpresso IDE v11.0.
NXP MCUXpresso IDE V11.0.0
The previous v10.3.1 was released back in Feb 2019, and the 11.0 now in June this year matches up with the Fall university semester. I appreciate that the releases are about every 6 months, so this gives me time to use it in my university lecture material and lab work. I had the weekend for trying it out, and I’m very pleased.
With the cost of an single pin, many ARM Cortex-M boards including the NXP i.MX RT1064 can produde SWO data: think about a pin able to stream data out of the chip in realtime. For example interrupt activity which otherwise might be hard to capture:
SWO Interrupt Trace
In a modern development workflow both command-line and a graphical user interface has its place. On the GUI side, Eclipse is famous that it offers many different ways to accomplish something which is great. But sometimes I continue to use an old habit or way because I have missed that there is a newer and better way, and the MCUXpresso Eclipse IDE is no exception to that. In this article I show a few ways how to use the mouse even more productive.
Project Settings
In my previous articles I have used the command line on Linux to build and debug NXP MCUXpresso SDK applications. In this article I’m running code on NXP i.MX RT1064 in RAM or FLASH.
i.MXRT1064 board with LPC845-BRK as debug probe
The LPC55S69-EVK board comes on-board debug probe. The board includes the LPC4322JET100 device which acts like NXP LPC-Link2 debug probe:
LPC4322JET100 on LPC55S69-EVK
But it is easily possible to use the board with an external debug probe or re-program the onboard one as a SEGGER J-Link debug probe.
There are different ways to ruin a Linux system. For the Raspberry Pi which uses a micro SD card as the storage device by default, it comes with two challenges:
For problem one I do I have a mitigation strategy (see “Log2Ram: Extending SD Card Lifetime for Raspberry Pi LoRaWAN Gateway“). Problem two can occur by user error (“you shall not turn it off without a sudo poweroff!”) or with the event of a power outage or black out. So for that problem I wanted to build a UPS for the Raspberry Pi.
Raspberry Pi with UPS System and tinyK22
The ARM TrustZone is an optional secu=rity feature for Cortex-M33 which shall improve the security for embedded applications running on microcontroller as the NXP LPC55S69 (dual-core M33) on the LPC55S69-EVK.
NXP LPC55S69-EVK Board
For the long Easter weekend I have organized a new toy: the NXP LPC55S69-EVK board: a dual ARM Cortex-M33 running at 100 MHz with ARM TrustZone:
LPC55S69 Microcontroller
In “Tutorial: MCUXpresso SDK with Linux, Part 1: Installation and Build with Maked” I used cmake and make to build the SDK application. In this part I’m going to use the command line gdb to debug the application on the board.
Cross-Debugging with GDB
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
My mantra is *not* to use any floating point data types in embedded applications, or at least to avoid them whenever possible: for most applications they are not necessary and can be replaced by fixed point operations. Not only floating point operations have numerical problems, they can lead to performance problems as in the following (simplified) example:
#define NOF 64
static uint32_t samples[NOF];
static float Fsamples[NOF];
float fZeroCurrent = 8.0;
static void ProcessSamples(void) {
int i;
for (i=0; i<NOF; i++) {
Fsamples[i] = samples[i]*3.3/4096.0 - fZeroCurrent;
}
}
For some projects it is not possible to have the device under debug available on my desk: the board might be in another room, on another site or in a place where physical access is not possible or even dangerous. In that case an IP-based debug probe (see Debugging ARM Cores with IP based Debug Probes and Eclipse) is very useful: as long as I can access its IP address, that works fine. It is an excellent solution even if the board is moving or rotating: hook it up to a WLAN access point and I still can use it as it would be on my desk.
But what if I have a debug probe only connected to USB? This article shows how to turn a USB debug probe into a IP-based debug solution: that way I can easily debug a board from remote, connected to the network:
IP Based Debugging with USB Debug Probe
On Friday a new release of the Eclipse Oxygen based NXP MCUXpresso IDE V10.3.1 has been made available. The IDE supports MacOS, Linux and Windows 32/64-bit and will be 64-bit only going forward.
MCUXpresso 10.3.1 About Information
The NXP LPC845-BRK board is a sub-$6 breadboard friendly development board with an ARM Cortex-M0+ on it. This tutorial is about developing a ‘blinky’ on it using MCUXpresso.
Binky on NXP LPC845-BRK Board
The NXP LPC845-BRK board is a tiny an inexpensive (sub $6) breakout board. The board includes a CMSIS-DAP (LPC11U35) on-board debug probe which can be used as a debug probe to debug any NXP LPC, Kinetis or i.MX RT device 🙂
LPC845-BRK used to debug a Sumo Battle Robot
I really love tiny and bread board friendly boards, especially if they are very affordable and can be use with Eclipse based tools. So I was excited to see the NXP LPC845-BRK board to be available at Mouser, so I ended up ordering multiple boards right away. Why multiple? Because they only cost CHF 5.95 (around $6)!
NXP LPC845-BRK Board
In the age of high-resolution graphical LCDs using a character display might look like a bit anachronistic. But these displays provide a lot of value for me as they are robust, available in different shapes and number of lines. And such a character display can be a better solution for an industrial application.
hd44780 display with NXP FRDM-KW41Z Board
It is a common thing to boot a Linux system (see the Raspberry Pi) from a micro SD card. It is not that common for a microcontroller. The NXP i.MX RT ARM Cortex-M7 fills that gap between these two worlds. No surprise that it features a ROM bootloader which can boot from a micro SD card.
SD Card with i.MX RT1052
Most host or desktop systems (say Linux, Mac or Windows) have a normal use case where you start the operating system say in the morning and shut it down in the evening, and then you leave the machine. Embedded Systems are different: they are not attended, and they are supposed to run ‘forever’. Not every embedded system needs to run an OS (or in that world: Real-Time Operating System or RTOS), but the same applies here: after the RTOS is started, it is not intended that it will shutdown and restart. To the extend that you won’t they support the ‘shutdown’ and ‘restart’ functionality at all. In case of gathering coverage information this would be really useful:
coverage information from FreeRTOS application
In the case of FreeRTOS: what if I really need to shutdown the RTOS and restart it again, as by default this is not supported. This is what this article is about …
GDB supports a mode which allows the GDB debug client to read memory while the target is running. This allows features like ‘live variables’: that way I can see the variables refreshed and changing over time without halting the target. Another functionality which comes with that feature is to check stopped threads or to see all threads in the system.
multiple FreeRTOS threads in debug view
