According to conventional wisdom, it is often said that even after a long time, you only use the features of a software product you tried when you first installed the product. In short, old habits can prevent you from making progress. And so, many STM32 developers still use only basic methodologies like single-stepping, running to breakpoints, and printf() debugging - despite having much more powerful capabilities already installed in their tools.

Make sure you don't fall behind other STM32 developers - read this whitepaper to find out what great time-saving and quality-improving capabilities smart developers enjoy!

Embedded development is difficult, and embedded debugging may be even more so. Thus it is important to use the best tools in your toolbox. It appears to me that many Cortex-M developers are not fully aware of the powerful debug capabilities included in their Cortex-M based microcontrollers, like STM32, Kinetis, LPC or EFM32. This is valid for the super-useful Serial Wire Viewer (SWV) real-time event and data tracing capabilities, but perhaps even more so, the hard fault crash analyzis capabilities integrated in the Cortex-M core.

For example, our Atollic TrueSTUDIO debugger includes a hard fault crash analyzer, which detects hard-to-find runtime errors during full-speed target execution. Perhaps your system crashes a couple of times every week due to a sensor reading out-of-range values, causing a pointer error to bring the CPU to a hard fault due to accessing illegal memory or on misaligned address  boundaries.  Or your code performs a division by zero, once a week. These types of problems can be really hard to find and solve.

ARM Cortex-M processors like STM32, Kinetis or EFM32 support live variable watch, a debugger feature that update the variables in a watch view in (almost) real-time as the target system executes at full speed. This feature is incredibly useful and can quickly help identify many bugs. Still, it appears many Cortex-M developers are not aware of this important debug capability.

I wrote another blog post on this topic some months ago, but I keep getting questions on the subject so I will cover live "real-time" variable watch once more. I would argue this capability is so useful and important, that professional embedded developers should not use an IDE without this ability. Let’s see how live variable watch debugger windows can be useful.

Any Cortex-M developer have likely struggled with getting interrupts to work, or tried to debug them. Getting it all hooked up can be rather tricky, from getting a correctly defined interrupt vector table linked on the right memory addresses, to enabling interrupts properly, and then processing them in an interrupt handler. It all involves advanced topics like linker configuration files, SFR register bit field configuration and manipulation, interrupt #pragmas, possibly inline assembly and more.

So how do you go about analyzing and debugging the behavior of your interrupts and exceptions on a Cortex-M device like STM32, Kinetis, LPC or EFM32? Interrupts and exceptions are by definition asynchronous to the execution flow of your application software and it can be very difficult to visualize interrupt behavior, and debug the same. So what is a Cortex-M developer to do? As it so happens, the Cortex-M core has brilliant hardware support for visualizing and debugging interrupt behavior. This is how to use it.

As we all painfully have come to learn - firmware is rarely bug-free and new requirements are usually added over time. And so there is a need for a method to upgrade the firmware of a shipped product when defects are found or new functionality is needed. From a logistics point of view, a product recall with a factory upgrade might not be a feasible option.

By separating the application logic from the booting process, developers can design a system that allows end-users or service technicians to upgrade the application software with a newer and presumably better version later on, without the need for recalls or factory upgrades. This can be done using a bootloader. But what is a bootloader and how is it implemented and debugged on an ARM Cortex-M device like STM32 or Kinetis? The post also links to a bootloader code example for STM32F4-Discovery.

Writing device-drivers for microcontrollers like STM32 is very complicated if you haven’t written a few of them before; not only do you need to understand the peripheral module hardware and their special function registers (SFR’s), you also have to be an ace on the meaning of SFR bit-fields and bits, understand interrupt vector tables, #pragmas, inline assembly and other intricate things.

Not too many years ago, semiconductor vendors didn’t provide device-driver libraries with their microcontrollers, and so each customer had to write them from scratch. What a waste of engineering time and duplication of resources! Way too many years later, they started to ship static device driver libraries or device-driver generations tools to help struggling developers. STMicroelectronics for example provide both static STM32 device-driver libraries, as well as the STM32CubeMX device initialization tool. And so, with readymade device driver libraries available, do STM32 developers need to worry about SFR’s anymore? I’d say yes, for reasons outlined in this blog article.

