Systems, devices, and methods for non-invasive platform telemetry reporting using an integrated connector

Abstract

The present invention relates to systems, devices, and methods for non-invasive platform telemetry reporting using an integrated connector. In one embodiment, a device includes a controller coupled between a system-on-chip (SoC) of a platform and an external connector. The controller can include: a digital converter for digitizing platform telemetry information of the platform; and a control circuit for receiving commands from a debug test system and directing the platform telemetry information to a destination in response to the commands. Other embodiments are described and claimed.

Description

Technical Field

[0001] Embodiments generally relate to techniques for debugging and transmitting telemetry information related to a computing device, and more particularly, to techniques for debugging and transmitting telemetry information related to a computing device using an all-in-one connector. Background Art

[0002] A computing system may include integrated circuits, system-on-chips (SoCs), and other circuit components. Components of these systems, including firmware components, operating system driver components, etc., may encounter errors. In a computing device, debugging may include the process of finding and reducing errors or defects in a computer program or an electronic hardware, as well as optimizing the performance, power consumption, and stability of the computing platform. In some cases, debugging may be performed when the chassis of the computing device is opened to expose the debugging interface. When the computing device has a closed chassis, it often increases the difficulty of debugging.

[0003] Debugging systems often use ad hoc schemes to obtain information from the system, while other systems use standardized debugging interfaces. However, for any given system, the debugging capabilities are typically limited to a single solution. Additionally, these debugging techniques are generally limited to the transmission of debugging information and do not provide the ability to obtain information about other platforms, and the ability to obtain information about other platforms may be desired by at least some end users. Brief Description of the Drawings

[0004] Figure 1 is a block diagram of a high-level view of a platform according to an embodiment.

[0005] Figure 2 is a block diagram of a system according to an embodiment of the present invention.

[0006] Figure 3 is a flowchart of a method according to an embodiment of the present invention.

[0007] Figure 4 is a flowchart of a method according to another embodiment of the present invention.

[0008] Figures 5A - 5B is a block diagram showing various ways of transmitting telemetry information in an environment according to an embodiment.

[0009] Figure 5C is a block diagram of a system environment according to yet another embodiment.

[0010] Figure 6 is a block diagram of a system according to an embodiment of the present invention.

[0011] Figure 7 is a block diagram of an exemplary system that may use embodiments.

[0012] Figure 8 is a block diagram of another exemplary system in which embodiments can be used.

[0013] Figure 9 is a block diagram of a system-on-chip according to an embodiment. DETAILED DESCRIPTION

[0014] Now referring to Figure 1 , a block diagram is shown of a high-level view of a platform 100 according to an embodiment. More specifically, the platform 100 can be any type of computing system ranging from, for example, relatively small portable electronic devices (such as smart phones, tablet computers, phablets, laptop computers, Internet of Things (IoT) devices, digital information entertainment devices, etc.) to larger systems (such as desktop computers, server computers, etc.). In the embodiments described herein, the platform 100 can be an enclosed chassis system, which means it is a fully fabricated system implemented within a given chassis. As will be described herein, the embodiments enable various non-invasive techniques to capture telemetry information related to the platform. As used herein, "telemetry information" includes any one of the electrical conditions, environmental conditions, and physical conditions (etc.) of the device and / or various system operating parameters. In the context of the platform herein, such telemetry information can include voltage information, current information, temperature information, movement information, and / or connection information (i.e., whether one or more peripheral devices are currently coupled to the device). In other cases, the telemetry information can include bandwidth information, time-in-state information, error information, memory residency, low-power state residency, silicon register information, the state of electrical pins, data obtainable from system sensors, etc.

[0015] Such information can be used in a wide variety of contexts, including during product validation of a prototype system, during system manufacturing testing (at the board level or at the system level), during transmission of at least some of the telemetry information to an end user, during providing at least some of the telemetry information for modulation purposes for a system that has suffered a fault, failure, etc. in the field. Of course, other uses of the telemetry information obtained by the non-invasive techniques described herein are possible.

[0016] In Figure 1In the illustrated embodiment, system 100 includes a system-on-chip (SoC) 110. In various embodiments, SoC 110 can be a multi-core processor that serves as the main central processing unit (CPU) of system 100. In different implementations, SoC 110 can include a variety of integrated processing engines, including general-purpose processor cores (which can be homogeneous cores and / or heterogeneous cores), graphics processors (e.g., one or more graphics processing units (GPUs)), dedicated processing units, fixed-function units, etc., as well as one or more levels of cache memory, memory controllers, communication circuits, interface circuits, and the like.

[0017] For the purpose of providing at least some debug information and / or platform features, such as for performance maximization, multiplexer 112 enables SoC 110 to selectively transmit information via Joint Test Action Group (JTAG) technology, Compact Joint Test Action Group (cJTAG) technology, and / or via Universal Asynchronous Receiver / Transmitter (UART) technology (or another serial communication technology such as ARM Serial Wire Debug (SWD) technology). SoC 110 can communicate with connector 150 via Universal Serial Bus (USB) pins (e.g., in accordance with the USB3 specification). In the embodiments described herein, USB connector 150 can be implemented as a USB Type-C connector. Connector 150 can comply with the USB Type-C Cable and Connector Specification, Revision 1.2 (March 25, 2016, Type-C Debug Accessory Mode (Appendix B)) or any of its extensions. Connector 150 can include a reversible plug connector that can be used on platform 100 and one or more peripheral devices. Other integrated ports can also be implemented in the debug technologies described herein.

[0018] The external connector 150 may have pins, including pins D+ and D- for data lines, which are arranged, for example, on the upper and lower halves of the connector such that they are exactly opposite each other. The arrangement of the data lines provides a reversible function such that the plug can be received at the connector 150 in a right-side-up or inverted orientation. The connector 150 may include a 24-pin double-sided connector interface, thereby providing four power / ground pairs, two differential pairs for the USB2.0 High-Speed (HS) data bus, four pairs for the SuperSpeed (SS) data bus, two Sideband Use pins (SBU1, SBU2), two Configuration Channel pins (CC1, CC2) for cable direction detection (which may be dedicated Biphase Mark Code (BMC) configuration data channel pins), and power interface pins. As shown, the USB connector 150 includes various pins, including SBU1, SBU2, multiple transmit and receive pins (TX1_P / N, TX2_P / N, RX1_P / N, RX2_P / N), as well as a voltage pin (VBUS), Configuration Channel (CC) pins (CC1, CC2), and additional USB pins (USB2). The Sideband Use (SBU) pins may include SBU1 and SBU2. The techniques described herein include setting SBU1 and SBU2 to default to a debug mode when the Configuration Channel (CC) pins CC1 and CC2 are disconnected, or otherwise not communicatively coupled to an external computing device (such as a debug test system). When CC1 and CC2 are disconnected, SBU1 and SBU2 default to a mode herein referred to as "Debug Special Mode" (DSM). In sub-mode 2, CC1 and CC2 remain unconnected, and Test Data Input (TDI) and Test Data Output (TDO) debug data can be transmitted via the D+ / D- pins. In one embodiment, depending on the selected debug protocol, SBU1 may transmit TMSC / SWDIO data, while SBU2 may transmit TCK (and / or TCKc) / SWDClk data.

