If you are not aware (yet?): it looks like the COVID pandemic caused a global silicon and microcontroller shortage with lead times >50 weeks in some cases. The microcontroller I have used for the MetaClockClock build (see “New MetaClockClock V3 finished with 60 Clocks” and “MetaClockClock V4 for the Year 2021“) is affected by this too, but I had luck and still enough microcontrollers to build a few more boards.
So I still have enough for building a new variant with it (not finished yet). While everyone else is waiting for the devices to arrive, here are more details and instructions for your own build.
One of the most frustrating part developing embedded applications is if the debug connection fails somehow: with all the different factors like operating system, virtual machines, USB ports and hubs, debug probe and firmware a ‘connection failed’ is my nightmare. And this is probably the most frustrating parts for my students (and myself!)
If you are developing Linux or desktop applications with GNU tools, you very likely are familiar with gcov: the GNU coverage tool. It collects data what parts of the code gets executed and represents that in different formats, great to check what is really used in the application code or what has been covered during multiple test runs.
Coverage Information with gcov
line never executed
GNU coverage is possible for resource constraint embedded systems too: it still needs some extra RAM and code space, but very well spent for gathering metrics and improves the firmware quality. As I wrote in “MCUXpresso IDE V11.3.0 for 2021” things are now easier to use, so here is a short tutorial how to use it.
Something what I say quite often is: “Google is your friend”. It means that the answer to many questions can be found with an internet search engine. And I have to admit that I have to ‘google’ my own articles to find solutions for problems I feel I have seen in the past too :-).
But for the one problem below I did not find anything: not on my own blog, and not anywhere else in the internet:
I had a few of PCBs left over from the V3 MetaClockClock, and originally I planned to finish a build with them by the end of 2020. But as always: things took a bit longer than expected, so I finally finished it today on the first day of the year 2021.
The build uses the same hardware as in the previous V3, but instead of an ‘artistic’ canvas background I decided for a more natural and wood design:
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):
SIM Unique ID (NXP K22P144M120SF5RM.pdf Reference Manual)
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? Continue reading →