Run-mode Diagnostic and Debug: Why You Need It
In a traditional embedded application DevOp, the host debugger interfaces with the target system by way of hardware debugger (ICE/JTAG). The benefits with this approach are
- Complete visibility into all aspects of the running system, and
- Instruction-level granularity run-control
This model / mindset sits well when the central processing unit is a single thread of execution, fed with pipeline of instructions executing sequentially. With multi-core and hyper-threading, it’s semantically fuzzy as to what it means for the debugger to single-step one instruction executing in one of many hardware threads. This semantic mismatch can be (and have been) sold as “good enough”.
A more practical concern is when the target runs a multi-tasking OS, usually Linux. These targets are usually subservient edge devices that will be expelled from their connection if not heard from by their cloud overlords within an allowable time threshold. Stopping edge devices, albeit momentarily, to debug with hardware debugger is usually advised should the devices expect to response to external network stimuli. Set-top boxes, gateway routers and the like fall in this category.
To be sure, stop-mode debug offers many advantages, and are still the dominant mode of board bring-up debugging. It lets you examine registers and memory without the concern that their values are being changed by another thread of execution within the system. With a few exceptions however, this mode of debugging is increasingly less practical in multi-tasking target:
- Stopping the debugged system completely prevents servicing of incoming interrupts, thus increasing the likelihood of severing channel of communication to the overlord, and
- In a multi-core environment/processor, it may not possible to simultaneously halt all processors
Run mode debug is an alternative well aligned in solving this challenge. Run mode debug uniquely allows maximum concurrency with minimal overhead, enabling the multi-tasking system to run at full speed even while under debug, both in user and kernel mode. Furthermore, run mode debug can occur over the existing IP channel to the target system; no hardware debugger is needed (unless stop-mode debug is desired in tandem). Consequently, run mode debug is highly suitable for certain class of problems that are not reproducible under normal controlled debug environment.
Whether to use stop mode or run mode debug depends on the needs of the application and placement of the target system within the global network. Let us know how run-mode debug can solve your development challenges, and how we can help.