[0019] As further shown, platform 100 also optionally includes components for radio frequency (RF) communication, including RF circuitry 160. To enable battery charging, there is also a battery charger 170. Platform 100 further includes a power management integrated circuit (PMIC) 120, which in one embodiment can be implemented as a stand-alone integrated circuit to provide platform-level power management operations. PMIC 120 is coupled between SoC 110 and USB connector 150. To perform various platform power management operations, PMIC 120 includes a controller 122, which in turn can include USB Power Delivery (USB-PD) control circuitry 124 (which in an embodiment can include physical unit circuitry, i.e., at least one physical layer). In an embodiment, control circuitry 124 can operate in accordance with the Universal Serial Bus Power Delivery Specification (USB-PD) (Version 1.2, Revision 2.0, March 25, 2016) and Engineering Change Notice (ECN) (August 2, 2016) and / or other protocols or extensions thereof. Additionally, PMIC 120 can also include a USB multiplexer 126.

[0020] It should be understood that controller 122 can also include control circuitry that is adapted to implement flexible routing of telemetry information obtained within PMIC 120. In different usage scenarios, this flexible control enables the transfer of telemetry information to one or more destinations within SoC 110 (including various destinations within SoC 110 and possibly via various communication paths), and similarly, the transfer of telemetry information via USB connector 150 to an external system such as a debugger system.

[0021] That is, in a debugging scenario, platform 100 (as discussed, platform 100 is an enclosed chassis system, which means it is not opened by an end user, engineer, technician, etc. and is in its original non-destructive testing form) can be coupled to an external debugger (the external debugger can be local or remote). More specifically, a debug test system 180 can be coupled to platform 100 via connector 150. As will be described in many cases herein, debug system 180 can send commands via connector 150 to controller 120 to enable the collection, processing, and delivery of telemetry information to a given destination (which can be one or more of SoC 110 and debug test system 180).

[0022] Thus, as described herein, the debug test system 180 can provide debug control and communication and collect debug trace results via a single standard connector of the platform. The external connector or integrated port can provide a power interface, can be at least partially or fully reversible, and can include a general-purpose data interface as well as additional dedicated data interfaces, such as a display interface, an audio interface, etc. Using a USB Type-C connection, telemetry information from the PMIC 120 can be collected and output to the SoC 110 or the external connector 150 in a standard manner without using a dedicated connector, opening the chassis for interaction, etc. It should be understood that although shown at this high level in the Figure 1 embodiments, many variations and alternatives are possible. For example, in other embodiments, instead of the PMIC, another type of controller can be coupled between the SoC 110 and the external connector 150. As an example, in other cases, the controller can be a USB Type-C port controller, an embedded controller, etc. This is the case when many systems may not include a separate PMIC. However, in various embodiments, a given controller or other device can manage power via a USB Type-C interface that is used as a host to perform the transfer of debug / telemetry information as described herein. Note that, as further described herein, in some cases, one or more intermediate devices capable of directly sensing data of interest and / or collecting / aggregating data from other devices can exist within the system. Thus, devices other than the SoC 110 can perform at least some of the functions described herein.

[0023] Now referring to Figure 2 , a block diagram of a system according to an embodiment of the present invention is shown. In Figure 2In the illustrated embodiment, system 100 is shown in more detail, including further details regarding components within SoC 110. SoC 110 includes a plurality of processor cores 114. These cores can include a collection of homogeneous cores and / or heterogeneous cores. As further shown, there is an interconnect system 115. In various embodiments, the interconnect system 115 can be implemented as one or more interconnects, such as a primary communication fabric, a secondary communication fabric, and / or a collection of independent interconnects that provide coherent and non-coherent communication between various components within SoC 110. As shown in the figure, the interconnect system 115 couples the processor cores 114 to a plurality of controllers, including a USB2 controller 116 and a USB3 controller 118. Additionally, the interconnect system 115 is coupled to a general-purpose input / output (GPIO) interface circuit 113, which provides an interface to PMIC 120 via a GPIO interconnect 135. As described herein, in an embodiment, PMIC 120 can transmit telemetry information to SoC 110 via the GPIO interconnect 135. In other embodiments, such communication can be via an 2 I2C or I3C interconnect (or a similar communication link).

[0024] Additionally, Figure 2 further details of PMIC 120 are shown. More specifically, PMIC 120 includes a digital converter 128, which can be one or more analog-to-digital converters (ADCs) in one embodiment. Various input signal information, including voltage signals, current signals, temperature information, and other telemetry information, can be transmitted to the ADC 128 for digitization. As shown in the figure, the ADC 128 has an output coupled to the GPIO interface circuit 125 of PMIC 120. It should be understood that although shown at this relatively high level in the Figure 2 embodiment, many variations and alternatives are possible. For example, in other embodiments, the digitization function can be performed within one or more other devices coupled to SoC 110 and / or a USB Type-C controller.

[0025] Now referring to Figure 3 , a flowchart of a method according to an embodiment of the present invention is shown. Figure 3 The method 200 can be executed in a platform controller, and more specifically, Figure 3 the method 200 can be executed in a control circuit that can handle platform power management activities for a given platform. As an example, the platform controller can be such as Figure 1 and Figure 2The PMIC shown. In an alternative embodiment, another type of controller, such as an embedded controller, may implement method 200. In other cases, the controller may be implemented within the SoC itself, for example, as part of a single-die SoC or as an independent die in a multi-chip package. In any case, in different embodiments, method 200 may be executed by hardware circuitry, software, firmware, and / or combinations thereof.

[0026] As Figure 3 shown, method 200 begins with receiving a request for platform telemetry information in the platform controller (block 210). The request may be received from different sources, the different sources including DTS or the SoC itself (e.g., by executing an application on the SoC). In other cases, the request may be received from another external source coupled to the enclosed chassis platform. It should also be noted that although the term "request" is used for ease of discussion, in many cases, the received request for telemetry information may actually be a command issued by the requester. As further described herein, in some cases, USB-PD messages may be used to provide such a command.

[0027] For the purposes of discussion herein, assume an implementation where the controller is an independent PMIC coupled to the SoC through multiple interconnects and may be further coupled to an external debugger such as DTS via an external connector of the enclosed chassis platform, which may be assumed to be a USB Type-C connector for the purposes of discussion herein. In some cases, the request may be received after a USB connection is made with the USB Type-C connector, and the controller may identify a voltage change (e.g., by detecting a voltage change on the CC1-CC2 pins). Further, in response to the voltage change detection, the controller may send an interrupt to the SoC (e.g., via the interrupt-L (INT-L) line). Further, details related to the detection of the resistor coupled to the CC1-CC2 pins may be sent, for example, via an I 2 C interconnect or an I3C interconnect to convey an in-band interrupt. In response to the interrupt, the SoC may configure a selection circuit (e.g., one or more multiplexers) to present specific information as described herein.

