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 LoRaWAN gateway (“Contributing an IoT LoRaWAN Raspberry Pi RAK831 Gateway to The Things Network” is running and working great now for more than a month and it already has transmitted more than 30k messages:
Gateway Overview
This creates a lot of log entries on the micro SD card of the Raspberry Pi. To avoid writing too many times log data, I have installed Log2Ram.
In the IoT world, it is all about security, connectivity and low power. LoRaWAN with the Things Network is able to connect devices over several kilometers, and I’m running my gateway for it already (see “Contributing an IoT LoRaWAN Raspberry Pi RAK831 Gateway to The Things Network“). This tutorial is about building a BLE+LoRaWAN+GPS sensor node with GNU tools and Eclipse:
LoRa+BLE with RAK813 and LPC845
In “Debugging the RV32M1-VEGA RISC-V with Eclipse and MCUXpresso IDE” I described how to build and debug applications for the VEGA RISC-V board. In this article I describe how to enable FreeRTOS for RISC-V, based on the latest FreeRTOS V10.2.0 release.
Blinky with FreeRTOS on the VEGA RISC-V Board
The ARM Cortex cores are everywhere. I like (and use) them a lot. Don’t take me wrong: maybe ARM needs some competition? It is very refreshing to see that something new is getting a lot of attention: RISC-V!
RV32M1 (VEGA)
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
LoRa and LoRaWAN is getting the de-facto wireless IoT network in my area. No surprise that traditional telecom providers like Swisscom trying to monetize the ‘Internet of Things’ area. Luckily there is an open and free alternative: https://www.thethingsnetwork.org/. Volunteers, enthusiasts and members in the different TTN communities build gateways and offer free LoRaWAN network access. I wanted to contribute to that grassroots movement with building my gateway, providing LoRaWAN access to my neighborhood.
LoRaWAN TheThingsNetwork Gateway
Sometimes I start a project with an ARM microcontroller, and in the middle of the project I find out that it was a wrong choice at the beginning and I need to switch the microcontroller derivative or even the used ARM core. With little knowledge of the project structure and the files needed, such a switch is not the easiest thing, but definitely possible.
switching cores
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
One great thing with that new NXP LPC845-BRK board is that it is possible to use it with any standard SWD/JTAG debugger, as it has the 10pin debug header present on the board. It is not populated by default, because the LPC845-BRK includes a CMSIS-DAP debug probe already. But if I want to use a SEGGER J-Link, a P&E Multilink or the NXP LPCLink2, this is certainly something to consider:
Debugging LPC845-BRK with LPC-Link2
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 …
