Ten tips for debugging
Tip No. 1: Do not skimp on the debug interface
The debug interface allows monitoring of hardware and software as well as their interaction, and is one of the most important possibilities to test a microcontroller system not only as a black box. Therefore, whenever possible a system-on-chip (SoC) with a high-performance diagnosis interface should always be selected and this then implemented on the hardware in the most powerful stage. Also remember that modern debug interfaces, the same as the functional peripherals, are complex assemblies and they therefore require the same level of attention in PCB layout with respect to power supply, clock frequency, etc.
Tip No. 2: Advantages of a trace interface
A trace is always essential whenever the program flow or the change of program data must be completely reconstructed to find the cause of a problem. However, besides that, an additional high-performance interface for code trace and/or data trace is highly recommended. The reason for this is because the results of a trace not only – as is often falsely assumed – serve the sole purpose of troubleshooting, but also provide a solid basis for debugging at system level with functions such as profiling, code coverage and execution sequence diagram. For example, performance bottlenecks in the application can be detected or the software certified according to specific standards. Nowadays, based on a code trace, an appropriate high-performance debug tool can, for example, also generate reliable statistics about C0 and C1 code coverage. C0 evaluates the coverage of each machine instruction and C1 evaluates the coverage of each decision branch in the program flow.
Figure 1: Code Coverage at function level
Figure 2: Universal Access Device 3+ with debug and trace pod at Cortex A8 target
Tip No. 3: Use special emulation devices
For some of the very high-performance 16-bit and 32-bit microcontrollers such as, for example, Infineon’s automotive SoCs in the XC2000 and TriCore families, there are special emulation devices, which have been available for a long time, that are 100 percent footprint compatible with the production chip. In addition to the production chip, these emulation devices have also implemented an additional debug logic and trace logic. According to the current state of technology and from personal experience, this is the most efficient diagnosis and debug approach, because it is de facto technically much more difficult and complicated to transport the internal large amount of data gathered in a complex SoC to the outside for diagnostic purposes. In the meantime, there are signs that other manufacturers will probably also take the same approach. If an appropriate emulation device is available then some prototypes of a new hardware should be equipped with it. The manageable additional effort in hardware and supporting tools mostly makes it already worthwhile in the first search for the cause of a more complex error.
Figure 3: Configuration of a trace task with Universal Emulation Configurator
Tip No. 4: A picture tells more than a thousand words
To maintain an overview of a modern SoC application, the debug tool should contain a view of the system in various levels of abstraction. Typical examples of this are the graphical representation of data and process variables over time and in relation to each other, function runtimes and program flow. The possibility of a fast tendentious process evaluation is important. This is sufficient for an initial quick assessment of the situation. For a detailed analysis, the measurements in parallel with the graphic are then still always available.
Figure 4: Graphical display of variable expressions
Tip No. 5: A debugger is far too good to be used only for troubleshooting
Nowadays, modern debuggers are often far more than just an interactive tool for troubleshooting. For example, for smaller projects, with a scriptable debugger even tests can be created and automatically executed. For larger projects, the debugger can provide access to the target and control the run state. It is important, however, that suitable high-performance – ideally, standardized non-proprietary interfaces – are available, which allow developers to put together own optimized workflows with their tools or to seamlessly integrate the tools in frameworks such as Eclipse.
Tip No. 6: Software and hardware know-how are equally important
When developing a complex embedded application not only pure hardware or software specialists are required. At least one developer on the team should additionally also be very familiar with hardware-related software and possess appropriate knowledge of on-chip diagnosis capabilities. With this knowledge, this developer can support the entire team with the efficient use of the debugger. Furthermore, it is also advisable to procure at least one evaluation board, if available, to learn the architecture.
Tip No. 7: Consider the complete runtime of the application
The debug interface not only plays an important role during development, but also in the production and diagnosis in the field. Unfortunately, this is still far too seldom taken into account during the application development. Typical consequences of this forgetfulness are that the production of the assembly is possible only with a a needle adapter and software updates can only be carried out directly by the manufacturer. Tools that cover the entire life cycle from debugger for the development, production flasher and service flasher to the diagnosis tool in the field can ultimately help save a lot of trouble and costs.
Tip No. 8: Is monitor-based debugging out of date?
Even in the age of standardized debug and trace interfaces, monitor-based debugging still continues to have its justification. The most popular is certainly the gdb server for Linux application debugging. But also in the hardware-related area, there are applications where a dedicated interface on a finished device can not be made available to the outside and debugging must be realized, for example, via the CAN bus. This is the case, for example, when assemblies are encapsulated for protection against environmental influences and only the connections necessary for operation are realized with special connectors. Therefore, with new acquisitions you should make sure that the tool also supports these types of debugging accordingly.
Tip No. 9: Synchronization of multi-core SoCs
An increasing number of modern SoCs contain two or more microcontroller cores. In this regard, particular attention should be given to on-chip synchronization capabilities. Almost every external synchronization leads to a time gap, for example, during starting and stopping of the cores. The debugger used should also, in terms of structure and operational concept, support the debugging of multiple cores without having to execute multiple instances.
Tip No. 10: Pay attention to the architecture support
And last but not least, in addition to pure performance parameters, the entire environment of the microcontroller architecture – such as programming examples for complex peripherals, application notes, code generation tools, user forums, good knowledge of the architecture at the tool vendors, etc. – also plays an important role. Admittedly, the latter is difficult to measure. However, if the tools offer support for architecture-specific features, this is usually a reliable indication that the respective tool vendor has in-depth system know-how and that there is a intensive cooperation with the respective MCU manufacturer.
About the author: Dipl.Inf. Heiko Riessland studied computer sciences at the Dresden Technical University. After gathering ten years of experience in designing and selling of software development tools and emulators for 16bit and 32bit microcontrollers, Riesland oversees the product marketing at software tool vendor PLS Programmierbare Logik & Systeme GmbH.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
