Académique Documents
Professionnel Documents
Culture Documents
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.
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.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
Internet
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.
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
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.
10
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
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