Debugging of a Remote Embedded System through cell phone

Abstract:
All embedded products are driven by time to market reduction, quality improvement. It becomes 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 could enable engineers to communicate with the development hardware system across the globe. The developer who is remotely located could use the cell phone to load programs into 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 and effective instant messaging communication. The viewing of any graphical display output is possible in the form of streaming video via mobile telecommunication network.

Author:
Himanshu Shrinkhal Amit S Joshi Srijita Sengupta

TABLE OF CONTENTS
1 2 3 4 Overview ................................................................................................................ 3 Need for remote debugging ..................................................................................... 3 Remote Debugging of Embedded Systems Challenges ......................................... 3 Approach 1 Use mobile device to remotely login to host machine ........................ 5 4.1 Requirements .................................................................................................. 5 4.2 Implementation Guideline ............................................................................... 6 4.3 Challenges....................................................................................................... 7 4.4 Advantages...................................................................................................... 7 4.5 Limitations ...................................................................................................... 7 Approach 2 Use mobile device as a host machine................................................. 8 5.1 Requirement.................................................................................................... 9 5.1.1 Target System.......................................................................................... 9 5.1.2 Phone System .......................................................................................... 9 5.1.3 Audio/Video/Trace Logs ....................................................................... 11 5.2 Implementation Guideline ............................................................................. 11 5.3 Limitations .................................................................................................... 12 Comparative Study of proposed implementations.................................................. 12 6.1 Third party software support.......................................................................... 12 6.2 Onsite support ............................................................................................... 12 6.3 Target system requirements........................................................................... 12 6.4 Need of additional software on target to support remote debugging............... 12 Benefits of Mobile over Laptop............................................................................. 12 Conclusion............................................................................................................ 13 References ............................................................................................................ 13

7 8 9

1 Overview
The 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 to notify 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 powerful cell 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 debugging

Availability 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 during development. 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 for teams working in offshore locations. With remote debugging facility teams will not be affected due to shipping delays. 3. Easier collaboration and coordination between teams located at geographically distant 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 Challenges

With increased focus on distributed software development, the need to merge and coordinate 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 of remote debugging of embedded systems.

1. Usually the hardware setup comprises of discrete units and multiple sources of input. Various components of the hardware need to be manipulated for the various test scenarios. Other than key board presses, some other input sources may include 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 location suitable methods need to be devised to provide similar inputs as and when required. 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 such cases, the output can be in the form of signal generated wave forms, or some indicator light blinking or some beep sound. When the developer is not 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 Operating Systems. This adds the time criticality parameter to data capturing and transmission. Delays may not be acceptable in most of the situations and data buffering and transmission have to be handled keeping this parameter in mind. 4. If the embedded system employs some packet based protocol then the data transmission order is critical. Also, data integrity needs to be preserved along with flow 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 they involve simulator/emulator, boards, wire etc which need to be manually connected. 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 testing Virtual Concatenation of SONET data, the links may need to be connected/disconnected at run time. Tools need to be developed to handle such functions via some remote trigger. 6. In many cases, the code needs to be flashed and firmware downloaded in multiple locations and their might be hardware dependencies [USB stick to be inserted / JTag to be connected]. Methods need to be devised to automate the process or design some script which would make this a one click operation as a debugging session entails multiple cycles of code change, compilation and download to test the fixes.

7. Usually embedded systems employ proprietary software as well as in-house developed 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 user authentication. 8. Although not particular to the embedded domain, there always remains the challenge to synchronize the operations performed by multiple parties. There might be more than one developer wanting to access the system simultaneously; again change management needs to be implemented to coordinate the activities such as code check in/check out etc. 9. Any remote setup always incurs the additional overhead in terms of resources and cost for system [both hardware and software] compatibility and connectivity issues. 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 host machine

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 Requirements
1. Internet connectivity to development PC and mobile device 2. A laptop or a mobile device capable of running windows applications

Ethernet

Development Hardware

Development PC
USB

Ribbon cable

IDE VNC Server Streaming Server

Internet

Mobile Device [Mocha VNC Streaming Video viewer]

Audio and Video capture Block Diagram of the System

4.2 Implementation Guideline

1. 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 audio output 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 the development PC. This will transmit audio and video from the development PC. 3. Application to connect to remote PC using mobile phone should be installed on remote mobile device. Mocha VNC Lite is an example of such an application through which user can connect to remote PC on iPhone.

4. Remote user should start mobile application in order to connect to the development PC. The IP address of the development PC and optional password should be entered. 5. An application to access streaming server should be downloaded and started on remote mobile device. 6. Remote user is now virtually present at development PC. He\She can now browse source 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.3 Challenges
1. Source Code integrity - While remote debugging gives the ability to debug and test hardware, it also requires access to source code over internet. This must be protected against unintended access. 2. Network Security: Since the remote user has to log onto the development PC, it will be a risk to company network. It is possible to spread malicious viruses from this computer. Proper access rights must be defined for remote user. 3. Convenience: It may not comfortable to debug from remote mobile device which has smaller display.

4.4 Advantages
1. 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 the development PC through remote mobile device, additional effort is not needed to port the source code browser, cross compiler, download agent etc on various mobile phones.

4.5 Limitations
1. 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.

5 Approach 2 Use mobile device as a host machine

In the second approach, the support of host system is eliminated. The ever growing capacity 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 equipped with an Ethernet JTAG adaptor card and a user interface input simulator. The audio/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 system over 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 embedded systems 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. Most modern 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 into the 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 8

and data into flash memory. Besides debugging, another application of JTAG is allowing device programmer hardware to transfer data into internal non-volatile device memory.

5.1 Requirement
5.1.1 Target System
The target system apart from regular blocks would consists of Ethernet based JTAG adaptor. It enables the phone to connect to the target using the Ethernet adaptor which will support the debug programs using the standard JTAG interface.

Clock

JTAG
Ethernet

DataIn DataOut Reset Mode Select

Ethernet Adaptor

ADAPTOR

CPU

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 System

An integrated development environment (IDE) software application would be residing on the 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 software to 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 inputs can be simulated by pressing key inputs on the simulator.

10

5.1.3 Audio/Video/Trace Logs

A 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 captured on hyper terminals have to be captured and transmitted along with other output.

5.2 Implementation Guideline

1. 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 to capture 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 mobile host application. 3. User to start the mobile debugger applications. The remote debugger connection to 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.

11

6. Start the keyboard simulator which communicates with the resident application on the target and provide user input at run time. 7. User can run trace log applications to receive debug prints/logs continuously from the streaming server.

5.3 Limitations
For debugging electronic hardware (e.g., computer hardware) as well as low-level software (e.g., BIOS, device drivers) and firmware, instruments such as oscilloscopes, logic analyzers are often used. Methods need to be established to provide this information to the developer. Since there is different IDE for various target CPU, debugger software need to be developed for mobile platforms

6 Comparative Study of proposed implementations

6.1 Third party software support
Both approaches require third party software support.

6.2 Onsite support

Both approaches might require onsite support if power cycle or manual hardware connection is needed.

6.3 Target system requirements

Approach 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 debugging

Approach 2 will need resident application on the target to provide user input at run time.

7 Benefits of Mobile over Laptop

The 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 that have 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 a pocket-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 is the requirement of a wireless access point.

12

8 Conclusion
In this whitepaper we have tried to explore some of the opportunities and conveniences that remote debugging techniques will provide along with implementation ideas and how it can be interfaced with commercially available software for easy operability.

9 References
1. http://en.wikipedia.org/ 2. http://online.wsj.com/ 3. http://www.mochasoft.dk

13