Developing an embedded system, where software and hardware must play well together, has become exceedingly complex and challenging, even for what may seem like the simplest Internet of Things (IoT) devices. So much so that when something goes wrong -as it will inevitably happen- debugging times are not usually a few hours, but can take weeks or even months. These delays add development costs, prevent a product from getting to market on time, delay manufacturing schedules, and wreck supply chains and business plans.
The best way to reduce debugging time and keep a project running is to use a combination of free hardware and free software debugging tools to get insight into how a system is performing and where problems are occurring. . For this reason, both for professionals and for enthusiasts, having the right tools for the job helps a lot to do it quickly and properly.
This article examines development tools and software that can be used to debug and test the performance of an IoT device. You will use a development board from STMicroelectronics as an example IoT device, and use tools and software from SEGGER Microcontroller Systems to understand and debug the system. Multiple tips and tricks will also be discussed on how to minimize debugging time and deliver an IoT project on time.
The usual IoT device to debug
The IoT devices they have become commonplace in virtually every field, from the smart home to industrial monitoring control. Despite the variety of applications, there are multiple common components that an IoT device will have. These include:
a microprocessor
A radio for connectivity
Embedded
A developer will not want to spin their board to explore debugging techniques or to test pieces of their application code. It's too much time. At your site, it's wiser to work with a low-cost development board like the B-L4S5I-IOT01A Discovery Kit for IoT Node from STMicroelectronics. It has virtually everything found in a proper IoT device (Figure 1).
The board includes the STM32L4S5VIT6, an Arm® Cortex®-M4 microcontroller running at one hundred and twenty megahertz (MHz). For this, it has up to two megabytes (Mbytes) of flash and six hundred and forty kilobytes (Kbytes) of RAM. For the purposes of this exercise, it is essential that the board include Wi-Fi and a multitude of sensors that can be used to quickly build an IoT test device.
Professional debugging hardware tools
Virtually all development boards come with a built-in JTAG/SWD interface so developers don't have to go out looking for their programmer. Instead, they can work with the development board right out of the box. While this is great for marketing, it's not great for actual engineering: Embedded debuggers are usually very stripped-down versions that have restrictions, such as the number of free breakpoints and the baud rate of the interface. To the uninitiated, these restrictions may not seem like a huge inconvenience, but having unlimited breakpoints prevents having to continually turn breakpoints on and off, and fast baud rates are required for application tracing (more on tracing in software tools section).
There are multiple free tools that can manage a professional debugging experience, but the tools themselves are only half the solution. The tools must be supported by good software. One set of tools that stands out from both a hardware and software perspective is the J-Link series from SEGGER. This series features a debugger version for virtually any kind of developer, from students and enthusiasts to die-hard professionals.
There are 2 models that experience has proven to be the most useful for the general developer: the J-Link Base and the J-Link Ultra+ (Figure two). In terms of form factor, the 2 drives are identical, but the J-Link Ultra+ offers the developer a faster download speed to RAM (three Mbytes/s vs. zero Mbyte/s) and a higher speed of the SWD interface (one hundred MHz instead of thirty MHz). Faster speeds make all the difference when a developer wants to trace their application to get information about performance, RTOS behavior and debug their system.
The nice thing about the J-Link and the B-L4S5I-IOT01A development board is that the two can be connected using a TC2050-IC-NL Tag-Connect cable and the TC2050-CLIP-3PACK retaining clip. They allow a debugger to be connected to the development board via the "nail pad" (Figure XNUMX). It may be necessary to mate the twenty-pin connector on the J-Link to the ten-pin connector on the TC-XNUMX cable. An alternative that can be used for this is the J-Link XNUMX ten-pin needle adapter.
When the developer has closed this path on the hardware side, he can use the software tools to examine and debug his application.
Professional debugging software tools
There are quite a few software tools that work quite well with the SEGGER J-Link tools, which are surprisingly not provided by SEGGER. Now, we're going to take a look at several of these free tools and see how developers can use each of them to debug their software.
The first is J-Scope. J-Scope is an oscilloscope-like tool that displays time-varying values. Developers can monitor a single variable or multiple dozens of them. Keep in mind, however, that as more variables are controlled, fewer samples can be taken before the sample buffer overflows and data is lost.
The variables are chosen by giving J-Scope the elf file that is output from the compiler. This gives the memory locations to be read, and the developer can then set their sample rates and monitor how the variable(s) change(s) over time. In figure four you can see an easy case of a trace of 3 variables.
The next one is Ozone. Ozone is a debugging interface and performance analyzer. Developers can load their elf file into the tool and debug at the source level. They can set breakpoints and update their code. A particularly useful feature for developers is that they can also keep track of instructions (if supported by their hardware) and also identify which C and assembly code statements have been executed. This is especially useful for checking the code coverage of hardware loop tests (HiL).
Ozone can also help developers examine their system's performance (Figure XNUMX) and view variables over time. This gives capabilities like J-Scope more in a more integrated way. It can even be used to monitor energy consumption and time all these events at a site.
A third tool is SystemView. SystemView lets developers examine the runtime behavior of their RTOS system. Job switching is recorded in a trace buffer and then notified to SystemView via the debugger (Figure XNUMX). SystemView now displays this information so that the developer can view their context switches and measure the performance of their system. It's also a great way to visualize a system and find bugs and other issues.
Tips and tricks for debugging an embedded system
Debugging an IoT device requires developers to have the right tools from both a hardware and software perspective. Both pieces need to be in place if developers are to minimize the time they spend debugging. In order to debug successfully, there are multiple "tips and tricks" developers should consider, such as
Use a professional debugger that maximizes the transmission speed of the interface. The amount of useful data that can be obtained from a system will depend on the speed with which that data can be perceived. Slower speeds result in a longer debugging session.
Set up debugging software early in the development cycle. Developers shouldn't wait for a problem to configure their debugging tools.
Employ tracking tools from the beginning of development. This will allow developers to inspect the performance of their system and immediately understand how software changes affect it.
Take advantage of instruction tracing or program counter sampling to understand system code coverage throughout testing. Bugs will exist in conditional branches and in untested code.
Take advantage of fast transfer protocols to get data off-chip, such as real-time transfer (RTT) libraries.
Developers who follow these "tips and tricks" will find that they save themselves a lot of time and stress when looking to develop an IoT device.
Conclusion
IoT device software has gotten complex, but that doesn't mean professional or hobbyist developers should be stuck continually debugging their systems. Using professional development software and tools can provide developers with the information they need to not only debug a system, but to test and improve its performance. By investing in these tools, users can dramatically reduce the time spent debugging and get their projects up and running and to market in a reasonable amount of time.
