COVID-19 is by far not over, and in Switzerland the infection rate is going up again (2nd wave?). During the spring 2020 semester university lock-down we moved pretty much everything to a ‘distance learning’ setup. With that experience and with the request to prepare for the fall semester, I have constructed a DIY conference and teaching device which should make things simpler and easier: a combination of video camera, speaker phone and a muting device:
At the university the end of a semester means that you have to get ready for the next semester. I always tend to use the latest and greatest tools for the labs. This week I received the notification that a new version of the Eclipse based MCUXpresso IDE is available, time to check it out for the next semester.
This is a follow-up article of my earlier project presented in “FatFS, MinIni, Shell and FreeRTOS for the NXP K22FN512“. I wanted to extend it with a USB MSD (memory stick) device: The USB storage device gets automatically mounted, and depending on a configuration (.ini) file on the memory device I can perform various actions, for example automatically copy data from the SD card to the USB device. For example the system logs data, and to get the data I insert the memory stick, it copies the data on it and automatically unmounts it, and I can remove the memory stick.
The NMI is a special interrupt on ARM Cortex-M architecture: as the name indicates, it cannot be ‘masked’ by the usual ‘disable interrupts’ flags (PRIMASK, BASEPRI), similar to the Reset signal.
cortex-m-vector-table (Source: adapted from arm.com)
Dealing with the reset signal is kind of obvious, and most designs and boards have it routed to a reset button or similar. The NMI is less obvious if you don’t pay attention to it: most ARM-Cortex implementations and boards have the NMI signal routed to a pin and are ‘hiding’ it in the schematics behind a normal GPIO pin or port: if you don’t pay attention to the NMI functionality, the board might not work as intended.
As promised I’m going to share more details about the “60 Billion Lights” project. It is about a project to build a piece of electronics behind a 100×50 cm canvas to show animations or to display information like temperature, humidity, weather, time or just any arbitrary text.
I’m using the NXP Kinetis K22FN512 in many projects, either with the FRDM-K22F or on the tinyK22: with 120 MHz, 512 KByte FLASH and 128 KByte it has plenty of horsepower for many projects. The other positive thing is that it is supported by the NXP MCUXpresso IDE and SDK. I have now created an example which can be used as base for your own project, featuring FreeRTOS, FatFS, MinIni and a command line shell.
The tinyK22 board with the NXP K22FN512 is a bread-board-friendly small board with a 8 MHz external oscillator:
This tutorial is about how to use the NXP MCUXpresso Clock configuration and configure the board to the maximum clock frequency of 120 MHz. The same steps apply to many other boards, including the FRDM-K22F one.
Right before Christmas 2019, NXP has released a new version of the MCUXpresso IDE, the version 11.1.0. This gave me time to explore it over the Christmas/New-Year break and evaluate it for the next university semester. There are several new features which will make my labs using it easier, so I plan to get the course material updated for it.
When using an RTOS like FreeRTOS, sooner or later you have to ask the question: how much time is spent in each task? The Eclipse based MCUXpresso IDE has a nice view showing exactly this kind of information:
FreeRTOS Runtime Information
For FreeRTOS (or that Task List view) to show that very useful information, the developer has to provide a helping hand so the RTOS can collect this information. This article shows how this can be done on an ARM Cortex-M.
Bootloaders are a fine thing: With this I can load any applications I like. Power comes with some complexity, and a bootloader alone is a complex thing already. But this applies to the application part too: I need to link the application to a certain offset in the memory space so it can be loaded by the bootloader, plus the application typically needs to add some extra information to be used by the bootloader. This article describes how to build a bootloader application with Eclipse (MCUXpresso IDE) using the MCUXpresso SDK.
Stack overflows are probably the number 1 enemy of embedded applications: a call to a a printf() monster likely will use too much stack space, resulting in overwritten memory and crashing applications. But stack memory is limited and expensive on these devices, so you don’t want to spend too much space for it. But for sure not to little too. Or bad things will happen.
The Eclipse based MCUXpresso IDE has a ‘Heap and Stack Usage’ view which can be used to monitor the stack usage and shows that a stack overflow happened:
Heap and Stack Usage
But this is using the help of the debugger: how to catch stack overflows at runtime without the need of a debugger? There is an option in the GNU gcc compiler to help with this kind of situation, even if it was not originally intended for something different. Continue reading →
The Espressif ESP32 devices are getting everywhere: they are inexpensive, readily available and Espressif IDF environment and build system actually is pretty good and working well for me including Eclipse (see “Building and Flashing ESP32 Applications with Eclipse“). The default way to program an ESP32 is to a) enter UART bootloader by pressing some push buttons and b) flash the application with ESP-IDF using a USB cable.
That works fine if the ESP32 is directly connected to the host PC. But in my case it is is behind an NXP Kinetis K22FX512 ARM Cortex-M4F microcontroller and not directly accessible by the host PC. So I had to find a way how to allow boot loading the ESP32 through the ARM Cortex-M which is the topic of this article.
That machine has now been modified to dispense solder paste. I did not had time yet to describe the build, but as I have received recently many questions: here are some pre-information about the build:
By default, Eclipse provides ‘stop-mode-debugging’: in order to inspect the target code and data, I have to stop the target. But with the right extensions as present in the Eclipse based MCUXpresso IDE, it is possible to inspect the target even while it is running.
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:
A few days ago NXP has released a new version of their Eclipse IDE flagship: the MCUXpresso IDE v11.0.
NXP MCUXpresso IDE V11.0.0
The previous v10.3.1 was released back in Feb 2019, and the 11.0 now in June this year matches up with the Fall university semester. I appreciate that the releases are about every 6 months, so this gives me time to use it in my university lecture material and lab work. I had the weekend for trying it out, and I’m very pleased.
In a modern development workflow both command-line and a graphical user interface has its place. On the GUI side, Eclipse is famous that it offers many different ways to accomplish something which is great. But sometimes I continue to use an old habit or way because I have missed that there is a newer and better way, and the MCUXpresso Eclipse IDE is no exception to that. In this article I show a few ways how to use the mouse even more productive.