[0028] Still referring to Figure 3, control proceeds to block 220, where analog platform telemetry information can be obtained. More specifically, depending on the type of request (e.g., a request for a specific type of telemetry information), the analog platform telemetry information can be obtained from one or more platform sensors (such as voltage detectors, current sensors, temperature sensors, and other such sensors). To this end, the controller can receive the platform telemetry information, for example, by polling and convert it to digital format (block 230). For example, one or more ADCs of the platform controller can perform this digitization.

[0029] Note that although in many cases the telemetry information can be analog-based, the embodiments are not limited in this regard. For example, in other cases, the platform telemetry information can be digital information in nature. For example, the information can include digital information related to internal registers, storage space, the status of GPIO pins, etc. Such telemetry information can also include the identification of whether a particular device is connected to the platform, or other information about the environment in which the device is operating. As an example, information related to the connection to a docking station (e.g., via a binary switch) can be provided. Or, a close user interaction with the platform can similarly be in digital format (e.g., an indication from a human-machine interface device (HID) sensor), etc. Other examples of such information can include observed data related to switches, memory cards / expansion slots, system configuration, etc. Next, control proceeds to block 240, where the now-digitized platform telemetry information can be sent to the SoC via the requested interface. As described above, the platform controller can be coupled to the SoC through multiple interfaces including one or more GPIO interconnects, one or more USB interconnects, one or more I 2 C interconnects, etc. Depending on the specific request received, the platform controller can condition the platform telemetry information for transmission through the selected interface. Of course, in other cases, the platform telemetry information can be sent to another data source in the telemetry communication path.

[0030] Still referring to Figure 3 , further operations that can be performed within the SoC itself are shown. First, at block 250, the platform telemetry information can be processed, and additional SoC telemetry information may also be processed. That is, a given SoC can include integrated sensors, including voltage detectors, current sensors, temperature sensors, etc. This processing of various telemetry information can include conditioning the information for transmission to another entity, such as the DTS. Or, depending on a given usage scenario, information can be collected for statistical or other measurements over a longer period.

[0031] Although the scope of the present invention is not limited in this regard, Figure 3Optional exemplary uses of the telemetry information are further shown (shown in dashed boxes 260 and 270). In some cases, depending on a given request, SoC and / or platform power control (block 260) can be performed based on the telemetry information about the platform and / or SoC. For example, the internal power controller of the SoC can perform power control based on the SoC, including, for example, dynamic voltage and frequency scaling, dynamic entry into and exit from a given low-power state for a particular core (or other processing engine), and so on. As an example, when the telemetry information indicates that the platform is docked or the environmental information indicates that the temperature is low enough, an increase in frequency and / or voltage can be made. When additional power is available (e.g., by including additional batteries or auxiliary power into the platform), a similar operation can be followed.

[0032] Moreover, based on some or all of the SoC and / or platform telemetry information, platform-based power management activities can be performed. Of course, other types of platform-based control can also be performed based on the platform telemetry information, such as thermal control, for example, enabling or disabling one or more cooling solutions (e.g., fans). As other examples, the bandwidth of various interconnects such as memory interconnects can be dynamically controlled, or specific components of the platform can enter a specific low-power device state and other examples.

[0033] Finally, at block 270, another optional use case can be to display at least some of the telemetry information on a display of the platform to an end user. While many examples are possible, in some cases, the display can provide a graphical illustration of the telemetry information generally about both the SoC and the platform, such as voltage, current, and temperature conditions under a given workload. Other examples can include memory bandwidth usage, low-power state residency, such as how long the system has been in a given low-power system state (e.g., Sx state or S0ix state, etc.). Similarly, the display can be performed simultaneously or alternately with another display (e.g., a display associated with DTS). In addition to displaying such platform telemetry information, the data can also be recorded (possibly via a remote session) for further processing and analysis, or for local processing and analysis for a given system or for processing and analysis by an external debugger or other consumers of the information. In a particular case, the data can also be used by various control systems such as an automated manufacturing functional test system. In some cases, the data can also be written to a file and / or sent via a USB Type-C interface or other wired or wireless interfaces (e.g., local area network, Wi-Fi, Bluetooth, etc.). Also note that while method 200 is shown in a particular order, the embodiments are not limited thereto, and at least some of the processes within method 200 can be performed in other orders.

[0034] Now refer to Figure 4, which shows a flowchart of a method according to another embodiment of the present invention. As Figure 4 shown, method 300 is another method that can be executed in the platform controller, and more specifically in the control circuit discussed above, for example. In any case, in various embodiments, method 300 can be executed by hardware circuits, software, firmware, and / or combinations thereof.

[0035] As shown, method 300 begins with receiving a request for platform telemetry information from a debug test system in the platform controller (block 310). Next, control proceeds to block 320, where analog (and / or digital) platform telemetry information can be obtained from various sensors of the platform (such as those discussed above). Thereafter, control proceeds to block 330, where, as described above, the analog platform telemetry information is converted into a digital format. Finally, control proceeds to block 340, where the platform telemetry information is sent to the debug test system via the requested interface. As described herein, the platform controller can be coupled to the DTS via various interconnections coupled to, for example, a Type-C USB connector coupled to the DTS. Depending on a given request, the platform telemetry information can be transmitted to the DTS via the CC interconnect or the USB2 interconnect, but other exemplary interfaces are of course possible. Note that in many cases, embodiments can be used to provide almost instantaneous data collection. For example, information about the power consumed by a set of devices can be obtained in fine detail. It should be understood that although shown at this high level in the Figure 4 embodiments, many variations and alternatives are possible.

[0036] Now referring to Figure 5A , which shows an illustration of various ways of transmitting telemetry information in an environment according to an embodiment. As Figure 5A shown, environment 400 can include an SoC 110, a controller 120, a USB connector 150, and a DTS 180, such as those discussed above with respect to Figure 1 and Figure 2As described. As further shown in FIG. 5, a specific communication flow is also described. First, at block 410-1, the telemetry information is shown to be directly transmitted to the DTS 180. Here, the telemetry information is converted to a digital format in the controller 120 and further converted to a serialized 2-wire format for output via the CC1 / CC2 pins. This telemetry information can be directly used by the DTS 180 (or other host systems connected to the connector 150). In one example, the DTS 180 can send a query to the PMIC 120 via a USB-PD message, and the PMIC 120 interprets the command and responds via the CC1 / CC2 pins of the connector 150 to provide the telemetry information via the same CC1 / CC2 pins, as shown at 410-1. In other cases, basic communication (e.g., UART) can occur via the CC1 / CC2 pins and through the PMIC 120 and the SoC 110.

