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.
By default, when debugging an embedded application, the target usually stops at main():
That’s usually fine, but what if I want to debug the code out of reset?
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 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 🙂
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 …
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.
Modern microcontroller come with plenty of internal FLASH memory. On the other side, many high performance MCUs as the NXP i.MX RT are ‘flashless’, because the silicon process for high performance cores is not matching the FLASH memory technology, so they are using external serial SPI or Quad-SPI (QSPI) memory instead.
Why not using an external SPI FLASH for a ‘normal’ microcontroller too?
I’m using the VL6180X ToF (Time-of-Flight) sensors successfully in different projects. The VL6180X is great, but only can measure distances up to 20 cm and in ‘extended mode’ up to 60 cm. For a project I need to go beyond that, so the logical choice is the VL53L0X which measures between 30 cm and 100 cm or up to 200 cm. For this project I’m using the VL53L0X breakout board from Adafruit, but similar products are available e.g. from Pololu.
Working with low power modes can be challenging. It can severely affect debugging capabilities of a microprocessor or microcontroller. I ported a FreeRTOS application using the Tickless Idle Mode to the NXP i.MX RT1064 board, and all of a sudden, the board was unresponsive to any debugger connection. Luckily the board was not really bricked, but it took me while to find a way to recover it. So for when you end up in a situation with a ‘bricked’ i.MX RT1064 board, this article might be helpful for you to recover it.