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.