[0037] Block 410-2 shows a similar communication with the DTS 180. In this example, the telemetry information is converted to a digital format in the controller 120 and sent to the USB multiplexer 126. Note that in some embodiments, the USB multiplexer 126 can be implemented as a hub. In embodiments with a hub, a portion of the endpoints (e.g., ADCs) are only visible in debug mode. In this embodiment, when in production / functional use mode, only the standard endpoints are visible. When in debug mode (e.g., entered via the USB Type-C debug accessory mode), additional endpoints / devices become visible, e.g., the DTS 180 can communicate with two components (functional and debug) simultaneously. In one example, as shown at 410-2, the DTS 180 can send a query to the PMIC 120 via a USB-PD message, and the PMIC 120 interprets the USB-PD command and provides the telemetry information to the USB2 pin of the connector 150 via the USB multiplexer 126.

[0038] Now refer to Figure 5B , a diagram showing an additional way of transmitting telemetry information in an environment according to an embodiment is shown. In yet another example, the telemetry information can be provided from the PMIC 120 to the SoC 110. As one such example, the telemetry information, after being digitized, is via I 2The C interconnects (SCL and SDA lines) are sent to the SoC 110. For example, this information can be sent to one or more cores 114 for processing to be displayed to the user. As another example, this path can also be used to send to either or both of the USB2 controller / USB3 controller (116, 118) of the SoC 110 for outward transmission via the USB3 / USB2 interconnect and via the connector 150. In one example, the DTS 180 can send a query to the PMIC 120 via a USB-PD message, and the PMIC 120 interprets the USB-PD command and provides the telemetry information to the SoC 110 via the I 2 C line for internal or external use, as shown at 410-3. In other cases, note that the I 2 C line can be replaced by an I3C line, which can merge debug I 2 C operations (e.g., cJTAG) and functional I 2 C operations.

[0039] Box 410-4 shows another way to transmit the telemetry information to the SoC 110. As can be seen, the telemetry information is sent to the SoC 110 via a Serial Peripheral Interface (SPI) or Low Pin Count (LPC) interconnect after being digitized. As an example, this information can be sent to one or more cores 114 for processing to be displayed to the user. As another example, this path can also be used to send to either or both of the USB2 controller / USB3 controller (116, 118) of the SoC 110 for outward transmission via the USB3 / USB2 interconnect and via the connector 150. In one example, the DTS 180 can send a query to the PMIC 120 via a USB-PD message, and the PMIC 120 interprets the USB-PD command and provides the telemetry information to the SoC 110 via the SPI or LPC line for internal or external use, as shown at 410-4.

[0040] Box 410-5 shows another way to transmit the telemetry information to the SoC 110. As can be seen, the telemetry information is sent to the SoC 110 via a GPIO interconnect after being digitized. As an example, in response to one or more executed applications, this information can be sent to one or more cores 114 of the SoC 110 via the interconnect 115 for processing to be displayed to the user, for example, when needed. In one example, the DTS 180 can send a query to the PMIC 120 via a USB-PD message, and the PMIC 120 interprets the USB-PD command and provides the telemetry information to the SoC 110 via the GPIO interconnect 135, as shown at 410-5.

[0041] Block 410-6 illustrates another way to transfer telemetry information to the SoC 110. As can be seen, the telemetry information is sent to the SoC 110 via the GPIO interconnect after being digitized. In one example, the DTS 180 can send a query to the PMIC 120 via a USB-PD message, and the PMIC 120 interprets the USB-PD command and provides the telemetry information to the SoC 110 via the GPIO interconnect. As an example, this information can be sent to the USB3 controller 118. Further, as shown at 410-6, the USB3 controller 118 can process the telemetry information and send it out via the USB3 interconnect to the connector 150.

[0042] Block 410-7 illustrates another way to transfer telemetry information to the SoC 110. As can be seen, the telemetry information is sent to the SoC 110 via the GPIO interconnect after being digitized. In one example, the DTS 180 can send a query to the PMIC 120 via a USB-PD message, and the PMIC 120 interprets the USB-PD command and provides the telemetry information to the SoC 110 via the GPIO interconnect. As an example, this information can be sent to the USB2 controller 116. Further, as shown at 410-7, the USB2 controller 116 can process the telemetry information and send it out via the USB2 interconnect to the connector 150.

[0043] Although the scope of the present invention is not limited in this regard, in some cases, a set of commands can be used to control the data stream using USB-PD messages, as shown in Table 1. The control circuit within the PMIC 120 can include a processor / finite state machine programmed through these messages. Then the telemetry data is automatically collected and stored or sent to the user (e.g., the SoC or the DTS). It should be understood that in some cases, the PMIC can include a general-purpose UART for, e.g., kernel mode debugging. In this case, kernel mode debugging can be performed using the operating system running on the main CPU in the SoC. Further, the PMIC acts as a gateway to the SoC because kernel mode debugging is transmitted to the SoC (e.g., via I 2 C, I3C, or UART) via the USB-PD message through the PMIC (or a similar component). The PMIC (or an embedded controller or a similar component) can have a debuggable embedded controller / CPU. These debug commands can be tunneled through the USB-PD message without an additional interface to debug the PMIC (or an embedded controller, etc.). Similarly, the SoC can be debugged through the USB-PD message, e.g., by tunneling JTAG (or SWD or similar) commands through the USB-PD message without an additional interface.

[0044] Table 1

[0045] GET_DATA<AD Value>

[0046] READ <io>

[0047] SET <io>

[0048] CLEAR <io>

[0049] SAMPLE<Converter ID>

[0050] SAMPLE_ALL

[0051] GET_SAMPLING_RATE<converter ID>

[0052] SET_SAMPLING_RATE<converter ID>

[0053] OUTPUT <port>

[0054] In one embodiment, SET and CLEAR commands can be used to control GPIO pins, which can be used to activate board components. In one embodiment, READ can be used <io>commands to check the status of the board components, such as docking status, switch positions, etc., and other examples. As an example, Read can be used <io>The command is used to determine the type of interface available for sending telemetry data, and SET can be used <io>Commands are used to specify the paths to be used. Similarly, the SAMPLE command can be used to sample telemetry data at specific times, and the OUTPUT command can be used to send telemetry information to the corresponding output(s). Note that other commands are possible. For example, an event setting mechanism can be used to trigger the output or writing of the collected data, e.g., in response to a given event occurring. Further, commands can be provided to configure the system to output / record blocks of telemetry data for a given time period or a certain number of samples.

[0055] In various systems, by changing the component layout and telemetry capabilities, many different types of telemetry data can be collected and transmitted. Thus, embodiments can provide discovery routine processing to determine the type and quantity of sources. In other cases, this discovery can be bypassed when the user already knows the configuration of the system a priori.

