English
Debugging of embedded Linux applications on ARM9/ARM11 processors
By Heiko Riessland & Frank Noack, pls Programmierbare Logik & Systeme GmbH
industrialcontroldesignline.com (June 24, 2009)
Embedded Linux as an operating system for modern ARM processors? Maybe not such a bad idea? Linux is a multitasking operating system and therefore, each process must be assigned its own process address space. However, this partitioning greatly complicates the debugging of processors and inter-process functionality. So what can be done to tackle this? The following article illustrates some possibilities how you can successfully achieve your goal.
Nowadays, two different debug approaches are normally still used with software development on embedded systems. On the one hand is mostly the classic debug tool, with which the behavior of the Linux kernel is examined. This tool helps the developer to detect problems during the boot phase of the operating system, detect faults in self-coded driver modules or display the back trace of kernel routines.
For debugging at application level, generally a special debug server is started on the target system. This server offers an interface to receive commands from the developer for debugging. It usually communicates with the host PC via the Ethernet interface. The operating system is not influenced by the debug session.
Both approaches have some very specific advantages. However, these are cancelled out by diverse disadvantages: The different tools and components, respectively, do not operate synchronously and, worst case can even obstruct each other! It can even happen that the connection of the application debugger to the target system is interrupted, because the operating system was halted by the kernel debugger and the debug server also comes to a halt. Additionally, a change between both debug tools must always be made thus making the debugging awkward and confusing the developer.
In the following text, the technical principles will be made clear in detail and, with the freeze-mode debugging, a method presented, which helps to avoid most of the disadvantages.
industrialcontroldesignline.com (June 24, 2009)
Embedded Linux as an operating system for modern ARM processors? Maybe not such a bad idea? Linux is a multitasking operating system and therefore, each process must be assigned its own process address space. However, this partitioning greatly complicates the debugging of processors and inter-process functionality. So what can be done to tackle this? The following article illustrates some possibilities how you can successfully achieve your goal.
Nowadays, two different debug approaches are normally still used with software development on embedded systems. On the one hand is mostly the classic debug tool, with which the behavior of the Linux kernel is examined. This tool helps the developer to detect problems during the boot phase of the operating system, detect faults in self-coded driver modules or display the back trace of kernel routines.
For debugging at application level, generally a special debug server is started on the target system. This server offers an interface to receive commands from the developer for debugging. It usually communicates with the host PC via the Ethernet interface. The operating system is not influenced by the debug session.
Both approaches have some very specific advantages. However, these are cancelled out by diverse disadvantages: The different tools and components, respectively, do not operate synchronously and, worst case can even obstruct each other! It can even happen that the connection of the application debugger to the target system is interrupted, because the operating system was halted by the kernel debugger and the debug server also comes to a halt. Additionally, a change between both debug tools must always be made thus making the debugging awkward and confusing the developer.
In the following text, the technical principles will be made clear in detail and, with the freeze-mode debugging, a method presented, which helps to avoid most of the disadvantages.
|
E-mail This Article | 
|
|
Printer-Friendly Page |
Related Articles
- Debugging complex RISC-V processors
- Fundamentals of Booting for Embedded Processors
- Using edge AI processors to boost embedded AI performance
- Software Infrastructure of an embedded Video Processor Core for Multimedia Solutions
- Meeting Increasing Performance Requirements in Embedded Applications with Scalable Multicore Processors
New Articles
- Why RISC-V is a viable option for safety-critical applications
- Dimensioning in 3D space: Object Volumetric Measurement by Leveraging Depth Camera-based Reconstruction on NVIDIA Edge devices
- What is JESD204B? Quick summary of the standard
- Post-Quantum Cryptography - Securing Semiconductors in a Post-Quantum World
- Analysis and Summary on Clock Generator Circuits and PLL Design
Most Popular
- System Verilog Assertions Simplified
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- Method for Booting ARM Based Multi-Core SoCs
- An Outline of the Semiconductor Chip Design Flow