The present invention relates to mobile systems, and more particularly to diagnostic testing of mobile systems.
Many different types of mobile systems exist. Examples of such systems include cellular telephone handsets, personal digital assistants (PDAs), notebook personal computers (PCs), and the like. During the design and development of such systems, significant resources are spent to confirm that the design and its implementation operate satisfactorily, both in laboratory testing and in the field during normal operation.
With respect to cellular telephones, for example, certain design issues may lead to systemic errors or performance issues that cannot be resolved during design phases or analysis of development or other prototype systems. Instead, such issues often arise only in the context of production systems. As a result, the final round of test and validation for a cellular handset is a systemic problem. All of the components of the phone may meet their respective specifications, but the unit as a whole may fail to meet one or more performance criteria, for a number of reasons. Many of these integration problems are inherently systemic and cannot be reproduced on a reference design, a development platform, or another handset model. Instead, such problems are debugged “in vivo” on the given handset model, and in some cases a specific handset.
Effective system debugging requires some degree of visibility into the internal operation of the handset, which is limited on a production model. Typically, in vivo debugging of handsets is performed using an integrated test mode or a conventional trace facility. The integrated test mode typically provides limited diagnostic capabilities and only allows limited viewing of trace data on a display of the handset. Conventional trace facilities are typically accessed using a serial port of the handset, and the tracing is typically limited to analysis of data from an internal microcontroller unit (MCU). Such trace information does not provide any visibility into the physical layer (Layer 1 in the OSI communication model) or digital signal processor (DSP) data.
Instead, to obtain such data a handset manufacturer may sometimes modify a handset to provide greater visibility. However, such modifications are time consuming and are often ineffective. For example, these modifications can vary operation of a handset to conceal problems, and may destroy the handset. Certainly, these handsets cannot be sold after the modifications are made. Nor are they generally suitable for field-testing of specific phone issues.
Accordingly, improved diagnostics for mobile systems would aid and speed handset development and debugging.
In one embodiment, the present invention includes an apparatus for permitting diagnostic testing of a production wireless device without any modifications to the device. The apparatus includes a first switch to route diagnostic information or acoustic information received from a processor, a codec coupled to the first switch to code the routed diagnostic information or acoustic information, and a second switch coupled to the codec to route the coded diagnostic information to a first port and to route the coded acoustic information to the first port or a second port. By selecting the switches appropriately, diagnostic information from the processor (which may be a digital signal processor) can be manipulated into a form for transmission through the first port, which may be an external acoustic port of the wireless device.
Another embodiment may be realized in the form of a method for performing a diagnostic routine in a wireless device such as a handset. The method may include generating diagnostic information in the handset, providing the diagnostic information to an external acoustic port of the handset, and forwarding the diagnostic information to a data collection unit from the external acoustic port. The data collection unit may be a personal computer such as a notebook computer or other portable device to allow for field-testing under a variety of conditions and locations.
Still further, an embodiment may be implemented in a mobile device that includes a processor having a data port and a diagnostic port. The processor may be, for example, a digital signal processor. The mobile device may further include a first switch coupled to provide a path to the diagnostic port or the data port. Also, the mobile device may include multiple audio ports, including an internal audio port coupled to the first switch to communicate audio data with the processor and an external audio port coupled to the first switch to communicate diagnostic information between the processor and a data collector during a diagnostic procedure. The data collector may be coupled to the external audio port via an interface unit that performs protocol manipulations on the diagnostic information sent from the mobile device. The interface unit may also provide control signals from the data collector to the mobile device for use in the diagnostic procedure.
In various embodiments of the present invention, a debug port of a wireless device is provided that may be used to inject control directives into and collect real-time trace data from the wireless device. Thus any production device including the port may be used for diagnostic purposes. As a result, phone issues occurring in a specific phone can be debugged using that phone itself. Furthermore, a diagnostic mode may be entered without modification of the handset, and without compromising handset operational modes and functions, as described below.
Virtually all cellular telephone handsets include a bidirectional acoustic port to which an external speaker and microphone can be attached. Embodiments of the invention “purloin” or co-opt this acoustic port for system debugging.
Referring now to
Furthermore, using data collection unit 20, control directives may be forwarded through DIU 15 for use in controlling diagnostic testing of handset 10. Accordingly, DIU 15 may modulate the control directives and provide them to handset 10 via bidirectional acoustic port 11. These control directives may be passed to a digital signal processor (DSP) within handset 10 for execution of diagnostic routines. The diagnostic routines may include testing of lower level (e.g., physical) layers of the DSP. Thus data collection unit 20 may include one or more storage media including instructions to perform diagnostic testing on a handset in accordance with an embodiment of the present invention. Further, the instructions may control storage and access to diagnostic trace data in data collection unit 20.
Referring now to
As shown in
As shown in
Still referring to
During diagnostic modes, data from trace port driver 112 is modulated in modem 115 and is switched through a first switch S1 to a codec 120. This diagnostic mode is shown in
During normal operation, voice processing is performed in DSP 110 and digitized data from codec port driver 114 is coupled via switch S1 through codec 120 and switch S2 to either external acoustic port 130 or an internal acoustic port 135 of IC 100, based on whether an external speaker/microphone is present. As shown in
In other embodiments, additional functionality may be implemented within DSP 110. For example, a voiceband modem may be implemented in software (i.e., a soft modem) for execution within DSP 110. Referring now to
Accordingly, to perform diagnostics the external acoustic port of a handset may be used. In some embodiments, an integrated test mode may be used to assign the external acoustic port for use in a diagnostic mode. However, other manners of allocating an external acoustic port to a diagnostic mode may be realized. When allocated to diagnostic service, the external acoustic port may remain in a diagnostic mode until one of several conditions occurs. In some embodiments, these conditions may include one of the following: (1) manual disabling of the diagnostic mode; (2) cycling of power on the handset; or (3) removing a power source from the handset (e.g., a battery).
While the types of diagnostic trace information may vary in different embodiments, in some embodiments the data may include information regarding operation of the DSP itself, along with physical layer data. Such data in the downlink direction may take various forms including, for example, log points, internal state data, and the like. Furthermore, diagnostic data to be captured may include low level data including, for example, I and Q data. Because such data may exist at higher bandwidths than may be accommodated via an external acoustic port, such data may be filtered and/or buffered, as described below. In the uplink direction, the connection from DIU 15 may carry control directives, which may take different forms. In some embodiments, the control directives may include, for example, enabling/disabling of specific trace points, querying of memory contents, modifying of internal states, and the like.
Trace data may be processed in various forms before it is sent in the downlink direction. For example, the trace data may be filtered and/or buffered. In such manner, trace data may conform to or match a speed of the link through bidirectional acoustic port 11. As discussed above, in some embodiments the link may have a speed of between approximately 50-60 kbps. To accommodate this speed, one or more buffers within DSP 110 may be used to store the trace data before it is sent through trace port driver 112. Furthermore, the trace data may be filtered. For example, only trace data that corresponds to a particular type of event (e.g., physical layer data, failure information or the like) may be sent. For example, code may be instrumented to generate trace data only for occurrences of certain events within the code.
By performing testing in accordance with an embodiment of the present invention, intermittent problems and/or problems that are hard to reproduce may be debugged. For example, issues relating to cell handover, dropping of calls and the like may be more readily debugged via field testing using a diagnostic setup in accordance with an embodiment of the present invention.
Because the external acoustic port is used for diagnostic purposes, the ability to listen to real audio during diagnostic modes may be precluded. However, while certain problems may manifest themselves as audio problems, the vast majority of problems are not in fact audio problems, but rather systemic issues, as described herein. Thus although real audio data may not be available during a diagnostic mode, successful debugging may occur.
Referring now to
Incoming RF signals are provided to a transceiver 310 which may be a single chip transceiver including both RF components and baseband components. Transceiver 310 may be formed using a complementary metal-oxide-semiconductor (CMOS) process, in some embodiments. As shown in
In some embodiments, transceiver 310 may correspond to ASIC 100 of
After processing signals received from RF transceiver 312, baseband processor 314 may provide such signals to various locations within system 300 including, for example, an application processor 320 and a memory 330. Application processor 320 may be a microprocessor, such as a central processing unit (CPU) to control operation of system 300 and further handle processing of application programs, such as personal information management (PIM) programs, email programs, downloaded games, and the like. Memory 330 may include different memory components, such as a flash memory and a read only memory (ROM), although the scope of the present invention is not so limited. Additionally, a display 340 is shown coupled to application processor 320 to provide display of information associated with telephone calls and application programs, for example. Furthermore, a keypad 350 may be present in system 300 to receive user input.
While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.
Number | Name | Date | Kind |
---|---|---|---|
5426643 | Smolinske et al. | Jun 1995 | A |
5557604 | Usumi et al. | Sep 1996 | A |
5586119 | Scribano et al. | Dec 1996 | A |
5623483 | Agrawal et al. | Apr 1997 | A |
5781593 | Petch et al. | Jul 1998 | A |
6064693 | Oliver et al. | May 2000 | A |
6421353 | Kim | Jul 2002 | B1 |
6658027 | Kramer et al. | Dec 2003 | B1 |
6754265 | Lindemann | Jun 2004 | B1 |
7248025 | Adachi | Jul 2007 | B2 |
7286522 | Preston et al. | Oct 2007 | B2 |
8116759 | Ying | Feb 2012 | B2 |
20020006138 | Odenwalder | Jan 2002 | A1 |
20020137506 | Matsuoka | Sep 2002 | A1 |
20020181446 | Preston et al. | Dec 2002 | A1 |
20030002609 | Faller et al. | Jan 2003 | A1 |
20030204563 | Oka et al. | Oct 2003 | A1 |
20040203467 | Liu et al. | Oct 2004 | A1 |
20070073535 | Chen et al. | Mar 2007 | A1 |
Number | Date | Country |
---|---|---|
4417286 | Nov 1995 | DE |
0876016 | Nov 1998 | EP |
1 229 747 | Aug 2002 | EP |
1 439 719 | Jul 2004 | EP |
1 441 497 | Jul 2004 | EP |
1441491 | Jul 2004 | EP |
06046083 | Feb 1994 | JP |
200472573 | Mar 2004 | JP |
564600 | Dec 2003 | TW |
I225342 | Dec 2004 | TW |
0024144 | Apr 2000 | WO |
WO 0184809 | Nov 2001 | WO |
Number | Date | Country | |
---|---|---|---|
20060281452 A1 | Dec 2006 | US |