Decreasing Cost Time to Market Professional Embedded Development Tools
While microcontrollers have gone through many evolutions, from simple 8-bit controllers with a few kilobytes of memory to the advanced 32-bit controllers available today, many developers still use archaic tools that hinder the development cycle.
For designers to keep up in today’s fast paced and complex development environments, they need to make sure that they have the right tools for the job. They need embedded tools that allow them to monitor the silicon and see that their software is operating the way they expect it to, as well as tools that point out errors or optimize code size, allowing them to decrease their BOM costs.
There are many tools available today that can help them decrease overall development costs and speed up the debugging process, resulting in a quicker time to market. This article will introduce some of these tools before touching on how to use them for maximum benefit.
Saving time and money with a professional debugger
It is very rare for a developer to write a software routine that works on the first try. Software development requires debugging, making the most critical tool in the software developers’ arsenal the debugger. The debugger allows a developer to load an application onto a target microcontroller, step through the code, view memory and other registers, and manipulate the hardware.
The problem that many professional developers encounter is that they often use the debuggers that come with their low-cost development boards. These debuggers are convenient, inexpensive and perfect for demonstration. However, when it comes to developing professional software, they might have limitations such as:
- Limited breakpoints
- Decreased clock rates
- Lacking trace capabilities
- Minimal functionality
In other words, sometimes developers get what they pay for: a minimal toolset that may not be the best route to quickly and efficiently develop and debug their software.
Professional grade debuggers come with many features that enhance the productivity of the engineer, such as unlimited breakpoints. Many debuggers can only use the microcontroller’s internal comparators to set breakpoints, and in most cases there are only two available. In a complex program with tens of thousands of lines of code, having only two breakpoints available can cause a developer to waste time switching between breakpoints, or cause the developer to miss critical points in the software where the bug may be lurking. This can result in longer coding time, which in turn can drive up development costs and jeopardize time to market.
A professional debugger comes with the algorithms to use not just hardware breakpoints but also software and flash breakpoints, giving developers more flexibility and a nearly limitless number of breakpoints to evaluate their code.
Professional debuggers are not inexpensive. They can easily carry a price tag anywhere from a few hundred to several thousand dollars. However, they provide an untold return on investment to developers and may be used for years without upgrade or replacement. When selecting a debugger, there are several questions that developers should ask themselves:
- Does the debugger include unlimited breakpoints?
- Is this a 3rd party debugger that can be used with nearly any toolchain and microcontroller?
- Can I still use this debugger five years from now?
- Is there a good ecosystem around this debugger?
- Can the debugger’s capabilities be expanded?
One particular 3rd party debugger that has become extremely popular because it meets the above criteria is the Segger J-Link. The Segger J-Link comes in a few different flavors depending upon the developer’s needs. These include J-Link Base Unit, J-Link Plus, J-Link Ultra Plus and J-Link Trace (Figure 1).
Figure 1: Segger J-Link debugger model comparison. (Source: Segger)
Routing out elusive bugs using debugger trace and branch detection
The advanced and often most expensive debuggers have an ETM trace connector that allows them to get large amounts of trace data that otherwise would not be possible using standard trace with JTAG or SWD.
Using the advanced trace capabilities, developers can use the debugger in conjunction with a commercial toolchain, such as Keil MDK-PRO for ARM to monitor whether every line of code in the system has been executed during testing. An example shows where Keil MDK-PRO for ARM was running with the trace debugger and detected which lines of code were executed during the test (Figure 2). This type of tracing can be extremely helpful for safety critical systems where 100% test coverage is necessary. Where code has not been tested, bugs may be lurking and waiting to cause problems.
Figure 2: Keil MDK-PRO for ARM running in debug mode and performing a branch analysis on the software. On the left hand side, the green blocks represent lines of code that have been executed during the test. (Image source: Keil)
For developers that don’t want to invest in the full-blown trace tools, there is an alternative for tracing using the SWD. In this case, developers can select to use a software tool such as Segger’s SystemView or Percepio’s Tracelyzer to stream trace information to an application executing on a PC. These trace systems typically work within an RTOS and require a few lines of code to setup a trace task that captures and sends the data to the debugger and then on to the PC.
Example output from the software trace is shown (Figure 3). Developers can use these tools to detect issues such as priority inversion, deadlock, thread starvation, and many other issues that can be encountered in a complex system. Each task has a lifeline that shows when it is ready to execute, when it executes, completes, and any events that may happen along the way, such as giving and taking semaphores.
This level of detail is required by professional developers, and in turn requires that the debugging tools they are using be capable of retrieving this kind of information.
Figure 3: Use a tool such as Percepio’s Tracealyzer to peer into the software’s operation and see what is executing when and for how long. (Image source: Digi-Key)
Tips and tricks for getting the most from a debugger
Debugging tools come with a lot of capability but they can sometimes be limited by the microcontroller that was selected for the application. Developers need to know the capabilities of their debugger and properly match them with their microcontroller. Many debuggers today are designed to work with the ARM® Cortex®-M microcontroller parts and there are several factors developers should consider when debugging these systems:
- Avoid printf through a UART. Instead, use an ITM port for better performance
- Don’t step through code, use advanced breakpoints to improve debugging efficiency
- Select a debugger that is server controlled so that multiple applications can be fed the debugging data i.e.: custom analyzer, trace, debug environment, among others.
- Adjust the default clock rate used by the debugger since it is usually much slower than the maximum
- Setup tracing early in the development cycle to create a baseline for comparison
- Enable the SWO to get more information from the system
- Selectively choose between hardware, software and flash breakpoints to minimize real-time performance impacts
Using these tips can help developers get more from their debugger and their debugging sessions.
Decreasing costs with a commercial compiler
GCC is an incredibly popular and successful compiler. One advantage that it has compared with commercial tools is that it is free! Free doesn’t always mean that the quality and output from the compiler will produce executable code that is on par with a commercial tool. In fact, in many cases, comparing GCC with a commercial compiler such as Keil MDK-PRO for ARM or IAR Embedded Workbench will result in GCC using a larger code size and a greater RAM footprint. Renesas has even shown this in their datasheet for their Synergy Platform (Figure 4).
In the figure, Renesas benchmarked their compilers using the EEMBC CoreMark® which shows that the code compiled by IAR is faster than the code compiled by GCC.
Figure 4: Renesas Synergy Platform CoreMark® Results. The larger the Coremark value the better the performance. (Source: Renesas SSP 1.0.0 Datasheet)
Benchmarks also show that code size can be dramatically reduced using a commercial grade compiler. At first glance, a developer may suggest that purchasing a tool such as Keil MDK-PRO for ARM is not worth the investment and instead, GCC should be used. But what happens when a developer is using a microcontroller, such as the NXP MK20DX128, which contains 128 Kbytes of code space, and discovers that using GCC their application requires 132 Kbytes?
When this happens, the team is forced to find a more expensive pin-compatible part with enough memory such as the NXP MKD20DX256. If the company will only be producing moderate volumes, the additional annual cost for the MCU may well exceed having initially invested in a commercial compiler.
There are certainly other advantages as well to using the commercial compiler that will help decrease costs such as:
- Code analysis capabilities such as branch detection
- Software complexity measurements
- Efficient code generation
- Superior debugging tools and capabilities
- Technical support
- Integration to driver libraries and frameworks
Developers can certainly get by using free or inexpensive development tools. The problem, however, is that these low-cost tools in most cases are not the best tools for the job. Lacking the advanced capabilities that every developer needs in their toolbox, rather than saving time and money they can often lead to project delays and increased costs.
Having a good professional debugger and toolchain are an investment that will save time and money for years to come, and dramatically improve the efficiency and performance of the development team.
免責条項：このウェブサイト上で、さまざまな著者および/またはフォーラム参加者によって表明された意見、信念や視点は、Digi-Key Electronicsの意見、信念および視点またはDigi-Key Electronicsの公式な方針を必ずしも反映するものではありません。