The MCU-Link is an inexpensive CMSIS-DAP debug probe from NXP. It can be used as a GDB server debug probe, and as such it includes scripting support. This scripting can be very useful in some cases where the MCU cannot be accessed by a normal debug session. This happens for example if students are not pay attention what binary they flash to which device, causing an MCU to potentially get ‘bricked’.
If one is using a dedicated logger module like the McuLog, then you don’t have to worry or care about timestamp support. But if your application is using normal printf() calls for for logging purpose, you will face issues to adding timestamps to it. You might consider to change all prinft() calls. This might be a lot of work, or not possible in all cases if you cannot change the source code.
But there is a really cool feature of the GNU linker to solve that problem. It allows to ‘wrap’ around any symbol or function, including the ones in the standard library. That way I can add my mode to the printf() code as a wrapper, for example adding a timestamp for every call.
In the example below you can see this in action:
printf() calls with added timestamps
In this article I’ll show how you can wrap any function with custom code.
In many of my embedded projects I need persistent data or storage for settings. If using an SD card, then FatFS is usually my choice for the file system. But if using an external FLASH memory device, then my preferred choice is usually LittleFS: it is a little fail-safe filesystem, designed for micro-controllers, which I’m using with external flash memory devices.
In the case where there is enough MCU flash, or if there is no external FLASH device available in a design, it can use the MCU internal FLASH as storage storage too. This is the topic of this article:
Embedded hardware comes with limitations, and one if it is the given number of hardware breakpoints. Depending on your MCU, 4 or only 2 hardware breakpoints are available, making debugging and stepping in read-only memory (FLASH) a challenge.
Debugging NXP LPC845 with unlimited FLASH Breakpoints using MCU-Link
Did you know that one can have ‘unlimited’ number of breakpoints in FLASH, with the help of GDB? This is very useful for extended debugging, or if you want to use breakpoints for testing?
Sometimes it makes sense to write everything in assembly, even these days. For example if using a tiny microcontroller. Or just if one just don’t need all the productivity of the C/C++ tools. And it is a good educational experience: getting hands-on on the lower levels.
A Triumvirate is or Triarchy is built by three individuals which lead or rule something. In this article I want to rule a project with Eclipse CDT, Visual Studio Code and with building it from the command line for automated builds.
So what if I have an Eclipse project (say MCUXpresso IDE and SDK), and want to build it on a build server, and and I want to use the same time the project with Eclipse IDE and Visual Studio code?
Key to this is CMake: I’m keeping the Eclipse CDT features, adding CMake with Make and Ninja to the fix, and have it ‘ruled’ by three different ’emperor’: Eclipse, Visual Studio Code and from a shell console:
MCUXpresso SDK CDT project with CMake for Eclipse, Visual Studio Code and Command Line BuildingContinue reading →
We all should know it: dynamic memory usage can be dangerous. There can be memory fragmentation, use-after-free, out-of-memory and memory leaks. While I do prefer static memory allocation for embedded systems, using a dynamic memory allocation in some applications is not avoidable or just makes sense.
In one of my lecture modules we develop a ‘Boulder’ game, where the player has to collect underground diamonds and avoid moving monsters:
LPC845-BRK with OLED using dynamic memory allocation
I’ll show you have FreeRTOS memory usage can be tracked and monitored.
I love the WS2812B (aka SK6812) addressable LEDs: they are inexpensive and available in different packages. I have used them in different projects, including the MetaClockClock one. I used the NXP Kinetis for these projects, but because they are not available any more, for a new project we had to choose a new microcontroller, with the Raspberry Pi Pico RP2040 as the winner.
Raspberry Pi Pico RP2040 driving WS2812B with PIO and DMAContinue reading →
When something goes wrong in an embedded system, a watchdog timer is the last line of defense against a blocked or malfunctioning system. A watchdog is a special timer which needs to be ‘kicked’ in a special way, otherwise the timer will run out and reset the system.