of 13
7/27/2019 Remote Debugging of Embedded Systems_Amit Joshi
1/13
1
Debugging of a Remote Embedded System
through cell phone
Abstract:
All embedded products are driven by time to market reduction, quality improvement. Itbecomes all the more reason for the developer to able to access the hardware setup
anytime, anywhere for debugging, development and testing.
The latest advancements in mobile technology have erased physical boundaries and couldenable engineers to communicate with the development hardware system across the
globe. The developer who is remotely located could use the cell phone to load programsinto the embedded system, run them, step through them, and view and change data used
by the system software. Physical user input could be simulated by real-time efficient andeffective instant messaging communication. The viewing of any graphical display output
is possible in the form of streaming video via mobile telecommunication network.
Author:H imanshu Shr inkhal
Ami t S Joshi
Sri ji ta Sengupta
7/27/2019 Remote Debugging of Embedded Systems_Amit Joshi
2/13
2
TABLE OF CONTENTS
1 Overview ................................................................................................................ 32 Need for remote debugging..................................................................................... 33 Remote Debugging of Embedded Systems Challenges ......................................... 3
4 Approach 1 Use mobile device to remotely login to host machine........................ 54.1 Requirements .................................................................................................. 5
4.2 Implementation Guideline ............................................................................... 64.3 Challenges....................................................................................................... 7
4.4 Advantages...................................................................................................... 74.5 Limitations...................................................................................................... 7
5 Approach 2 Use mobile device as a host machine................................................. 85.1 Requirement.................................................................................................... 9
5.1.1 Target System.......................................................................................... 95.1.2 Phone System.......................................................................................... 9
5.1.3 Audio/Video/Trace Logs ....................................................................... 115.2 Implementation Guideline ............................................................................. 11
5.3 Limitations.................................................................................................... 126 Comparative Study of proposed implementations.................................................. 12
6.1 Third party software support.......................................................................... 126.2 Onsite support ............................................................................................... 12
6.3 Target system requirements........................................................................... 126.4 Need of additional software on target to support remote debugging............... 12
7 Benefits of Mobile over Laptop............................................................................. 12
8 Conclusion............................................................................................................ 139 References ............................................................................................................ 13
7/27/2019 Remote Debugging of Embedded Systems_Amit Joshi
3/13
3
1 OverviewThe latest mobile phones are not limited to basic phone functionalities only. They are
rapidly emerging as aids in all our day to day activities. Currently SMS alerts are used tonotify the out of office user about updates such as build completion or test fail status
which can trigger requisite action; our idea is to utilize the omnipresent all powerfulcell phone for remote debugging of embedded devices.
In this paper, investigations are made on methods to provide such an arrangement. Our
proposed approaches are just ideas and have not been implemented.
2 Need for remote debuggingAvailability of the actual embedded hardware during development phase is scarce.Frequently teams are spread across onsite and multiple offshore locations across
continents. It is not uncommon to have frequent changes in hardware duringdevelopment.
Considering these limitation, remote debugging offers following benefits
1. Cost saving Savings in terms of Lab space, infrastructure at multiple locations,travel expenses, hardware shipment.
2. Reduce development time Hardware unavailability can create a bottleneck forteams working in offshore locations. With remote debugging facility teams willnot be affected due to shipping delays.
3. Easier collaboration and coordination between teams located at geographicallydistant locations.
Hence it is very much essential to have ability to debug and test embedded software
without having the hardware at developer location.
3 Remote Debugging of Embedded Systems ChallengesWith increased focus on distributed software development, the need to merge andcoordinate the activities of remotely located teams is one of the foremost challenges. The
issues get magnified when working in the embedded domain.
First we shall try to study the many parameters which contribute to the challenges ofremote debugging of embedded systems.
7/27/2019 Remote Debugging of Embedded Systems_Amit Joshi
4/13
4
1. Usually the hardware setup comprises of discrete units and multiple sources ofinput. Various components of the hardware need to be manipulated for the various
test scenarios. Other than key board presses, some other input sources mayinclude key presses on the hardware unit, knob rotation, slider movement, touch
screen options, audio inputs, external device plug-in etc. Thus when the
developer/tester is not physically present at the target environment locationsuitable methods need to be devised to provide similar inputs as and whenrequired. Simulators are often designed to address this requirement.
2. Similarly there are possibilities of multiple output mechanisms.a. For embedded systems which have a Human Machine Interface there is
the added overhead of tapping any audio or video outputs and transmitting
the same to the remotely located developer.b. For Performance Monitoring and Fault Monitoring solutions, the
verification often relies on some independent detection device. In suchcases, the output can be in the form of signal generated wave forms, or
some indicator light blinking or some beep sound. When the developer isnot physically present to monitor such output forms there is the additional
overhead of recording and transferring the data.
3. The embedded hardware systems are mostly run on Real Time OperatingSystems. This adds the time criticality parameter to data capturing and
transmission. Delays may not be acceptable in most of the situations and databuffering and transmission have to be handled keeping this parameter in mind.
4. If the embedded system employs some packet based protocol then the datatransmission order is critical. Also, data integrity needs to be preserved along withflow control mechanisms. Sometimes separate tools are designed to study the
packet formats and extract relevant information. In case of remote developers,such applications also need to be ported for easy analysis of results.
5. Usually the hardware setup necessitates physical presence at the location as theyinvolve simulator/emulator, boards, wire etc which need to be manuallyconnected. Power on/off type of functions can be remotely performed through
Remote Power Switches which enables remotely located users to turn on/ turn off/reboot systems at will. However, in many cases, the wire connections need to be
modified during the verification and validation process. For example when testingVirtual Concatenation of SONET data, the links may need to be
connected/disconnected at run time. Tools need to be developed to handle suchfunctions via some remote trigger.
6. In many cases, the code needs to be flashed and firmware downloaded in multiplelocations and their might be hardware dependencies [USB stick to be inserted /
JTag to be connected]. Methods need to be devised to automate the process ordesign some script which would make this a one click operation as a debugging
session entails multiple cycles of code change, compilation and download to testthe fixes.
7/27/2019 Remote Debugging of Embedded Systems_Amit Joshi
5/13
5
7. Usually embedded systems employ proprietary software as well as in-housedeveloped protocols and hence there is the added concern about security. All the
code, data, information that is shared needs to be over a secured channel after userauthentication.
8.
Although not particular to the embedded domain, there always remains thechallenge to synchronize the operations performed by multiple parties. Theremight be more than one developer wanting to access the system simultaneously;
again change management needs to be implemented to coordinate the activitiessuch as code check in/check out etc.
9. Any remote setup always incurs the additional overhead in terms of resources andcost for system [both hardware and software] compatibility and connectivityissues. This also is not specific to embedded systems but the same issues get
magnified due to the many other parameters listed above.
We would like to propose two different approaches to address some of the above issues.
4 Approach 1 Use mobile device to remotely login to hostmachine
The theory behind this approach is log on to the development PC using remote desktop
application. Remote user can be considered to be virtually present at development PC.He\She can now browse source code, compile, download the executable and then debug
and test. If needed a fix can be applied and recompiled and tested.
4.1 Requirements1. Internet connectivity to development PC and mobile device2. A laptop or a mobile device capable of running windows applications
7/27/2019 Remote Debugging of Embedded Systems_Amit Joshi
6/13
6
Block Diagram of the System
4.2 Implementation Guideli ne1. A Virtual Network Connection server should be installed on development PC.
VNC server should be configured with optional password.
2. If the product under development has display device connected and the audiooutput needs to be tested then a camera should be connected to capture video and
audio from hardware. A streaming server also needs to be started on thedevelopment PC. This will transmit audio and video from the development PC.
3. Application to connect to remote PC using mobile phone should be installed onremote mobile device. Mocha VNC Lite is an example of such an applicationthrough which user can connect to remote PC on iPhone.
Development
Hardware
Development PC
- IDE- VNCServer- Streaming
Server
Ethernet
Internet
USB
Ribbon cable
Audio and Video
capture
Mobile
Device
[Mocha VNC
Streaming
Video
viewer]
7/27/2019 Remote Debugging of Embedded Systems_Amit Joshi
7/13
7
4. Remote user should start mobile application in order to connect to thedevelopment PC. The IP address of the development PC and optional passwordshould be entered.
5.
An application to access streaming server should be downloaded and started onremote mobile device.
6. Remote user is now virtually present at development PC. He\She can now browsesource code, compile, download executable and then debug and test.
7. If needed a fix can be applied and recompiled and tested.8. Additionally captured debug logs can be viewed on mobile device. Also it can be
sent via email for further analysis.
4.3Challenges
1. Source Code integrity - While remote debugging gives the ability to debug andtest hardware, it also requires access to source code over internet. This must beprotected against unintended access.
2. Network Security: Since the remote user has to log onto the development PC, it willbe a risk to company network. It is possible to spread malicious viruses from thiscomputer. Proper access rights must be defined for remote user.
3. Convenience: It may not comfortable to debug from remote mobile device whichhas smaller display.
4.4 Advantages1. Easy - Various applications to connect to PC using VNC viewer client already
available.
2. Additional porting is not required - Since remote user has full access to thedevelopment PC through remote mobile device, additional effort is not needed toport the source code browser, cross compiler, download agent etc on various
mobile phones.
4.5 Limitations1. This approach needs onsite support. Some person may be needed at hardware
location in case power recycle or reconnection is needed.
2. Internet speed will affect debugging.
7/27/2019 Remote Debugging of Embedded Systems_Amit Joshi
8/13
8
5 Approach 2 Use mobile device as a host machineIn the second approach, the support of host system is eliminated. The ever growingcapacity of mobile functionality is leveraged to connect directly to the target system. The
purpose is to enable communication between the debugger application running in the cell
phone and the target environment using the wireless network. The target is equippedwith an Ethernet JTAG adaptor card and a user interface input simulator. Theaudio/video and output logging trace would be live streamed to facilitate the developer to
gain physically presence experience.
Block Diagram of the System
Remote debugging is the process of debugging a program running on a system different
than the debugger. To start remote debugging, debugger connects to a remote systemover a network. Once connected, debugger can control the execution of the program on
the remote system and retrieve information about its state. Processors used in embeddedsystems typically have extensive JTAG debug support. Most system consists of an
adaptor unit that sits between the host computer and the system to be tested. Mostmodern systems use the target system's CPU directly, with special JTAG-based debug
access. It enables programmer to access the on-chip debug circuit that is integrated intothe CPU via JTAG in order to debug the software of an embedded system. Processors
can normally be halted, single stepped or let run freely. Code breakpoints are supported,data breakpoints are often available. JTAG programmers are also used to write software
7/27/2019 Remote Debugging of Embedded Systems_Amit Joshi
9/13
9
and data into flash memory. Besides debugging, another application of JTAG is allowingdevice programmer hardware to transfer data into internal non-volatile device memory.
5.1 Requirement5.1.1 Target System
The target system apart from regular blocks would consists of Ethernet based JTAGadaptor. It enables the phone to connect to the target using the Ethernet adaptor which
will support the debug programs using the standard JTAG interface.
The user input is provided through another application running on the target. This
application will receive the key inputs from the simulator application running on the
phone. Both the applications would communicate over the wireless network.
5.1.2 Phone SystemAn integrated development environment (IDE) software application would be residing onthe cell phone. It would typically consist of a source code editor, a compiler and/or an
interpreter; build automation tools, a debugger. The phone would have the client softwareto view the live streaming of audio, video and trace logs. User input to the target system
can be provided by a simulator application running on the phone. Selection of key inputscan be simulated by pressing key inputs on the simulator.
JTAG
ADAPTOR CPUEthernetAdaptor
Clock
DataIn
DataOut
Reset
Mode Select
Ethernet
7/27/2019 Remote Debugging of Embedded Systems_Amit Joshi
10/13
10
7/27/2019 Remote Debugging of Embedded Systems_Amit Joshi
11/13
11
5.1.3 Audio/Video/Trace LogsA camera with a microphone device such as webcam, need to be established for capturing
the video and audio output. The print or debug statements which are typically capturedon hyper terminals have to be captured and transmitted along with other output.
5.2 Implementation Guideli ne1. The target device is made powered by resident engineer. The target to have an IP
address to support remote connection.2. Set up to be made ready at the target location for the audio, video from to be
captured via camera and transmitted to streaming server. If there is need tocapture trace logs, it needs to be fed to streaming server too. A streaming server
also needs to be up and running. This will transmit audio and video to the mobilehost application.
3. User to start the mobile debugger applications. The remote debugger connectionto target to be made via JTAG Ethernet adaptor. Definitely this would require
remote authentication first.4. User can edit, compile and download the image to the target and run.5. Start the host applications to connect to streaming server for live audio, video
update.
7/27/2019 Remote Debugging of Embedded Systems_Amit Joshi
12/13
12
6. Start the keyboard simulator which communicates with the resident application onthe target and provide user input at run time.
7. User can run trace log applications to receive debug prints/logs continuously fromthe streaming server.
5.3Limitations
For debugging electronic hardware (e.g., computer hardware) as well as low-levelsoftware (e.g., BIOS, device drivers) and firmware, instruments such as oscilloscopes,
logic analyzers are often used. Methods need to be established to provide thisinformation to the developer.
Since there is different IDE for various target CPU, debugger software need to bedeveloped for mobile platforms
6 Comparative Study of proposed implementations6.1 Thi rd party software support
Both approaches require third party software support.
6.2 Onsite supportBoth approaches might require onsite support if power cycle or manualhardware connection is needed.
6.3 Target system requi rementsApproach 1 does not require Ethernet support on target systems. Hence it can be
used for the target systems without Ethernet capability as well.Approach 2 needs Ethernet support on target systems.
6.4 Need of additional software on target to support remote debuggingApproach 2 will need resident application on the target to provide user input at
run time.
7 Benefits of Mobile over LaptopThe last few years has witnessed a shift from static work locations restricted by the
desktop machines to the relatively portable laptops. With advent of smart phones thathave lots of computing punch it is possible to handle nearly every computing task that a
regular developer would require. Hence we can aim for even more portability with apocket-size gadget that weighs a fraction of laptop computers.
Smart phones offer another advantage: coverage. Users can access the Internet anywhere
they can get a cell phone signal. A major drawback of using a laptop for mobile work isthe requirement of a wireless access point.
7/27/2019 Remote Debugging of Embedded Systems_Amit Joshi
13/13
13
8 ConclusionIn this whitepaper we have tried to explore some of the opportunities and conveniencesthat remote debugging techniques will provide along with implementation ideas and how
it can be interfaced with commercially available software for easy operability.
9 References1. http://en.wikipedia.org/2. http://online.wsj.com/3. http://www.mochasoft.dk