While developing applications, it can happen that things go wrong. And in my case I ended up with two LPC55Sxx EVK boards on my desk, which seemed not to be usable any more. The issue: the boards were not accessible with the debug probe, because right after main they muxed the pins in a wrong way :-(.
The standard GDB debug connections (both on-board and off-board) were not able to regain access of the board, because the MCU was running into the fault condition pretty much right out of reset.
Luckily, after a lot of trial-and-error, I have found a way to recover them.
One great thing with the Eclipse Gnu Make Builder (aka ‘auto make’ or ‘auto build’) feature: just add source files (*.c, *.cpp, …), and with kind of magic, they all get compiled and linked properly.
But for something easy and convenient: is it hard to use custom file extensions? So what if I want to use a different file extension for my source files, different from the standard ones? Actually Eclipse CDT can do this too, it just takes two settings to recognize, compile and link source files with custom extension.
I’m not a big fan of using printf() in embedded applications, but I have to admit that in some cases it is very useful. One problem in debugging embedded systems debugging is getting values or information off the target: because of the limited resources this can be very challenging.
So why not doing this with the debugger in an automated way? And here dynamic printf breakpoints can help: it adds printf()-style output on-the-fly to your program without the need to recompile or restart your program, without the need to run printf() on the target:
One of the great things in Eclipse is that it can be customized down to the bits. The downside (pun intended) is that it might not be obvious how to do this. So here is how you can create your own custom file header when creating a new C/C++ file in Eclipse:
It is interesting to see that some aspects (mostly unintended) can stimulate lots of good and fruitful discussions. So this happened with “Spilling the Beans: Endless Loops” (recommended to read 🙂 where using (or not using) volatile for inline assembly created thoughts which warrant an article on that subject.
The volatile qualifier in C/C++ is misunderstood by many programmers, or wrongly used.
Still, ‘volatile’ is very useful if you know what it means for the compiler and what is good use of it.
G-Code (or RS-274) is a widely used protocol for CNC machines. I have added vinyl cutting capabilities to the Shapeoko desktop CNC recently (see DIY Vinyl Cutting Drag Knife for Desktop CNC), however cutting vinyl with a drag knife is whole different story compared cutting materials like wood or aluminum. As with many other things, it is about handling all corner cases properly.
Welcome to ‘Alice in Wonderland‘! For a university research project using an ARM Cortex-M33 we are evaluating position-independent code as way to load applications or part of it with a bootloader. It sounds simple: just add -fPIC to the compiler settings and you are done.
Unfortunately, it is not that simple. That option opened up a ‘rabbit hole’ with lots of wonderful, powerful and strange things. Something you might not have been aware of what could be possible with the tools you have at hand today. Leading to the central question: how is position-independent code going to work with an embedded application on an ARM Cortex-M?
Let’s find out! Let’s start a journey through the wonderland…
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.