[0056] It should be understood that the above techniques can also be used in combination with the MIPI Parallel Trace Interface (PTI) and the MIPI Narrow Interface Debug and Test (NIDnT) methods. In this way, embodiments can output telemetry information via pins using, for example, a USB3 / USB2 functional interface, an ad-hoc debug interface, and a MIPI-PTI / NIDnT interface.

[0057] Now referring to Figure 5C , a block diagram of a system environment according to yet another embodiment is shown. More specifically, as Figure 5C shown, the system environment 400' can generally be configured to be the same as the system 400 discussed above. However, additional details are described in this implementation. Additionally, there can be an additional telemetry host 185 that serves as an interface between the PMIC 120, the SoC 110, and various telemetry information sources, including, for example, one or more sensors 190 and one or more other devices 195. As can be seen, the sensors 190 and the devices 195 transmit data and / or signals to the telemetry host 185. As further shown, the telemetry host 185 also receives input signals from various parts of the platform, for example. The telemetry host 185 in turn communicates with the PMIC 120 via a telemetry interface and is also interfaced with the SoC 110. In different embodiments, this interface between the telemetry host 185, the PMIC 120, and the SoC 110 can be a single interface or a JTAG daisy chain. In other cases, the interface can be a proprietary interface.

[0058] Now referring to Figure 6 , a block diagram of a system according to an embodiment of the present invention is shown. In the Figure 6 embodiment, the system 900 can be a SoC including multiple domains, and each domain can be controlled to operate at an independent operating voltage and operating frequency. As a specific illustrative example, the system 900 can be based on Architecture Core TM SoCs, such as the i3, i5, i7, or another such processor available from Intel Corporation. However, as an alternative, in other embodiments, there may be other low-power SoCs or processors, such as those based on designs available from Advanced Micro Devices, Inc. (AMD) of Sunnyvale, California, those based on ARM designs available from ARM Holdings, Ltd. or its licensors, or those based on MIPS designs available from MIPS Technologies, Inc. of Sunnyvale, California or its licensors or adopters, such as the Apple A7 processor, the Qualcomm Snapdragon processor, or the Texas Instruments OMAP processor. Such SoCs can be used in low-power systems such as smartphones, tablet computers, phablet computers, Ultrabook TM computers, IoT devices, wearable devices, or other portable computing devices.

[0059] In Figure 6 the high-level view shown, the SoC 900 includes a plurality of core units 9100 - 910 n . Each core unit may include one or more processor cores, one or more caches, and other circuitry. Each core unit 910 may support one or more instruction sets (e.g., the x86 instruction set (with some extensions added for more recent versions); the MIPS instruction set; the ARM instruction set (with optional additional extensions such as NEON)) or other instruction sets or combinations thereof. Note that some core units may be heterogeneous resources (e.g., of different designs). Additionally, each such core may be coupled to a cache (not shown), which may be a shared level 2 (L2) cache in one embodiment. The non-volatile storage 930 can be used to store various programs and other data. For example, the storage can be used to store at least part of the microcode, boot information such as BIOS, and other system software, etc.

[0060] Each core unit 910 may also include an interface such as a bus interface unit to enable interconnection with additional circuitry of the SoC. In one embodiment, each core unit 910 is coupled to a coherence fabric, which can act as a primary cache-coherent on-die interconnect, which is in turn coupled to a memory controller 935. In turn, the memory controller 935 controls communication with a memory such as DRAM (not shown for ease Figure 6 of the illustration herein).

[0061] In addition to the core units, there are additional processing engines within the processor, including at least one graphics unit 920, which may include one or more graphics processing units (GPUs) to perform graphics processing and possibly general operations on the graphics processor (so-called GPGPU operations). Additionally, there may be at least one image signal processor 925. The signal processor 925 may be configured to process input image data received from one or more capture devices inside or outside the SoC. In one embodiment, the image signal processor 925 may process the telemetry information received from the platform-based controller as described herein and generate one or more graphical representations of the telemetry information for display on a display of a system including the SoC.

[0062] There may also be other accelerators. In Figure 6 the illustrated example, the video codec 950 may perform encoding and decoding operations including encoding and decoding of video information, such as providing hardware acceleration support for high-definition video content. A display controller 955 may also be provided to accelerate display operations, including providing support for internal and external displays of the system. Additionally, there may be a debug unit 945, and the debug unit 945 may include debug control circuitry to receive input debug and / or telemetry information (e.g., from one or more interfaces of the SoC 900) and provide the debug and / or telemetry information to an indicated destination. As described herein, the power consumption of each of these units may be controlled via a power manager 940, which may include control logic units to perform various power management techniques, including dynamic DVFS and dynamic bandwidth management to enable enhanced turbo mode during operation. It should be understood that, as described herein, the resources of the debug unit 945 may also be used in functional modes, for example, based on workload requirements.

[0063] In some embodiments, the SoC 900 may also include an incoherent structure coupled to a coherent structure, where each peripheral device may be coupled to the incoherent structure. One or more interfaces 960a - 960d enable communication with one or more off-chip devices. These communications may be in accordance with various communication protocols such as PCIe TM , GPIO, USB (including USB Type-C), I 2 C, I3C, UART, MIPI, SDIO, DDR, SPI, HDMI, and other types of communication protocols. In this way, the SoC 900 may transfer various debug and / or platform / SoC telemetry information to, for example, an external debug system coupled thereto. Although illustrated at this high level in Figure 6 the embodiment, it should be understood that the scope of the present invention is not limited in this regard.

[0064] Now refer to Figure 7 , a block diagram of an exemplary system in which embodiments may be used is shown. As can be seen, system 1200 may be a smart phone or other wireless communicator. Baseband processor 1205 is configured to perform various signal processing on communication signals transmitted from or received by the system. Baseband processor 1205 is in turn coupled to application processor 1210, which may be the main SoC of the system and is used to execute the OS and other system software in addition to user applications such as many well-known social media and multimedia applications. Application processor 1210 may further be configured to perform various other computing operations of the device and may include debugging circuitry as described herein.

[0065] Furthermore, application processor 1210 may be coupled to user interface / display 1220, such as a touch screen display. Additionally, application processor 1210 may be coupled to a memory system including non-volatile memory (i.e., flash memory 1230) and system memory (i.e., dynamic random access memory (DRAM) 1235). As can be further seen, application processor 1210 is further coupled to capture device 1240, such as one or more image capture devices that may record video and / or still images.

[0066] Still referring to Figure 7 , a universal integrated circuit card (UICC) 1240, including a subscriber identity module and possibly a secure storage and cryptographic processor, is also coupled to application processor 1210. System 1200 may also include a security processor 1250 that may be coupled to application processor 1210. A plurality of sensors 1225 may be coupled to application processor 1210 to enable input of various sensing information (e.g., accelerometer information and other environmental information). Audio output device 1295 may provide an interface to output sound, for example, in the form of voice communication, playing, or streaming audio data.