The new ARM Cortex-M7 processor core is the most recent and highest performance of the different microcontroller cores in the ARM Cortex-M family. And as such, it outperforms for example the Cortex-M3 and Cortex-M4 on performance, while maintaining backwards compatibility.

Many semiconductor manufacturers have announced new Cortex-M7 devices, and one of the first out is STMicroelectronics, adding new Cortex-M7 devices to their STM32 family. The Cortex-M7 version of STM32 is called STM32F7, runs at 200MHz and initially coming with 512KB or 1MB of Flash memory and 320KB of RAM. And so, what can STM32 developers expect, when equipping their coming designs with the more powerful STM32F7?

By now, I have written a large number of blog articles highlighting the advanced debugger capabilities offered by the Serial Wire Viewer (SWV) real-time event- and data tracing, available in Cortex-M devices, such as STM32 from STMicroelectronics, Kinetis from Freescale, LPC from NXP, etc. In this blog article, I will mention how the Instrumentation Trace Macrocell (ITM), which is part of SWV, can be used to measure the execution time of any-sized and any-partitioned blocks of code.

For example, you may want to know what the execution time is of a while{} loop. Or how long it takes from the user press the “Heat” button until the oven reaches a certain temperature in the code (perhaps detected by an if{} statement code line), or how long time it takes to execute 15 sequential lines  of code in a function. All these time measurement use cases, and more, can easily be accommodated using SWV/ITM in Cortex-M based devices, such as the widely popular STM32 or Kinetis microcontroller families.

Many STM32 developers use ST-LINK as their JTAG/debug probe. In particular, it is soldered onto many STM32 starter kits and evaluation boards, including the STM32 Discovery Kits and Nucleo boards. But it is also offered as a low-cost stand-alone JTAG/debugger probe as well.

So what debugging capabilities can you expect when hooking up the C/C++ debugger in your IDE to your STM32 board using the ST-LINK JTAG/debug probe? Considering its price, it is a very useful and convenient debug solution, but it also doesn’t offer the performance or all of the more advanced capabilities of for example the SEGGER J-Link or J-Trace debug probes.

As the embedded industry now standardize on the GNU C/C++ tools (gcc compiler and gdb debugger) and the ECLIPSE IDE, more tool options have become available in the last year or two. In particular, free or low-cost Eclipse/GNU tools are widely available on the market for Cortex-M devices like STM32, Kinetis and LPC. Also available are high-end Eclipse/GNU tools like Atollic TrueSTUDIO, supporting the same devices with many commercial add-ons. And so, which one to choose?

A question is if the free tools really are free, and if they offer what you need? Factors to consider are out-of-the-box experience, quality and support options, as well as productivity and functionality, and managing project risks. Different development teams may well have different priorities and answer to these questions. Let’s see what factors there are to consider.

So, where do you hang out? Or rather, where do you spend your time? While this question may appear a bit personal, it is a valid question in terms of embedded software. Knowing where your application spends most time executing is the first step in efficient speed optimizations. Profiling your application to understand where it spends most of the time, is the best way to optimize performance the most, with the least efforts.

Say for example that your application spends 95% of the time in 3 C-functions, and the remaining 5% in another 125 C-functions. Then it is quite obvious you should spend your optimization efforts in the 3 functions that use most of the CPU time. While this 95% in 3 functions/5% in 125 functions ratio may appear to be a rigged and fairly extreme example, it really isn’t that uncommon. Usually, only a few C-functions use most of the CPU cycles. By analyzing what C-functions steal most of the CPU cycles, you know where to optimize for best results.

In my previous blog articles on Cortex-M Serial Wire Viewer data tracing, I have outlined how you can exploit real-time variable watch and Memory access history trace log capabilities in popular Cortex-M devices like STM32, Kinetis or LPC.

This blog article will extend upon this and show how you can visualize variable values graphically in real-time, using an “oscilloscope style” data plot graph as the Cortex-M target system executes at full speed.This gives developers instant and highly visual feedback, non-intrusively, from running target systems.