Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Performing long-distance debugging

Posted: 01 Mar 2005 ?? ?Print Version ?Bookmark and Share

Keywords:embedded system? ocd? remote debug? interface? host?

Craig Haller of Macraigor Systems talks about things to be considered for remote debugging to work.

Embedded devices are finding themselves everywherefrom every room in the house, in the car and office, to remote assembly facilities and offshore drilling platforms. As the devices become more entrenched throughout the world, the importance of remote maintenance and debug comes to the forefront.

A typical debug setup consists of a host PC, a target connection and the device under test. In the vast majority of situations, the host is a PC typically running Microsoft Windows or Linux. There are several ways of communicating with the target under test, commonly via a parallel, serial or Ethernet connection. Many manufacturers offer connections to take advantage of the target's on-chip debug (OCD) capabilities. The OCD interface then connects to the target processor through a specified header.

When a device is manufactured with the intent of facilitating remote debug, three items must be considered. First, how will the target's OCD be accessed? If the connector for the OCD communications is physically deep within the systems, as is the norm, then the unit under test may have to be disassembled in the field, or somehow modified in ways that are probably not acceptable. Second, will the OCD interface be built into the unit or will it be externally applied? If in the lab one uses a serial interface from a host computer to communicate via an OCD interface to the target, will the final product have the OCD interface built in and only present the serial port to the outside? Or will an OCD interface be placed in the remote location along with the unit? The considerations here are more than just cost. If the unit is in a hostile environment and must be carefully sealed, the issues are different than if it is on a factory floor. Third, the issue of how to reach the OCD interface from the host computer must be considered. The host may be many miles away or may be physically carried to the remote location in which case size and weight of the host come into play. Even a modern laptop is not the easiest thing to carry when attempting to debug in the canopies of Guatemala.

Remote debug also refers to the less drastic cases of simply wanting to stay home and debug a new prototype that is in the lab at work. In this case, the issues are not so much how the test equipment access the target, but how the engineer access the host computer or how the host computer access the test equipment. There are different ways to handle each scenario.

Looking at the simplest case firstan engineer who wants to stay at home and debug a system in the lab back at work. Assuming the host computer is physically connected to the test equipment, the issue is how to control that computer from the home computer. There are several products on the market that make this simple. Assuming both systems have access to the Internet, there are several commercial solutions. By simply setting up an account with the Web-based GoToMyPC, anyone can easily, and securely, access a remote PC from any Web browser. So, working at home, the engineer can see a complete, working representation of the office computer's desktop on the local computer and test and debug the target as effectively as if he/she was physically present at the office. There are other commercial solutions, such as Symantec's pcAnywhere, that offer similar features with differences in security and client requirements. This situation requires that all the debug and maintenance software is installed on the system in the lab.

The problem gets more complex if the engineer wants to do some of the test and debug tasks locally while still having a remote target. If the engineer is more in the design phase, or if the maintenance or debug involves intensive compilations or simulation, the process might be easier using a local host. In this case, figure out how to connect the local computer with the debug interface. Considering that the fixture is still in the lab at work, try to abstract the host to debugger connection. This connection may be serial, parallel, USB or Ethernet. In this case, consider an Ethernet connection since that is easier.

In a local test environment, we often have an Intranet with many PCs, some test equipment and a gateway to the Internet. The components that are on the Intranet each have a local IP address that is not typically seen from the outside world. This offers security and is needed since there are not enough addresses for every device in the office to be open to the world. The gateway device, typically a router, is the guard at the door. It typically has an address that the world can see. To do the remote debug or maintenance, clients from the outside world need to have access to the device inside. Luckily, routers have a simple way of handling this. network address translation (NAT) is implemented as a lookup table inside the router. Simplified, TCP/IP communication uses a dual address scheme. Part of it is the IP address and the other part is a port number.

In the example, the router has an IP address that is exposed to the world via the Internet. Anyone from anywhere can have a direct communication to it. When the router gets a packet of information with its address, it looks at the port number that is targeted. This port number is compared with port numbers in the router's NAT table. If there is a match, the table will contain an internal IP address of the device that the communication is destined for. The packet will then be sent to the correct internal device, in this case, our Ethernet-based OCD interface. This scenario provides no security in that anyone knowing the IP address of the router and the desired port number of the debugger can access the system.

If more security is needed, there are other ways of interfacing a host computer with a remote debugger. A virtual private network (vpn) is a way of using the Internet to provide remote systems secure access to a host network. Instead of using dedicated phone lines or other secure communications, a VPN depends on security procedures such as password access, encrypting data and tunneling protocols. The engineer does not need to be concerned with all the details of how a VPN works past setting up the client software on the home machine and having the IT department set up the server side at the office or in the lab. Once a connection is established and authenticated over the Internet, the engineer sees the connection. All of the transmissions are encrypted, but more importantly, the engineer is seen as a valid user and is given access to both the OCD device and his target under test or more of the Intranet, as needed.

The next step is remote debug and maintenance in a truer sense of the word. Over the last few years, this technology has reached into some everyday devices such as vending machines. The newest machines actually contact distributors when they need to be refilled. This is typically accomplished with the embedded processor by simply using modem and phone lines. This setup is not restricted to a local inventory report, as the machine can also have its firmware upgraded or other maintenance over the same communication channel. Other embedded systems such as bank ATMs are becoming more intelligent as they are connected to host systems over phone or Ethernet to host systems and expanding their capabilities for remote debug, maintenance and upgrades.

Going a step further, there are more embedded systems finding their way to exotic places such as remote oilrigs as well as in the forests of South America. When the device is in a remote but not technically-challenged location, such as a modern oilrig, the Internet connection is still feasible. By building into the device an Ethernet-OCD debug connection, remote maintenance and upgrade is feasible. Satellite communications are allowing Web access in the most remote locations. Security issues are more vital in this case for a couple of reasons. The communication channel is more complex and possibly involves several technologies, and thus several points of failure or attack. An engineer may be doing the remote debug via a host computer on a phone line to a corporate server to a T1 high-speed connection onto the Internet to a satellite to a remote receiver, and somehow on to the target. A simple VPN may be running in the target device itself along with error-correcting communication codes.

Physical design of these devices is also important. Typically, there are considerations due to the environment they will be in, but thought is also given to how a service call will be performed. Since remote debug or maintenance may simply mean sending a technician to update firmware, the design should not mean the need for complete disassembly to reach an embedded EPROM.

- Craig Haller

Macraigor Systems LLC

Article Comments - Performing long-distance debugging
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top