[0067] As further shown, a near field communication (NFC) contactless interface 1260 is provided, which communicates in the NFC near field via NFC antenna 1265. Although separate antennas are shown in Figure 7 , it should be understood that in some embodiments, one antenna or different sets of antennas may be provided to implement various wireless functions.

[0068] The PMIC 1215 is coupled to the application processor 1210 to perform platform-level power management. To this end, the PMIC 1215 can issue power management requests to the application processor 1210 as needed to enter specific low-power states. In addition, based on platform constraints, the PMIC 1215 can also control the power levels of other components of the system 1200. Similarly as described herein, the PMIC 1215 is configured to interact with a debug test system coupled to the system 1200, which is an enclosed chassis system. To this end, the PMIC 1215 can include digitization circuitry to digitize various different analog telemetry information in response to control signals received from the DTS (e.g., via a USB Type-C connector). Further, the PMIC 1215 can transmit at least some of this telemetry information to the application processor 1210, which can further process the telemetry information to enable it to be displayed on the display 1220 and can transmit at least some of the information as well as other debug / telemetry information to the DTS.

[0069] To enable the transmission and reception of communication information, various circuits can be coupled between the baseband processor 1205 and the antenna 1290. Specifically, there can be a radio frequency (RF) transceiver 1270 and a wireless local area network (WLAN) transceiver 1275. Generally, the RF transceiver 1270 can be used to receive and transmit wireless data and calls according to a given wireless communication protocol such as a 3G or 4G wireless communication protocol (e.g., according to Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), Long Term Evolution (LTE), or other protocols). Additionally, there can be a GPS sensor 1280. Other wireless communications can also be provided, such as receiving and transmitting radio signals, such as AM / FM and other signals. Additionally, via the WLAN transceiver 1275, local wireless communication can also be achieved, for example, according to the Bluetooth TM standard or the IEEE 802.11 standard (e.g., IEEE 802.11a / b / g / n).

[0070] Now referring to Figure 8 , a block diagram of another exemplary system in which embodiments can be used is shown. In the Figure 8 illustration, the system 1300 can be a mobile low-power system such as a tablet computer, a 2-in-1 tablet computer, a phablet, or other foldable tablet system or stand-alone tablet system. As shown, there is a SoC 1310, and the SoC 1310 can be configured to operate as an application processor of the device. The SoC 1310 can include debug circuitry as described herein.

[0071] Various devices can be coupled to the SoC 1310. In the illustrated diagram, the memory subsystem includes a flash memory 1340 and a DRAM 1345 coupled to the SoC 1310. Additionally, a touch panel 1320 is coupled to the SoC 1310 to provide display capabilities and touch-based user input, including providing a virtual keyboard on the display of the touch panel 1320. To provide a wired network connection, the SoC 1310 is coupled to an Ethernet interface 1330. A peripheral hub 1325 is coupled to the SoC 1310 to enable interfacing with various peripheral devices that can be coupled to the system 1300 through any one of a variety of ports or other connectors, for example.

[0072] In addition to the internal power management circuits and functions within the SoC 1310, a PMIC 1380 is also coupled to the SoC 1310 to provide platform-based power management, for example, based on whether the system is powered by a battery 1390 or by alternating current via an AC adapter 1395. In addition to this power source-based power management, the PMIC 1380 can also perform platform power management activities based on environmental and usage conditions. Additionally, the PMIC 1380 can transfer control and status information to the SoC 1310 for various power management operations within the SoC 1310. And, as described herein, the PMIC 1380 can act as an interface between an external debug system ( Figure 8 not shown in the figure) and the SoC 1310 for performing various debug and / or telemetry information transmissions.

[0073] Still referring to Figure 8 , to provide wireless capabilities, a WLAN unit 1350 is coupled to the SoC 1310 and in turn to an antenna 1355. In various embodiments, the WLAN unit 1350 can provide communication in accordance with one or more wireless protocols, including the IEEE 802.11 protocol, the Bluetooth TM protocol, or any other wireless protocol.

[0074] As further shown, a plurality of sensors 1360 can be coupled to the SoC 1310. These sensors can include various accelerometers, environmental sensors, and other sensors, including user pose sensors. Finally, an audio codec 1365 is coupled to the SoC 1310 to provide an interface to an audio output device 1370. Of course, it should be understood that while shown in this particular embodiment in Figure 8 , many variations and alternatives are possible.

[0075] Next, turn to Figure 9 , which shows an embodiment of a SoC design according to an embodiment. As a specific illustrative example, SoC 2000 is included in a user equipment (UE). In one embodiment, a UE refers to any device used by an end user, such as a wearable device, a handheld phone, a smartphone, a tablet, an ultra-thin notebook, a notebook, an IoT device, or any other similar device. The UE is typically connected to a base station or a node.

[0076] Here, SoC 2000 includes two cores 2006 and 2007. Similar to the above discussion, cores 2006 and 2007 may comply with an instruction set architecture, such as a processor based on Architecture Core TM , a processor of Advanced MicroDevices, Inc. (AMD), a MIPS-based processor, an ARM-based processor design or its customers, and processor designs of its licensors or adopters. Cores 2006 and 2007 are coupled to a cache controller 2008, which is associated with a bus interface unit 2009 and an L2 cache 2010 to communicate with other parts of the system 2000. The interconnect 2010 includes an on-chip interconnect.

[0077] The interconnect 2010 provides a communication channel to other components such as a debug unit 2030, which can perform debug operations and / or telemetry information processing as described herein. As can be seen, the debug unit 2030 can interface with multiple off-chip connections. The interconnect 2010 is also coupled to a boot ROM 2035 to store the boot code executed by cores 2006 and 2007 to initialize and boot the SOC 2000, coupled to an SDRAM controller 2040 to interface with an external memory (e.g., DRAM 2060), coupled to a flash memory controller 2045 to interface with a non-volatile memory (e.g., flash memory 2065), coupled to a peripheral controller 2050 (e.g., a serial peripheral interface) to interface with peripherals, coupled to a video codec 2020 and a video interface 2025 to display and receive inputs (e.g., touch-implemented inputs) via one of the MIPI or HDMI / DP interfaces, coupled to a GPU 2015 to perform graphics-related computations, etc.

[0078] In addition, the system shows peripherals for communication, such as a Bluetooth module 2070, a 3G modem 2075, a GPS 2080, and a WiFi 2085. The system also includes a power controller 2055. In one embodiment, the power controller 2055 can act as an interface between the SoC 2000 and an external debug system (not shown in Figure 9 for ease of illustration).

[0079] The following examples relate to further embodiments.

[0080] In one example, a device includes: a controller for coupling between an external connector of a platform and a SoC. The controller includes: a digital converter for digitizing platform telemetry information of the platform; and control circuitry for receiving commands from a debug test system and directing the platform telemetry information to a destination in response to the commands.

[0081] In one example, in response to a command having a first destination identifier, the control circuitry causes the platform telemetry information to be directed to the SoC, and in response to a command having a second destination identifier, the control circuitry causes the platform telemetry information to be directed to the debug test system.

