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.
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:
- Excessive writes to the SD card can wear it out
- Sudden power failure during a SD card write can corrupt the file system
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.
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.
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…
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:
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:
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.
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:
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.
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.
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.
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:
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)!
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.
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.
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:
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 …