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
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)