[0082] In one example, the controller further includes a GPIO interface circuit for receiving the platform telemetry information from the digital converter and sending the platform telemetry information to the SoC via a first interconnect coupled between the controller and the SoC.

[0083] In one example, the controller includes a PMIC for coupling to the SoC via at least one USB interconnect and at least one GPIO interconnect.

[0084] In one example, the command includes a USB power delivery message.

[0085] In one example, in response to a command having a first interface identifier, the controller sends the platform telemetry information to the debug test system via a second interconnect coupled between the controller and the external connector.

[0086] In one example, the controller receives the command via the second interconnect.

[0087] In one example, in response to a command having a second interface identifier, the controller sends the platform telemetry information to the debug test system via a third interconnect coupled between the controller and the external connector.

[0088] In one example, in response to the command, the controller sends the platform telemetry information to the SoC, where the SoC in turn sends the platform telemetry information to the debug test system via the external connector.

[0089] In one example, in response to the command, the controller sends the platform telemetry information to the SoC so that at least one core of a processor can process the platform telemetry information to enable at least some of the platform telemetry information to be displayed on a display.

[0090] In another example, a method includes: receiving, in a controller of a system, a request for platform telemetry information from a requester, the controller being coupled between a processor of the system and an external connector of the system, the system including an enclosed chassis platform; obtaining, in the controller, platform telemetry information from one or more sensors of the system; and sending the platform telemetry information to a destination in response to a destination identifier associated with the request, the destination including one of the processor and a debug test system that is coupled to the system via the external connector.

[0091] In one example, the method further includes performing power control of one or more components of the system based at least in part on the platform telemetry information.

[0092] In one example, the method further includes enabling at least some of the platform telemetry information to be displayed on a display of the system, wherein the processor provides at least some of the platform telemetry information to the display.

[0093] In one example, the method further includes: converting, in the controller, at least some of the platform telemetry information from an analog format to a digital format; and sending the at least some of the platform telemetry information in digital format to the processor via a first interconnect coupled between the controller and the processor, wherein the controller includes a telemetry host.

[0094] In one example, the method further includes: receiving a request from the debug test system via a second interconnect coupled between the external connector and the controller; and sending the platform telemetry information to the debug test system via the second interconnect.

[0095] In another example, a computer-readable medium includes instructions for performing the method of any of the above examples.

[0096] In another example, a computer-readable medium including data is used by at least one machine to fabricate at least one integrated circuit to perform the method of any of the above examples.

[0097] In another example, a device includes modules for performing the method of any of the above examples.

[0098] In yet another example, a system includes: a System-on-Chip (SoC) that includes at least one core, an interconnect system, a first USB controller, and GPIO interface circuitry; a USB connector coupled to the SoC via a first USB interconnect to enable one or more devices to couple to the SoC; and a controller coupled to the SoC. In one example, the controller includes: GPIO interface circuitry; a digital converter for digitizing platform telemetry information of the system; control circuitry for receiving commands via the USB connector and directing the platform telemetry information to at least one of the SoC and a device coupled to the USB connector in response to the commands; and a USB selection circuit coupled to a second USB interconnect and a third USB interconnect. The system may further include a GPIO interconnect for coupling the GPIO interface circuitry of the SoC to the GPIO interface circuitry of the controller; a first USB interconnect for coupling the SoC to the USB connector; a second USB interconnect for coupling the SoC to the controller; and a third USB interconnect for coupling the controller to the USB connector.

[0099] In one example, the commands include USB power delivery messages from a debug test system coupled to the USB connector, and wherein the controller receives the USB power delivery messages via one or more configuration channel interconnects that couple the controller to the USB connector.

[0100] In one example, in response to the commands, the controller sends at least some of the platform telemetry information to the debug test system via one or more configuration channel interconnects.

[0101] In one example, in response to the commands, the controller sends the platform telemetry information to the SoC so that at least one core can process the platform telemetry information to enable at least some of the platform telemetry information to be displayed on a display of the system.

[0102] In one example, in response to the commands, the controller sends the platform telemetry information to the SoC, and further in response to the commands, the SoC sends at least a portion of the platform telemetry information to a first device coupled to the USB connector via the first USB interconnect.

[0103] In one example, a device includes: a module for receiving, in a control module, a request for platform telemetry information from a requester, the control module being coupled between a processor module of the system and an external connector module of the system, the system including an enclosed chassis platform; a module for obtaining platform telemetry information from one or more sensors of the system; and a module for sending the platform telemetry information to a destination in response to a destination identifier associated with the request, the destination including one of the processor module and a debug test system, the debug test system being coupled to the system via the external connector module.

[0104] In one example, the device further includes a module for performing power control of one or more components of the system based at least in part on the platform telemetry information.

[0105] In one example, the device further includes a module for enabling at least some of the platform telemetry information to be displayed on a display module of the system, wherein the processor module provides at least some of the platform telemetry information to the display.

[0106] In one example, the device further includes: a module for converting at least some of the platform telemetry information from an analog format to a digital format; and a module for sending the at least some of the platform telemetry information in digital format to the processor module via a first interconnect module coupled between the control module and the processor module.

[0107] In one example, the device further includes: a module for receiving a request from the debug test system via a second interconnect module coupled between the external connector module and the controller module; and a module for sending the platform telemetry information to the debug test system via the second interconnect module.

[0108] It should be understood that various combinations of the above examples are possible.

[0109] Note that the terms "circuit" and "electronic circuit" may be used interchangeably herein. As used herein, these terms and the term "logic unit" are used to refer, alone or in any combination, to analog circuits, digital circuits, hardwired circuits, programmable circuits, processor circuits, microcontroller circuits, hardware logic circuits, state machine circuits, and / or any other type of physical hardware component. Embodiments may be used in many different types of systems. For example, in one embodiment, a communication device may be arranged to perform the various methods and techniques described herein. Of course, the scope of the present invention is not limited to communication devices. Instead, other embodiments may be directed to other types of devices for processing instructions, or to one or more machine-readable media including instructions that, when executed on a computing device, cause the device to perform one or more of the methods and techniques described herein.

[0110] Embodiments can be implemented in code and can be stored on a non - transitory storage medium having instructions stored thereon, the instructions being usable to program a system to execute the instructions. Embodiments can also be implemented in data and can be stored on a non - transitory storage medium that, if used by at least one machine, causes the at least one machine to fabricate at least one integrated circuit to perform one or more operations. Further embodiments can be implemented in a computer - readable storage medium that includes information that, when fabricated into an SoC or other processor, will configure the SoC or other processor to perform one or more operations. The storage medium can include, but is not limited to, any type of disk, including floppy disks, optical disks, solid - state drives (SSDs), CD - ROMs, CD - RW, magneto - optical disks, semiconductor devices such as read - only memories (ROMs), random - access memories (RAMs) such as dynamic random - access memory (DRAM), static random - access memory (SRAM), erasable programmable read - only memory (EPROM), flash memory, electrically erasable programmable read - only memory (EEPROM), magnetic or optical cards, or any other type of medium suitable for storing electronic instructions.

