Author Archives: Erich Styger

Unknown's avatar

About Erich Styger

Embedded is my passion....

Consolidating with VS Code

Posted on by
26

It is August 1st, and Switzerland is celebrating its National Holiday. Rather cold and rainy, so this gets me some time to catch up on things. The preparation for the coming university semester in September is in full swing, and I have the honor to take over building up a new Master of Science in Engineering education module. In the existing courses I teach on the topic of embedded systems, I do use devices and MCUs from vendors like Broadcom, NXP, STM, Nordic, Raspberry Pi and Espressif. This not only means different SDKs, but different IDEs with different debug probes.

Just a subset of different hardware kits used in different labs

Eclipse has been the common factor in the mix with all these, and with all the pros and cons, it worked very well. With NXP having released support for Visual Studio Code, adding an announcement, and other vendors going into the same direction, I took the decision that I want to migrate my lab and lecture infrastructure to VS Code.

Continue reading →

Using Legacy Devices with LinkServer

Posted on by
2

The Freescale K20DX128 MCU was one of the first ARM Cortex-M devices of that company (now NXP) back in 2012, and the FRDM-K20D50M board was the first ‘FRDM‘ board of a long and successful series of boards, starting back in 2013. I still have the K20 present in many of my designs. The challenge with ‘early’ or ‘legacy’ devices is that after a while, they are ‘not recommended’ any more, and it is hard to get support for them. So for example in newer tooling and software from NXP, there is no support for the K20.

MCU-Link (NXP, left) debugging FRDM-K20 (Freescale, right) board

So if you still have the K20 around, and need some newer tooling, then I have good news for you: It is possible to add that good-old-Kinetis to the list of supported LinkServer devices, so you are not stuck and can use newer debugging solutions for the K20.

Continue reading →

Data Converter for MCUXpresso Energy Measurement Data

Posted on by
Reply

The combination of the NXP MCUXpresso IDE with the NXP MCU-Link Pro debug probe implements a nifty power and energy measurement tool (see New “MCU-Link Pro”: Debug Probe with Energy Measurement). The eclipse based IDE provides a dedicated view to inspect the data collected. It can export and import data, but it is in a binary format. In this article I present a way to export and then convert the data into .csv or any other format for processing or visualizing it in different ways.

Exporting data to gnuplot and csvplot

Using an open source command line tool, the binary data gets converted into a csv format, which then can be consumed by many tools, e.g. gnuplot.

Continue reading →

LinkServer Scripting, and how to Recover MCUs with a Script

Posted on by
2

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’.

NXP MCU-Link debug probe connected to Sumo Robot
Continue reading →

GNU Linker Wizardry: Wrapping printf() with Timestamps

Posted on by
3

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.

Continue reading →

LittleFS File System with MCU Internal FLASH Memory

Posted on by
8

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:

LittleFS File System Data
Continue reading →

‘Nicer Coding’: Ligatures with Eclipse and Visual Studio Code

Posted on by
7

The choice of IDE is sometimes given by the available tools at hand. And sometimes it is a preference of the look and feel. Or maybe just what one is used to use. And sometimes small changes can make a big difference too.

For example, when I’m starring at my code for hours, a nice font can make all the difference. A cool and nice feature of fonts are ‘Ligatures‘. Maybe you can you can spot them in the following screenshot?

Eclipse with Ligatures
Continue reading →

Catchpoints: Unlimited Number of FLASH Breakpoints with GDB

Posted on by
2

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?

Continue reading →

Creating a GNU Assembly-Only Project

Posted on by
Reply

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.

Debugging an Assembly-Only Project
Continue reading →