The previous parts were about installation, project setup and building. This one is about debugging an ARM Cortex-M Microcontroller with Visual Studio Code:
Visual Studio Code for C/C++ with ARM Cortex-M: Part 4 – Debug
39
Category Archives: Tutorial
Visual Studio Code for C/C++ with ARM Cortex-M: Part 3 – Build
This is the third part in a series to get up and running using the Microsoft Visual Studio Code for embedded development on ARM Cortex-M. So far we have installed the needed tools, created a project and are able to build it from the command line. Now it is about how execute directly scripts or the build from the IDE.
Visual Studio Code for C/C++ with ARM Cortex-M: Part 2 – Project
This is the second part of series or articles how to use the Microsoft Visual Studio Code for embedded development on ARM Cortex-M. In this part I’m going to show how to create and build a project using CMake running Make or Ninja as build system.
Visual Studio Code for C/C++ with ARM Cortex-M: Part 1 – Installation
For a few months I’m learning and using Rust. I’m still learning, but I’m very impressed by the powerful and cool programming language, the vibrant ecosystem, the advanced concepts behind it and by the tools. With learning Rust I have been using the Visual Studio Code IDE and it works great for Rust. But I was wondering: could I use it for my ‘usual’ C/C++ development on ARM Cortex-M devices too? The answer is a clear ‘yes’, and this mini series of articles should get you up and running too.
Upgrade to a new NXP MCUXpresso SDK
As time flies by, my projects are evolving. My lab projects get used over multiple semesters, and the MCUXpresso projects by default use the SDK version used at that time.
This is great because I do want to have control over what SDK is used. But from time to time it makes sense to upgrade a project to a newer version. In this post I’ll show how an existing project can be upgraded to use a new SDK.
Continue readingAttach with the Debugger to a Running Target
Sometime I’m pretty sure I wrote about a topic I can find or refer to, and I was pretty sure I did write about ‘attaching to a running target’ using MCUXpresso IDE in an article, but Google does not find it? The only rational outcome is that I can blame Google and I have to come up with a potential duplicate ;-).
Anyway: attaching to a running target is such an essential life saver it deserves a dedicated article.
Debug Firmware Switching for the LPC4322
In “Freelink LPC4322JET100 based Debug Circuit on NXP i.MX RT1064-EVK Board” I described how to change the factory firmware from OpenSDA to the LPC-Link2 one.
Now it is possible to use a Segger J-Link firmware too, or to switch back to the factory default one.
Continue readingMetaClockClock Build Instructions
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.
Tutorial: GNU Coverage with MCUXpresso IDE
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.
assert(), __FILE__, Path and other cool GNU gcc Tricks to be aware of
It is always good to have a close look what ends up in a microcontroller FLASH memory. For example using EHEP Eclipse plugin to inspect the binary file:
Source File Name in Binary Image
Obviously it has path and source file information in it. Why is that? And is this really needed?
What about:
- Privacy: the path or file name might expose information (secret project name?) or might be used for reverse engineering?
- Size: The strings add up to the final data/FLASH size, so this increases the need for ROM space?
So let’s have a look what is the reason for this and how it could be avoided or at least reduced.
MCU on Eclipse 