[0111] Although the invention has been described with respect to a limited number of embodiments, those skilled in the art will recognize many modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations that fall within the true spirit and scope of the invention.< / io> < / io> < / io> < / port> < / io> < / io> < / io>

Claims

1. An apparatus for transmitting platform telemetry information, comprising: A controller for coupling between an on-chip system of a platform and an external connector, the controller comprising: A digital converter for digitizing the platform telemetry information of the platform; and A control circuit for receiving commands from a debug test system and directing the digitized platform telemetry information to a destination in response to the commands, wherein, in response to a command having a first interface identifier, the controller transmits the digitized platform telemetry information to the debug test system via a second interconnect coupled between the controller and the external connector.

2. The apparatus according to claim 1, wherein: In response to a command having a first destination identifier, the control circuit causes the digitized platform telemetry information to be directed to the on-chip system; And In response to a command having a second destination identifier, the control circuit causes the digitized platform telemetry information to be directed to the debug test system.

3. The apparatus according to claim 1, wherein, The controller further comprises a general-purpose input / output interface circuit for receiving the digitized platform telemetry information from the digital converter and transmitting the digitized platform telemetry information to the on-chip system via a first interconnect coupled between the controller and the on-chip system.

4. The apparatus according to claim 1, wherein The controller comprises a power management integrated circuit (PMIC) for coupling to the on-chip system via at least one universal serial bus (USB) interconnect and at least one general-purpose input / output interconnect.

5. The device according to claim 4, wherein The command comprises a USB power delivery message.

6. The device according to claim 1, wherein, The controller receives the command via the second interconnect.

7. The apparatus according to claim 1, wherein In response to a command having a second interface identifier, the controller transmits the digitized platform telemetry information to the debug test system via a third interconnect coupled between the controller and the external connector.

8. The apparatus according to claim 1, wherein In response to the command, the controller transmits the digitized platform telemetry information to the on-chip system via a fourth interconnect, wherein the on-chip system then transmits the digitized platform telemetry information to the debug test system via the external connector.

9. The device according to claim 1, wherein, In response to the command, the controller transmits the digitized platform telemetry information to the on-chip system so that at least one core of the on-chip system can process the digitized platform telemetry information, thereby enabling at least some of the digitized platform telemetry information to be displayed on a display.

10. A method for transmitting platform telemetry information, comprising: Receiving, in a controller of a system, a request for platform telemetry information from a requester, the controller being coupled between a processor of the system and an external connector of the system, the system comprising an enclosed chassis platform; Obtaining the platform telemetry information from one or more sensors of the system in the controller; Transmitting the platform telemetry information to a destination in response to a destination identifier associated with the request, the destination comprising one of the processor and a debug test system, the debug test system being coupled to the system via the external connector; Receive a request from the debug test system via a second interconnection coupled between the external connector and the controller; And Send the platform telemetry information to the debug test system via the second interconnection.

11. The method according to claim 10, further comprising performing power control on one or more components of the system at least partially based on the platform telemetry information.

12. The method according to claim 10, further comprising enabling at least some platform telemetry information to be displayed on a display of the system, wherein, The processor provides the at least some platform telemetry information to the display.

13. The method according to claim 10, further comprising: Convert at least some platform telemetry information from an analog format to a digital format in the controller; And Send the at least some platform telemetry information in digital format to the processor via a first interconnection coupled between the controller and the processor, wherein the controller includes a telemetry host.

14. A computer-readable storage medium including computer-readable instructions that, when executed, implement the method according to any one of claims 10 to 13.

15. A system for transmitting platform telemetry information, comprising: A system-on-chip including at least one core, an interconnection system, a first Universal Serial Bus (USB) controller, and a general-purpose input / output interface circuit; A USB connector coupled to the system-on-chip via a first USB interconnection, the USB connector enabling one or more devices to be coupled to the system-on-chip; A controller coupled to the system-on-chip, the controller including: A general-purpose input / output interface circuit; A digital converter for digitizing the platform telemetry information of the system; Control circuitry for receiving commands via the USB connector and directing the digitized platform telemetry information to at least one of the system-on-chip and a device coupled to the USB connector in response to the commands; and A USB selection circuit coupled to a second USB interconnection and a third USB interconnection; A general-purpose input / output interconnection for coupling the general-purpose input / output interface circuit of the system-on-chip to the general-purpose input / output interface circuit of the controller; The first USB interconnection for coupling the system-on-chip to the USB connector; The second USB interconnection for coupling the system-on-chip to the controller; and The third USB interconnection for coupling the controller to the USB connector.

16. The system according to claim 15, wherein, The command includes a USB power delivery message from a debug test system coupled to the USB connector, and wherein the controller receives the USB power delivery message via one or more configuration channel interconnections coupling the controller to the USB connector.

17. The system according to claim 16, wherein In response to the command, the controller sends at least some digitized platform telemetry information to the debug test system via the one or more configuration channel interconnections.

18. The system according to claim 15, wherein, In response to the command, the controller transmits the digitized platform telemetry information to the system-on-chip, enabling the at least one core to process the digitized platform telemetry information, thereby enabling at least some of the digitized platform telemetry information to be displayed on a display of the system.

19. The system according to claim 15, wherein, In response to the command, the controller transmits the digitized platform telemetry information to the system-on-chip, and also in response to the command, the system-on-chip transmits at least a portion of the digitized platform telemetry information to a first device coupled to the USB connector via the first USB interconnect.

20. An apparatus for transmitting platform telemetry information, comprising: a module for receiving, in a control module, a request for platform telemetry information from a requester, the control module being coupled between a processor module of a system and an external connector module of the system, the system including an enclosed chassis platform; a module for obtaining the platform telemetry information from one or more sensors of the system in the control module; a module for transmitting the platform telemetry information to a destination in response to a destination identifier associated with the request, the destination including one of the processor module and a debug test system, the debug test system being coupled to the system via the external connector module; a module for receiving the request from the debug test system via a second interconnect module coupled between the external connector module and the control module; and a module for transmitting the platform telemetry information to the debug test system via the second interconnect module.

21. The apparatus according to claim 20, further comprising a module for performing power control of one or more components of the system based at least in part on the platform telemetry information.

22. The apparatus according to claim 20, further comprising a module for enabling at least some platform telemetry information to be displayed on a display module of the system, wherein, The processor module provides the at least some platform telemetry information to the display module.

23. The apparatus according to claim 20, further comprising: a module for converting at least some platform telemetry information from an analog format to a digital format; and a module for transmitting the at least some platform telemetry information in digital format to the processor module via a first interconnect module coupled between the control module and the processor module.

24. A computer program product comprising computer-readable instructions that, when executed, implement the method according to any one of claims 10 to 13.

Images