The NXP MCU-Link is a powerful $10 debug probe for ARM Cortex-M devices and works with the NXP LinkServer for debugging. The LinkServer does not an implement a gdb server, so it limits its usage e.g. for scripting or command line debugging. But as MCU-Link is also a CMSIS-DAP compatible debug probe, I can use it with OpenOCD which is open source and implements a GDB server. This article shows how I can use it with the MCU-Link.
The ‘Black Magic Probe’ (or in short: BMP) is a very small and open source JTAG/SWD debug probe with a build-in GDB Server. I saw that probe referenced in different places, so I thought I try it out with a few of my NXP LPC and Kinetis boards:
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…
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.
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.
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.
You might wonder what ‘Zork‘ is? Zork is one of the first and earlist fictive computer games, written around 1977 and 1979, written in MDL on a DEC PDP-10 by members of the MIT Dynamic Modelling group (see https://en.wikipedia.org/wiki/Zork). I believe the first time I have played Zork was around 1984 on a Commodore 64.
With Eclipse as IDE it is very easy to debug an application on a board. Still sometimes it is useful to get one level down and control the GDB server directly.