Are you a skilled embedded developer, creating great software for STM32? You are in good company. If so, this blog article is for you. I have collected a number of tools and techniques that can be used to help you write STM32 software in an even better way, launching your embedded product more timely and of higher quality.
What does it take to write great STM32 software? Naturally, you need to know C or C++ and possibly a tad bit of assembler as well. You also need to know your target device and its device driver libraries as well. STMicroelectronics will provide information on this. But when what? What are the “secret” techniques used by really skilled STM32 developers? What tips and tricks do they want to keep to themselves?
In my opinion, it appears many of the advanced debugger capabilities built-in into the Cortex-M processor core are not used by many embedded developers, and STM32 developers are likely no different. This is unfortunate as these powerful debugger capabilities are available right there, but not helping to solve your urgent problem, when it could have.#1 Live real-time variable watch.
The Cortex-M core enables debuggers to query the processor memory when the target system runs at full speed, enabling debuggers to provide live variable watch views with real-time update. These can also support complex data structures such as structures and arrays. Being able to see variable values changing as your target application executes at full speed is very useful!
The CPU may crash due to a hard fault exception caused by a software error, such as division by zero, a pointer error or a stack overrun. Use the built-in Cortex-M hard fault crash analysis capabilities that will tell you what happened, where in the code it was, and why. It can save you so much time!
The MAP file can help you get a clear understanding of your system and check some error-prone design issues. Linker related bugs can be very hard to find, as studying the source code will not help identifying the problem. The problem is that map files can be extremly hard to understand. The Build Analyzer in Atollic TrueSTUDIO Pro provides an unprecedented view into the generated build image file, and the memory layout of different code and data sections. This novel feature presents information on memory regions and memory details in a highly visual fashion - thus providing a completely new view of your system.
Embedded systems often include bugs developers have a hard time to find. One common cause of tricky bugs are stacks that grow beyond their dedicated memory area, thus causing unpredictable behavior and a malfunctioning system. This is because the stack can overwrite important variable values, that thus inadvertently get the wrong value. Alternatively, a variable overwrites the stack, as the stack has expanded into the memory area dedicated to that variable. Upon the next function call return, the software crashes as it returns to the wrong location (the return address is stored on the overwritten stack and execution continues on a random location). Due to these reasons, stack related bugs often appear to be completely random, in most cases making them incredibly difficult to find. If you use an RTOS running parallel tasks, these problems can multiply. Each task has its own stack, and with more tasks, you get more stacks that can cause stack related bugs.
The stack depth analyzer in Atollic TrueSTUDIO Pro can help resolve such problems and help develop more robust systems.
Cortex-M processors have hardware support for real-time event and data tracing, offering capabilities like:
- Graphical oscilloscope-styled variable value chart plots
- Memory and variable access history log
- Performance analysis using statistical profiling
- Interrupt and exception event logging
- Interrupt and exception statistics
- Interrupt and exception nesting analysis
- Real-time variable watch
- Single-channel and multi-channel printf() redirection to a debugger console
- Software instrumented tracing
- Execution time measurement
- General event logging
Every STM32 developer should be aware of, and use, the powerful debug capabilities offered by SWV event and data tracing!
For really advanced debugging tasks, you may have to buy an ETM trace enabled JTAG probe, such as SEGGER J-Trace. It will record the execution history for you, enabling the possibility to analyze what happened prior to a tricky bug. ETM instruction tracing may be your only option if stopping on a breakpoint will damage physical equipment, for example in motor control applications.
The are many reasons to use a Real Time Operating System (RTOS). And there are many good choices, including FreeRTOS, Micrium uC/OS, Segger embOS and ThreadX from ExpressLogic. But make sure you can see what is going on! If you are using an RTOS, you will want to use an RTOS-aware debugger that shows you the internal state of the RTOS when you stop on a breakpoint; for example by visualizing the state of tasks, semaphores, message queues, timers, etc.
Why invent the wheel or doing things opposite to what hard-learned industry best-practice tells you? Make sure your source code conforms to the MISRA-C coding standard, or some other formal coding standard. That helps you write code that is less error prone, more portable, and more maintainable.
Use a consistent coding style, and standardize your blank lines, indentations, location of curly brackets etc. A modern editor should allow you to configure the coding style, and helps you enforce that automatically. This helps code reading and code understanding.=#9 Utilize peer-based source code reviews to improve code quality.
Performing peer reviews or source code reviews is arguable the cheapest way to improve software quality the most, fastest. It is often not done as it is considered a bit boring, and integrated tool support have previously been lacking. But if you are serious about improving your software quality, you ought to perform source code reviews regularly. At least for the critical parts of your software product. It is a really cost-effective way of improving your software quality, and for sharing of knowledge and expertise too.
Really. Do this. There is no exception to this rule. None. It surprises me to hear there are still professional developers working on commercial projects, without proper code management using version control systems. In my mind, this is a serious neglect even if you are a single developer working alone on your own. For a multi-developer team, this is just a must. In particular since the tools needed for this are free, and provides so much benefits in terms of traceability, change tracking, revertability, as well as possibilities for working in parallel using feature and release branches etc. If you don’t use version control systems already, stop reading this article right now and download the Subversion (SVN) or Git version control system immediately. Remember, these tools are free.
While not fully as important as using a version control system, it almost is. Download for example the free Bugzilla or Trac issue management database systems, and record all bugs, feature requests and work tasks in a well-organized database, allowing you to track work tasks like bug reports and feature requests, and tag them for different versions/releases, etc. Scanning through the open items in the issue management database in the weekly team meeting is an excellent way to organize the work-week and weekly team-meetings as well.
It will save you a lot of time and work with the more target specific parts of your STM32 development!
Most of the techniques listed above are either free or likely already supported in the tools you already use (as is the case with the Atollic TrueSTUDIO IDE for example); and so in many cases it is just to learn a new skill, or perhaps download some new free tools. Even if you do not start to use all of these techniques right now, using some of them will likely improve your development situation quite a bit.
Learn more about STM32 development and debugging in this whitepaper: