remote debugging of embedded systems_amit joshi

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


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


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.


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.


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


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/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.


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


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


10/13

10


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.


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.


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

remote debugging of embedded systems_amit joshi

Documents