To me, one of the most frustrating things working with ARM Cortex-M cores are the hard fault exceptions. I have lost several hours this week debugging and tracking an instance of a hard fault on an ARM Cortex-M0+ device.
The ARM Cortex-M microcontroller are very popular. And it has a very flexible and powerful nested vectored interrupt controller (NVIC) on it. But for many, including myself, the Cortex-M interrupt system can be leading to many bugs and lots of frustration :-(.
ARM Cortex-M7: NXP KV58
Understanding the NVIC and the ARM Cortex-M interrupt system is essential for every embedded application, but even for if using an realtime operating system: if you mess up with interrupts, very bad things will happen….
My embedded applications are implemented mostly in C, a few in C/C++. But all of them have one or few assembly files included too: Assembly programming is the needed to do low-level things so it is a natural part of a true embedded application. For example I use often an assembly file for the application startup code.
I have run into a nasty Eclipse CDT issue which deals with assembly files projects. Here is a quizz for you: can you spot the problem in my project below?
Startup Assembly Code
Readers of my blog know: I’m not a fan of printf(), and I think for many good reasons. Still printf() is widely used, and the GNU gcc tries to optimize things. This is observed with a simple example: If I’m writing
printf("a");
Then the code produced (ARM Cortex-M0+ with GNU ARM Embedded 4.9 2015q2 gives:
movs r0, #97 ; 0x61 bl 0xa98
Instead of calling printf(), it is calling putchar()! Why is that?
PutChar instead of Printf
Mastering interrupts is critical to make an embedded application reentrant. The challenge with reentrancy is that things might be implemented in a wrong way and the issue might just show up sporadically (see “EnterCritical() and ExitCritical(): Why Things are Failing Badly“). The ARM Cortex interrupt controller is named NVIC (Nested Vectored Interrupt Controller).
ARM Cortex NVIC Registers
In “A Processor Expert Component to Help with Hard Faults” I’m using a C handler with some assembly code, created with Processor Expert, to help me with debugging hard faults on ARM Cortex-M. Inspired by a GNU gdb script here, I have now an alternative way. As this approach is using the GDB command line approach, it works both with an Eclipse GUI and with using GDB in command line mode only :-).
I have several applications where I store application specific information in the microcontroller FLASH memory (see “Configuration Data: Using the Internal FLASH instead of an external EEPROM“). I have run into issues recently with the Segger J-Link GDB server as by default it does *not* erase all the FLASH memory. So the question is: How can I erase all (or part) of the FLASH memory with GDB (e.g. in Kinetis Design Studio or in Eclipse)?
Memory Monitor with Erased Flash
With my DIY tool chain (see “Constructing a Classroom IDE with Eclipse for ARM“) I get a complete tool chain. I do not need to build that tool chain from the sources for Windows, as all the binaries are nicely pre-compiled and made available. But there is one issue I face from time to time: as the libraries provided by ARM do not come with sources and debug information enabled, I end up with that “No source available for …” message in the debugger:
No Source Available
The solution is to grab the C/C++ library sources from the ARM launchpad site and get it built locally the way I need it.
I have carefully implemented my firmware. It works perfectly for hours, days, months, maybe for years. If there would not be this problem: the firmware crashes sporadically :-(. Yes, I’m using watchdogs to recover, but hey: it is a serious problem. And because it happens only under rare and special conditions, it is hard to track it down or to debug it.
Accessing shared data from the main application and from an interrupt
The thing is: these nightmares exist, and they are real and nasty. I’m pushing my students hard on this topic: It is about how to protect critical sections. And what could go wrong. And here is just yet another example: how it can go badly wrong if you are not careful. And it took me a while too to realize where the problem is. It was not a fun ride….
MCU on Eclipse 