The holiday break at the end of the year is always a good time to finish projects started during the year. This one is about my ‘MetaClockClock’ Version 3.
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 MCU-Link is a $10 CMSIS-DAP capable debug probe which works out-of-the box with the MCUXpresso Eclipse based IDE. This is great for development, but how can I programming with the push of a button or a script? The answer is no: there is an easy way to use the debug probe outside Eclipse from a shell script, and you can use that MCU-Link probe to do the job. This is especially useful as with the example below where I have to program 60 boards this week-end :-).
The NXP Kinetis devices implement a UID (Unique ID) for each device, using the ‘Unique Identification Register) which is part of the SIM (System Integration Module):
While this number should be unique, I was wondering last week why students in the labs reported the same UID for multiple robots in the lab. So maybe this number is not so unique as it should be?
Reentrancy is an attribute of a piece of code and basically means it can re-entered by another execution flow, for example by an interrupt or by another task or thread. This is an important concept and still a lot of code ‘in the wild’ does violate reentrancy. As a result the application crashes immediately in the best case. Worse it crashes randomly or even worse it behaves incorrectly 😦 .
Reentrancy is always a concern if using standard library functions, including printf() or malloc(). FreeRTOS offers a reentrant wrapper to the standard malloc() and free() (Memory Scheme 3)
If having a boot loader running on a micro-controller, it is very useful if both the boot loader and the loaded application can be debugged together:
Implementing low power in embedded applications implemented can be challenging. Measuring current consumption is a first step to see if the software changes indeed have an effect on the current consumed. The PEmicro Universal Multilink FX debug probe comes with a useful feature to provide power to the target and the same time to measure the current consumption and to show the current used in the Eclipse IDE:
Eclipse has a great built-in source code parser and browser (aka ‘Indexer’). It is basically a built-in compiler which parses the source files and assists the user with code completion and navigation help, making Eclipse this awesome productivity tool. On the downside this background parsing could potentially slow down things, and therefore Eclipse has some default settings to prevent this. Unfortunately, the FreeRTOS Kernel ‘tasks.c’ file is above-and-beyond of a ‘sane’ source file and will hit the default limits: as a result the ‘tasks.c’ file is not indexed and things like ‘Open Declaration‘ might not work for the file ‘tasks.c’.
Typically I have many, many projects listed in the Eclipse Project Explorer, usually more than 100 projects: from example projects, projects on git, lecture module projects, research projects or just some hobby projects I’m working on. With the default Eclipse settings, all these projects are listed in a ‘linear’ list. What I found really useful is the ability to group them into ‘Working Sets‘: