Power transmission method, system and controller

Abstract

Power transfer methods, systems, and controllers are provided. Techniques are described for dynamically sharing system power among charging ports of a multi-port power delivery (PD) system. In one implementation, the multi-port PD system includes a master controller associated with a master device port and one or more slave controllers associated with one or more slave device ports. The master controller determines port connection states for a set of the plurality of ports. The port connection states indicate that a plurality of devices are connected. The master controller determines power requirements for each device. The master controller dynamically allocates system power among each port without relying on a connection order of the devices.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 958,522, filed January 8, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to USB TYPE-C power delivery methods, systems, and controllers. Background Technology

[0004] Various electronic devices (such as smartphones, tablets, laptops, hubs, chargers, adapters, etc.) are configured to transmit power via a Universal Serial Bus (USB) connector according to the USB Power Delivery protocol defined in various revisions of the USB Power Delivery (USB-PD) specification. For example, in some applications, an electronic device can be configured as a power consumer to receive power via the USB connector (e.g., for battery charging), while in other applications, it can be configured as a power provider to supply power to another device connected to it via the USB connector. However, the USB-PD specification allows power providers and power consumers to dynamically negotiate the voltage and current levels they provide. Summary of the Invention

[0005] This disclosure provides a method comprising: a controller determining the port connection status of a plurality of USB ports, the port connection status indicating that a plurality of devices are connected, wherein at least one of the plurality of USB ports is a USB Type-C Power Delivery (USB-C / PD) port; the controller determining the power requirement of each of the plurality of devices; and the controller dynamically distributing system power among each of the plurality of USB ports, independent of the connection order of the plurality of devices.

[0006] This disclosure provides a system comprising: a first USB Type-C Power Delivery (USB-C / PD) port; a second USB port; and a first controller operatively coupled to the first USB-C / PD port and the second USB port, wherein the first controller is configured to: determine a port connection state of the first USB-C / PD port and the second USB port, the port connection state indicating that a first device is connected to the first USB-C / PD port and a second device is connected to the second USB port; determine a first power requirement of the first device and a second power requirement of the second device; and dynamically allocate system power between the first USB-C / PD port and the second USB port, independent of the connection order of the first USB-C / PD port and the second USB port.

[0007] This disclosure provides a USB Type-C Power Delivery (USB-C / PD) controller, comprising: a first terminal coupled to a first USB-C / PD port among a plurality of USB ports of a multiport adapter; a terminal set coupled to a communication interface coupled to at least a second USB-C / PD controller, the second USB-C / PD controller being coupled to a second USB-C / PD port; and processing circuitry coupled to the first terminal and the terminal set, the processing circuitry being configured to: determine a port connection state of the plurality of USB ports, the port connection state indicating that a plurality of devices are connected; determine the power requirement of each of the plurality of devices; and dynamically allocate system power among each of the plurality of USB ports, independent of the connection order of the plurality of devices. Attached Figure Description

[0008] The disclosure is illustrated by way of example rather than limitation in the various figures of the accompanying drawings.

[0009] Figure 1 This is a block diagram of a multiport power delivery (PD) system having a master device port and a slave device port according to one embodiment.

[0010] Figure 2 This is a flowchart of a method for dynamic intelligent power sharing between ports in a multi-port PD system according to one embodiment.

[0011] Figure 3 This is a flowchart of a method for redistributing power among ports in a multi-port PD system according to one embodiment.

[0012] Figure 4 This is a schematic diagram of a finite state machine (FSM) for a slave device controller in a multi-port PD system according to one embodiment.

[0013] Figure 5 This is a schematic diagram of the FSM of the master device controller of a multi-port PD system according to one embodiment.

[0014] Figure 6 This is a schematic diagram of an FSM for handling communication failures between a master device controller and a slave device controller according to one embodiment.

[0015] Figure 7 This is a flowchart of a power sharing initialization method according to one implementation.

[0016] Figure 8 This is a flowchart of a slave device controller operation method according to one embodiment.

[0017] Figure 9 This is a flowchart of a slave device controller command processing method according to one embodiment.

[0018] Figure 10 This is a flowchart of a slave device controller communication fault handling method according to one embodiment.

[0019] Figure 11A This is a block diagram of various multiport power adapters 1100a configured to dynamically and intelligently distribute power between ports using a firmware-based method, according to one embodiment.

[0020] Figure 11B This is an illustration of a multi-port AC power adapter 1100b configured to dynamically and intelligently distribute power using a firmware-based approach, according to one embodiment.

[0021] Figure 12 This is a block diagram illustrating a system of USB devices for USB power delivery according to some embodiments.

[0022] Figure 13 This is a flowchart of a method for dynamically distributing total system power among ports according to one implementation. Detailed Implementation

[0023] The following description sets forth numerous specific details, such as examples of specific systems, components, methods, etc., to provide a good understanding of various implementations of the technology described herein for achieving dynamic and intelligent system power sharing between connected USB-C / PD charging ports. This technology allows for dynamic and intelligent system power sharing without leaving any unallocated system power. USB-C / PD may also be referred to as USB-C / PD. However, it will be apparent to those skilled in the art that at least some implementations can be practiced without these specific details. In other instances, well-known components, elements, or methods are not described in detail or are presented in the form of simple block diagrams to avoid unnecessarily obscuring the technology described herein. Therefore, the specific details set forth below are merely exemplary. Specific implementations may differ from these exemplary details and may still be considered within the spirit and scope of the invention.

[0024] The references to "implementation," "one implementation," "example implementation," "some implementations," and "various implementations" in the specification refer to specific features, structures, steps, operations, or characteristics described in connection with the implementation that are included in at least one implementation of the invention. Furthermore, the phrases "implementation," "one implementation," "example implementation," "some implementations," and "various implementations" appearing in different places in the specification do not necessarily refer to the same implementation.

[0025] The specification includes references to the accompanying drawings, which form part of the detailed description. The drawings illustrate embodiments according to exemplary practices. These embodiments, also referred to herein as “examples,” are described in sufficient detail to enable those skilled in the art to practice embodiments of the claimed subject matter described herein. Embodiments may be combined, other embodiments may be utilized, or structural, logical, and electrical changes may be made without departing from the scope and spirit of the claimed subject matter. It should be understood that the embodiments described herein are not intended to limit the scope of the subject matter, but rather to enable those skilled in the art to practice, make, and / or use the subject matter.

[0026] This document describes various implementations of a technique for enabling intelligent and dynamic system power sharing between connected USB-C / PD charging ports or multi-port USB-C / PD controllers. The technique allows for dynamic and intelligent system power sharing without leaving any unallocated system power. Examples of such electronic devices include, but are not limited to: personal computers (e.g., laptops, notebook computers, etc.), mobile computing devices (e.g., tablets, tablet computers, e-reader devices, etc.), mobile communication devices (e.g., smartphones, mobile phones, personal digital assistants, messaging devices, PDAs, etc.), connectivity and charging devices (e.g., hubs, docking stations, adapters, chargers, etc.), audio / video / data recording and / or playback devices (e.g., cameras, recorders, handheld scanners, monitors, etc.), and other similar electronic devices that can communicate, charge batteries, and / or transfer power using USB connectors (interfaces) (e.g., USB-C, USB-A, Micro-USB, etc.). The embodiments described herein can be used in various types of power adapters, GaN-based power adapters operating at 600 kHz, power adapters with primary or secondary-side controllers, and power adapters operating in, for example, quasi-resonant mode (QR), discontinuous conduction mode (DCM), and continuous conduction mode (CCM). The embodiments described herein can be used in power adapter solutions in conjunction with Type-C PD functionality. Aspects of this disclosure enable power supplies with significantly lower capacities, thereby reducing cost and complexity, while continuing to effectively utilize the maximum charging potential of the underlying USB-C / PD port.

[0027] USB-enabled electronic devices or systems may conform to at least one version of the USB specification. Examples of such USB specifications include, but are not limited to, USB Specification Revision 2.0, USB 3.0, USB 3.1, and / or various supplements (e.g., On-The-Go or OTG), versions, and their errata. The USB specification generally defines the characteristics (e.g., attributes, protocol definitions, service types, bus management, programming interfaces, etc.) of the differential serial bus required for designing and building standard communication systems and peripherals. For example, USB-enabled peripherals are attached to a USB-enabled host device via the host device's USB port to form a USB-enabled system. A USB 2.0 port includes a 5V power supply line (denoted as VBUS), differential data pairs (denoted as D+ or DP, and D- or DN), and a ground line (denoted as GND) for power return. A USB 3.0 port also provides VBUS, D+, D-, and GND lines for backward compatibility with USB 2.0. In addition, to support the faster differential bus (USB SuperSpeed ​​Bus), the USB 3.0 port provides differential pairs for the transmitter data lines (denoted as SSTX+ and SSTX-), differential pairs for the receiver data lines (denoted as SSRX+ and SSRX-), a power line for power supply (denoted as DPWR), and a ground line for power return (denoted as DGND). The USB 3.1 port provides the same wiring as the USB 3.0 port for backward compatibility with USB 2.0 and USB 3.0 communication, but extends the performance of the SuperSpeed ​​Bus through a series of features called Enhanced SuperSpeed.

[0028] The more recent technology used for USB connectors, known as USB Type-C, is defined in various releases and / or versions of the USB Type-C specification. The USB Type-C specification defines Type-C receptacles, Type-C plugs, and Type-C cables that can support USB communication and power delivery via the newer USB power delivery protocols defined in various revisions / versions of the USB-PD specification. Examples of USB Type-C features and requirements may include, but are not limited to: data and other communications according to USB 2.0 and USB 3.0 / 3.1; electromechanical definitions and performance requirements for Type-C cables; electromechanical definitions and performance requirements for Type-C receptacles; electromechanical definitions and performance requirements for Type-C plugs; requirements for Type-C to legacy cable assemblies and adapters; requirements for Type-C-based device detection and interface configuration; and requirements for optimized power delivery for Type-C connectors. According to the USB Type-C specification, Type-C ports provide VBUS, D+, D-, GND, SSTX+, SSTX-, SSRX+, and SSRX- lines. In addition, the Type-C port provides a sideband usage (SBU) line for signal transmission for sideband functions, and a configuration channel (CC) line for discovery, configuration, and management of connections across Type-C cables. The Type-C port can be associated with a Type-C plug and / or a Type-C receptacle. For ease of use, the Type-C plug and receptacle are designed to be reversible, operating regardless of plug-to-receptacle orientation. Therefore, a standard USB Type-C connector, arranged as a standard Type-C plug or socket, provides terminals to the following lines: four VBUS lines, four ground return (GND) lines, two D+ lines (DP1 and DP2), two D- lines (DN1 and DN2), two SSTX+ lines (SSTXP1 and SSTXP2), two SSTX- lines (SSTXN1 and SSTXN2), two SSRX+ lines (SSRXP1 and SSRXP2), two SSRX- lines (SSRXN1 and SSRXN2), two CC lines (CC1 and CC2), and two SBU lines (SBU1 and SBU2), etc.

[0029] Some USB-enabled electronic devices may follow specific revisions and / or versions of the USB-PD specification. The USB-PD specification defines a standard protocol designed to provide more flexible power delivery over a single USB Type-C cable, along with data communication, to enable the maximum functionality of USB-enabled devices. The USB-PD specification also describes the architecture, protocols, power delivery behavior, parameters, and wiring necessary to manage power delivery over USB Type-C cables at up to 100 watts. According to the USB-PD specification, devices with USB Type-C ports (e.g., USB-enabled devices) can negotiate greater current and / or higher or lower voltage over USB Type-C cables compared to what is allowed by older USB specifications (e.g., USB 2.0, USB 3.1, USB Battery Charging Specification versions 1.1 / 1.2, etc.). For example, the USB-PD specification defines the requirements for the power delivery protocol (PD protocol) that can be negotiated between pairs of USB-enabled devices. The PD protocol can specify the power level and direction of power transmission that both devices can adapt to, and can be dynamically renegotiated based on the request of either device and / or in response to various events and conditions—such as power role switching, data role switching, hard reset, power failure, etc. (e.g., without unplugging the device).

[0030] According to the USB-PD specification, electronic devices are typically configured to transfer power to another device via a power path configured on a USB VBUS line. The device providing power is typically referred to as (or includes) a "provider" (or power source), and the device consuming power is typically referred to as (or includes) a "consumer" (or power consumer). The power path typically includes a power switch connected in series on the VBUS line and configured to turn power transfer on and off.

[0031] In one implementation, the USB-PD power supply can be configured to draw power from a direct current (DC) source and may include a DC-DC converter. In other implementations, the USB-PD power supply can be configured to draw power from an AC power adapter or another AC source. Therefore, as part of the AC-DC conversion, some implementations may use large capacitors on the power side of the VBUS line to remove the AC component of the power signal. The switching on and off of the power switch (also known as a power FET) allows for further circuit protection based on current and voltage condition analysis and fault detection.

[0032] In USB-C / PD (also known as USB Type-C / PD) chargers with multiple ports, power-sharing solutions are necessary to match the power budget of each port. Using a lower-capacity power supply that provides lower system power to utilize its full power capacity at each port simultaneously can lead to failure. Furthermore, for a given power supply, it is not possible to increase the capacity of each port without increasing the system power or fuse rating. Some power-sharing technologies are implemented with little or no adaptability and use techniques such as fair sharing, first-come, first-served, and / or limiting the power available to each port. In fair sharing, each port is allocated the same power regardless of the number of connected devices or their power requirements. In first-come, first-served, the first device to connect is allocated power based on its power requirements, and any subsequently connected device may not be able to meet its power needs. By limiting the available power to each port (e.g., limiting it to 15W), power cannot be redistributed among other ports. In each of these technologies, fault detection between ports cannot be transmitted. In another power-sharing technology, an external controller, separate from the USB-C / PD controller coupled to each port, can be used to allocate the power budget. However, this technology may lack a fair sharing mechanism, may not be able to reallocate unused power, and may be limited to sharing power between two ports. Other communication failures between the external controller and the ports may not be detected.

[0033] This document describes various implementations of intelligent and dynamic power-sharing technology between connected USB-C / PD charging ports. The implementations described herein address the challenges mentioned above and others by providing algorithms to sense the power requirements of connected sink devices (if any) and intelligently distribute power among ports, regardless of connection order. By defining the power-sharing master device as the sole power transfer decision-maker and defining one or more power-sharing slave devices that respond to the master device, the implementations reduce form factor and can be seamlessly integrated into existing designs. These implementations facilitate runtime configuration of master and slave roles based on system requirements, enabling a symmetric firmware-based approach without impacting USB data transfer or user experience. The implementations described herein combine mechanisms for detecting failed receive connections and for preventing failed receive connections from affecting other ports, thereby increasing the robustness of the power transfer system. Power-sharing ports are independent, so they can continue to operate even if communication between ports is interrupted. These implementations achieve fair and intelligent reallocation of unused power, recoverability from communication failures, scalability to systems with more than two ports, and compatibility with dynamic power-throttling algorithms.

[0034] While the implementations described herein relate to techniques for enabling intelligent and dynamic power sharing between connected USB-C / PD charging ports, these techniques are not limited to power sharing between USB-C / PD ports. For example, these techniques can be applied to other types of resource allocation where resources are allocated intelligently and dynamically. In another example, the technique can be applied to various other battery charging protocols.

[0035] In one embodiment, a power-sharing master device may include a master device controller associated with a master device port, and a power-sharing slave device may include a slave device controller associated with a slave device port. In another embodiment, a power-sharing master device may include a master device controller and a first set of ports, and a power-sharing slave device may include a slave device controller and a second set of ports. In yet another embodiment, a single master device controller may be associated with a group of two or more ports and may dynamically and intelligently distribute power among the groups of two or more ports.

[0036] A power-sharing master device can track the port connection status of all power-sharing ports (master ports and all slave ports) and send commands to power-sharing slave devices to update the power delivery power (PDP) of their corresponding slave ports, regardless of the connection order from device to power-sharing port. The PDP of a port is a portion of the total system power that a given port is allowed to provide to the receiving device. Power-sharing slave devices trigger necessary PDP changes according to the master device's instructions and notify the master device of their port connection status. The power-sharing master device can send heartbeat messages to power-sharing slave devices, and the power-sharing slave devices can acknowledge heartbeat messages initiated by the master device. When a communication failure is detected with any slave device, the master device can perform necessary power budget reductions. Similarly, slave devices can perform necessary power budget reductions upon detecting a communication failure with the master device.

[0037] Figure 1This is a block diagram of a multiport power delivery system 100 having a master port 102 and a slave port 104 according to one embodiment. The multiport PD system 100 may be a USB-C / PD system. A firmware-based approach enables the sharing of system power between ports of the multiport PD system 100, such as master port 102 and slave port 104. Master port 102 is controlled by master controller 112, which is the sole PDP decision-maker, while slave port 104 is controlled by slave controller 114, which is a PDP responder capable of responding to commands initiated by master controller 112. Master controller 112 is also referred to as load-sharing (LS) master controller 112, and slave controller 114 is also referred to herein as LS slave controller 114. Master controller 112 is configured to obtain the port connection status of slave port 104 from slave controller 114. Master controller 112 is also configured to distribute power fairly and sharedly to all ports. The master controller 112 and slave controller 114 can then perform power redistribution based on the connected ports. It should be noted that master port 102 and slave port 104 can be the same. It should also be noted that master controller 112 and slave controller 114 can be the same, except that master controller 112 is assigned (or otherwise programmed) to operate as a master controller to control slave controller 114 via a firmware-based method, and slave controller 114 is assigned (or otherwise programmed) to operate as a slave controller and respond to master controller 112 via a firmware-based method.

[0038] The multi-port PD system 100 has an input voltage V from the power supply at the input line 106. IN The power supply provides system power (or total system power) to the multi-port PD system 100. Power converter 108 converts the input voltage to a different voltage to supply the master device port 102. Power converter 109 converts the input voltage to a different voltage to supply the slave device port 104. In one embodiment, power converters 108 and 109 can convert the input voltage V... INThe voltage is reduced to a lower level (e.g., referred to as voltage drop). Serial bus 110 couples power converter 108 to LS master controller 112. Serial bus 111 couples power converter 109 to LS slave controller 114. In the described embodiment, the power supplies coupled to power converters 108 and 109 provide system power to be distributed between master port 102 and slave port 104. Field-effect transistor (FET) 122 can be turned on or off to provide power to master port 102. LS master controller 112 provides signals to turn FET 122 on or off. FET 124 can be turned on or off to provide power to slave port 104. LS slave controller 114 provides signals to turn FET 124 on or off. FETs 122 and 124 are coupled to master port 102 and slave port 104 via Vbus line 116.

[0039] In some implementations, the power converter 108 may be a linear DC-DC converter, a switching DC-DC converter, an AC-DC converter, etc. Although in Figure 1 The circuit is shown as a DC-DC converter, but power converter 108 can be implemented as an AC-DC converter or other power converter. FETs 122 and FET 124 can be N-channel FETs, P-channel FETs, etc. Master port 102 and slave port 104 can be USB Type-C ports, micro USB ports, USB Type-A ports, other ports that provide or receive power, etc.

[0040] The LS master controller 112 and the LS slave controller 114 can be configured to communicate via a communication interface 118 for load sharing (or power sharing). The communication interface 118 can operate on the following lines: a unidirectional clock (CLK) line, through which the LS master controller 112 sends a clock signal to the LS slave controller 114; a unidirectional interrupt line, through which the LS slave controller 114 sends an interrupt signal to the LS master controller 112; and a bidirectional data line, through which signals are transmitted between the LS master controller 112 and the LS slave controller 114. The communication interface 118 can be a serial communication interface such as I2C, RS-232, RS-485, or Serial Peripheral Interface (SPI). The LS master controller 112 continuously tracks the connection status of all ports, including its own port (master port 102) and the slave port 104. In one implementation, the LS slave controller 114 notifies the LS master controller 112 of the port connection status of the slave port 104. In another implementation, the LS master controller 112 may query the LS slave controller 114 for the port connection status of the slave port 104. The port connection status may indicate whether the receiving device is attached to or connected to the port. If the receiving device is connected to the port, the port is said to be attached. If no receiving device is connected to the port, the port is said to be detached. The LS master controller 112 may send a command to the LS slave controller 114 to update the PDP of the slave port 104. In response to receiving a command from the LS master controller 112, the LS slave controller 114 triggers a PDP change based on the received command. The receiving device may be any device attached to or connected to the port and consuming power from that port, such as a mobile phone, tablet, laptop, etc.

[0041] In one embodiment, the LS master controller 112 includes a first terminal 134 coupled to a master port 102 and a first set of terminals 136 coupled to a communication interface 118. The LS slave controller 114 includes a second terminal 138 coupled to a slave port 104 and a second set of terminals 140 coupled to the communication interface 118. The LS master controller 112 and the LS slave controller 114 are coupled and communicate via the communication interface 118.

[0042] The commands sent by the LS master device controller 112 depend on the connection states of all ports of the multi-port PD system 100. When all ports of the multi-port PD system 100 are disconnected, the LS master device controller 112 can send a first type of command. When one port of the multi-port PD system 100 is connected, the LS master device controller 112 can send a second type of command. And when more than one port of the multi-port PD system 100 is connected, the LS master device controller 112 can send a third type of command.

[0043] The firmware-based method is configured to allocate the total system power (SP) among N ports without depending on the port attachment order. The total system power can be allocated without leaving any system power unallocated in the total system power. It is noted that although Figure 1 two ports are shown, the multi-port PD system can have a positive integer (N) number of ports, such as three, four, five or more ports. Each port is capable of providing a separate port budget (PB) (also referred to herein as port power). The individual port budget (PB) is less than the system power (SP), e.g., PB < SP. However, the total port power of all ports (N*PB) can be greater than the system power, e.g., N*PB > SP, although the algorithm for dynamic and intelligent power sharing prevents the total output of the multi-port PD system from outputting power greater than SP. When all of the N ports are detached, each of the N ports can be allocated an equal share of the power amount, e.g., SP / N. When one port is attached, the attached port can be allocated PB. The remaining power or unused power of the system is the difference between the system power and the power budget of the connected port (e.g., SP - PB). The remaining detached ports (there are N - 1 of them) can be allocated an equal share of the remaining power amount, e.g., (SP - PB) / (N - 1), where N - 1 represents the number of remaining disconnected powers. When more than one port is connected, SP / N can be initially allocated to each port, and then the unused power is reallocated among the attached ports. If a port selects a power amount less than SP / N, the port can be referred to herein as a DOWN port. If a port selects a power amount of SP / N, the port can be referred to herein as an UP port. A lower PDP is reallocated to the DOWN port, resulting in the remaining power to be reallocated among the UP ports. The remaining power is reallocated to the UP ports in an equal share model.

[0044] The LS master controller 112 can send messages to the LS slave controller 114 to determine whether a communication failure exists between the LS master controller 112 and the LS slave controller 114. In one embodiment, the message is a heartbeat message sent by the LS master controller 112 to the LS slave controller 114 at predetermined intervals. In one embodiment, the predetermined interval can be several seconds and can be programmable. In another embodiment, the message is a heartbeat message sent by the LS master controller 112 to the LS slave controller 114 at different points in time during the operation of the multiport PD system 100. In some embodiments, for example, if there is a temporary communication problem between the LS master controller 112 and the LS slave controller 114, or if there is a permanent communication failure, the heartbeat message may not be sent at predetermined intervals. If the LS slave controller 114 does not receive a heartbeat message within a first threshold time period, a communication failure is determined to exist between the LS slave controller 114 and the LS master controller 112. When the LS slave controller 114 receives a heartbeat message, it sends an acknowledgment or heartbeat acknowledgment to the LS master controller 112. If the LS master controller 112 does not receive a heartbeat acknowledgment within the second threshold time period, a communication failure is determined to exist between the LS master controller 112 and the LS slave controller 114. Once a communication failure is detected, if the previously allocated PDP for master port 102 and slave port 104 is greater than that for fair sharing, the PDP for both master port 102 and slave port 104 is reduced to fair sharing, such as SP / N.

[0045] The LS master controller 112 can determine whether a state change of master port 102 or slave port 104 is valid or invalid. In some implementations, a state change can be considered valid if a user is attaching or disconnecting a receiving device from the multiport PD system 100, if the receiving device no longer needs to draw power, etc. In some implementations, a state change can be considered invalid if the receiving device has an incorrect connection to the multiport PD system 100, if the receiving device malfunctions, etc. In some implementations, when at least one port (master port 102 or slave port 104) has been attached, any subsequent port state change is considered valid if it remains unchanged or stable after a threshold duration (referred to herein as tDebounce). tDebounce is a duration during which a port state change should remain consistent to be considered valid while at least one other port is attached. If the port connection state is inconsistent within the threshold duration, the LS master controller 112 ignores the port connection state change. In some implementations, tDebounce can be a number of milliseconds. Alternatively, tDebounce can be other time quantities. Any power-sharing specific PDP update for master port 102 or slave port 104 occurs only after tDebounce. This allows the multi-port PD system 100 to be recoverable from faulty receiving device connections or disconnections and prevents unnecessary power redistribution to already connected ports in such scenarios.

[0046] Although the multi-port PD system 100 is in Figure 1 The system is shown as having one slave port, but in other embodiments, a multi-port PD system can have a different number of slave ports, such as two, three, four, or other positive integers of N ports. Although the multi-port PD system 100 is shown in... Figure 1 While shown as a single device, a firmware-based approach for intelligent and dynamic power sharing can be implemented across multiple PD devices with a common power source.

[0047] Although the multi-port PD system 100 is in Figure 1 The diagram illustrates a system with a master controller and slave controllers, the master controller having an associated master port and the slave controller having an associated slave port. However, in other embodiments, a multi-port PD system may have only a master controller that controls multiple ports. In such an embodiment, to distribute power among the ports, the master controller sends commands directly to each corresponding port, rather than sending commands to the slave controller.

[0048] Although the multiport PD system 100 is shown as a power provider, in other embodiments, the multiport PD system can be a multiport power consumer. A multiport power consumer can be implemented using a firmware-based approach configured to intelligently and dynamically consume the total system power (SP) distributed across N ports.

[0049] Figure 2 This is a flowchart of a method 200 for dynamic and intelligent power sharing between ports in a multi-port PD system according to one embodiment. Method 200 can be executed by processing logic including hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software, firmware, or a combination thereof. In one embodiment, method 200 can be executed by any processing device described herein. In one embodiment, method 200 is executed via a master device controller, for example... Figure 1 The processing logic of the LS master device controller 112 is used to execute the operation. In one embodiment, the master device controller executes a firmware-based method that performs the following operations. In another embodiment, the master device controller has embedded code or logic and is configured to execute instructions to perform the following operations. When executing a dynamic and intelligent power sharing method, the master device controller enters various operating states.

[0050] Method 200 begins at point A202, representing the previous operating state. In the previous operating state, the master device controller can monitor changes in the port connection state. The port connection state indicates whether a receiving device is connected to the port. A change in the port connection state indicates that a receiving device has connected to or disconnected from the port. After completing the power distribution for the previously determined port connection state change, the master device controller enters the RUNNING state. While monitoring for changes, the master device controller can determine whether a communication error or communication failure has been detected (box 204). The master device controller can send a heartbeat message to all slave device controllers at predetermined regular time intervals tHeartBeat. If a slave device controller does not receive a heartbeat message within the duration tCommunicationFailure, it is determined that there is a communication failure with the master device controller. In one embodiment, the communication failure is caused by a failure of the serial communication interface between the master device controller and the slave device controller. In another embodiment, the communication failure is caused by a failure of either the master device controller or the slave device controller. If a slave device controller receives a heartbeat message within the duration tCommunicationFailure, it sends a heartbeat acknowledgment to the master device controller. If the master controller does not receive a heartbeat acknowledgment from the slave controller within a time period longer than the duration tCommunicationFailure, it determines that there is a communication failure with the slave controller. In one implementation, if a communication failure is detected, the master controller sets the master port's PDP to the fair sharing value SP / N (total system power divided by the total number of ports) if the master port's PDP was previously greater than the fair sharing value, and the slave controller sets the slave port's PDP to the fair sharing value SP / N if the slave port's PDP was previously greater than the fair sharing value (box 206). In another implementation, if a communication failure is detected, the master controller sets the master port's PDP to a value less than the fair sharing value if the master port's PDP was previously greater than the fair sharing value, and the slave controller sets the slave port's PDP to a value less than the fair sharing value if the slave port's PDP was previously greater than the fair sharing value.

[0051] The master device controller can evaluate port connection status (box 208). When the master device controller evaluates port connection status, it is in the DETERMINE_PORT_CONNECT_STATUS state. While in the DETERMINE_PORT_CONNECT_STATUS state, the master device controller determines or evaluates the port connection status of all ports and subsequently determines power distribution based on the port connection status of all ports. Any change in port status will trigger the master device controller to change its state to the DETERMINE_PORT_CONNECT_STATUS state. In one implementation, a port status change occurs when one or more receiving devices connect to or disconnect from any power-shared port, resulting in a port connection status of attached or disconnected, respectively. In another implementation, a port status change occurs when one or more receiving devices have an incorrect connection to a port, at which point the master device controller performs a dejittering method. The master device controller can determine the port connection status as one of three possibilities: all ports are disconnected, one port is attached, or more than one port is attached. Once the master controller determines the port connection status, it enters the DISTRIBUTE_LOAD state. The DISTRIBUTE_LOAD state is the first level of PDP allocation. The power budget is the amount of power the master controller allocates to a port, corresponding to the maximum power that the port is allowed to supply to connected receiving devices. In some cases, receiving devices may request power below the port budget or indicate a higher power demand (requesting or demanding power) (e.g., in cases of capacity mismatch), and the master controller will reconfigure the power budget allocated to each port.

[0052] In the first scenario, the master device controller determines the port connection status with all ports disconnected. The master device controller can enter the DISTRIBUTE_LOAD state and assign ALL PORTS (all ports) to the variable X (box 210). ALL PORTS refers to the total number of ports, so X = N. Then, for any ports in the multi-port PD system without any attached ports, the master device controller checks if the state of any port has changed (box 212). If the state of any port has not changed, this indicates that the multi-port PD system was initialized without any attached ports, and the power budget PB for each port is equal to the PB for each of the other ports. The master device controller can then allocate power equal to a portion of the total system power to each of the X ports (box 214). This portion is equal to the total system power divided by the number of ports, or SP / N. In other implementations, the portion may be equal to a portion of the total system power, and each portion may be a different part of the total system power that, when added together, equals the total system power. In other words, in some cases, the total system power is allocated such that no system power in the total system power is not allocated. In other cases, the total system power is roughly distributed. To allocate power to each port, the master controller can signal the slave controller corresponding to each port, causing the slave controller to update its corresponding port's PDP. The master controller can also update its own corresponding port's PDP. To ensure that each port's PDP has been successfully updated, the master controller exits the DISTRIBUTE_LOAD state and enters either the WAIT_FOR_SLAVE_COMPLETE (waiting for slave completion) state or the WAIT_FOR_MASTER_COMPLETE (waiting for master completion) state. In the WAIT_FOR_SLAVE_COMPLETE state, the master controller has triggered a change to the slave's PDP and must wait for the slave controller to update its corresponding slave port's PDP. When the operation is complete, the slave controller can send a notification to the master controller to indicate completion. In the WAIT_FOR_MASTER_COMPLETE state, the master controller has triggered a change to its own master port's PDP and must wait for the operation to complete. The master controller performs a power processing completion check to verify that the PDPs of all ports have been successfully updated (Box 216). Once the PDPs of all ports have been successfully updated and the master controller has received notification from the slave controller, the master controller exits the WAIT_FOR_SLAVE_COMPLETE and WAIT_FOR_MASTER_COMPLETE states and re-enters the RUNNING state.The master device controller can monitor the status of all ports to determine if there are any changes (e.g., communication failure, port not being attached, etc.) (Box 218). The master device controller can then repeat this process.

[0053] Returning to box 212, when the master device controller is in the DISTRIBUTE_LOAD state, if the master device controller alternatively determines that the state of one or more ports has changed, this indicates the presence of a receiving device attached to one of the ports, and that the receiving device has been disconnected, so that the multi-port PD system no longer has any attached receiving devices. As described in further detail below in the second case, when a receiving device is attached, the port to which it is attached is allocated power PB, while the remaining ports are allocated a portion of the total remaining power equal to (SP-PB) / (N-1), where (SP-PB) / (N-1) is less than PB. In other embodiments, the portion may be equal to a portion of the total remaining system power, and each portion may be a different portion of the total system power, which, when added together, equals the total remaining system power. The master device controller may allocate a first portion of the total system power, SP / N, to each of one or more ports in descending order of power demand (e.g., from high PB to low PB) (box 220). This ensures that the total power allocated to all ports will never exceed the total system power SP. The master controller then exits the DISTRIBUTE_LOAD state and enters the WAIT_FOR_SLAVE_COMPLETE and WAIT_FOR_MASTER_COMPLETE states. The master controller can then perform a power processing completion check (similar to the power processing completion check in box 216) (box 222). Once the master controller determines that power processing is complete and the PDPs of one or more ports have been successfully updated, it exits the WAIT_FOR_SLAVE_COMPLETE and WAIT_FOR_MASTER_COMPLETE states and re-enters the DISTRIBUTE_LOAD state. The master controller assigns the REMAINING PORTS corresponding to ports whose PDPs have not yet been updated to the variable X (box 224). The master controller then executes the steps described in boxes 214, 216, and 218 above.

[0054] It should be noted that in other implementations, the master device controller does not need to allocate the first portion of the total system power (SP / N) to each of one or more ports in descending order of power demand. For example, the master device controller may allocate the first portion to each of one or more ports in a random, sequential, or other order.

[0055] In the second scenario, where the master controller is in the DETERMINE_PORT_CONNECT_STATUS state, upon determining the presence of an attached port (following box 208), the master controller enters the DISTRIBUTE_LOAD state and allocates a second portion of the total system power from high PB to low PB to each attached port (box 226), where the second portion is (SP-PB) / (N-1). The master controller then changes its state to WAIT_FOR_SLAVE_COMPLETE and WAIT_FOR_MASTER_COMPLETE, and can perform a power processing completion check to ensure that the PDP of each unattached port has been successfully updated (box 228). Once the master controller determines that the PDP of each unattached port has been successfully updated, it changes its state to DISTRIBUTE_LOAD and allocates PB of power to the attached port, allowing the attached port to have the maximum power supported by the port (box 230). The master controller can then perform a power processing completion check to ensure that the PDP of the attached port has been successfully updated (box 216). Once the master controller has determined that the PDP of the attached port has been successfully updated, the master port changes its state to RUNNING and monitors the state of all ports to determine if any changes have occurred (box 218).

[0056] In the third case, where the master controller determines during the DETERMINE_PORT_CONNECT_STATUS state that there is more than one attached port (after box 208), the master controller enters the DISTRIBUTE_LOAD state. The master controller can then allocate fair shared power (SP / N) to each port in descending PB order to ensure that the total allocated power never exceeds the total system power SP (box 232). The master controller changes its state to WAIT_FOR_SLAVE_COMPLETE and / or WAIT_FOR_MASTER_COMPLETE and performs a power processing completion check to ensure that the port's PDP has been successfully updated (box 234). The master controller then changes its state to REDISTRIBUTE_UNUSED_LOAD and performs the power redistribution method at point B 236.

[0057] In each of the second and third scenarios, the master controller waits for a threshold time tDebounce before initiating power redistribution, before changing its state from DETERMINE_PORT_CONNECT_STATUS (box 208) to DISTRIBUTE_LOAD (boxes 226 and 232). tDebounce is a time parameter that defines the duration during which a port state change should remain consistent to be considered valid when at least one port is connected. When at least one port is connected, any subsequent port state change can be considered valid if it remains consistent within the threshold time tDebounce. When a state change is considered valid, a power-sharing specific PDP update occurs. This allows the system to be recoverable from poor connection or disconnection of a receiving device to a port and prevents unnecessary power redistribution to already connected ports in such scenarios. The master controller may apply the threshold time tDebounce to check the validity of a port state change before performing any power distribution or redistribution, as ports can be attached or detached at any time during operation.

[0058] Figure 3 This is a flowchart of a method 300 for redistributing power among ports in a multi-port PD system according to one embodiment. Method 300 can be executed by processing logic including hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software, firmware, or a combination thereof. In one embodiment, method 300 can be executed by any processing device described herein. In one embodiment, method 300 is executed by a master device controller, such as... Figure 1 The processing logic of the LS master device controller 112 is used to execute the operation. In one embodiment, the master device controller executes a firmware-based method that performs the following operations. In another embodiment, the master device controller has embedded code or logic and is configured to execute instructions to perform the following operations.

[0059] Method 300 can be implemented when the master device controller determines that there is more than one attachment port and power should be redistributed among the attachment ports. In one embodiment, method 300 is in relation to... Figure 2 At point B236, which is the same as point B236. When implementing a dynamic and intelligent power sharing method, the master device controller enters various operational states.

[0060] At box 302, the master device controller changes its state to REDISTRIBUTE_UNUSED_LOAD. When a receiving device is connected to or attached to a port, the port connection state of that port is attached, and the receiving device requests power RP from that port. The requested power or requested electricity can be configured as a selected power data object (PDO) voltage multiplied by the PDO current, or a selected PDO voltage multiplied by the requested data object (RDO) current. If no receiving device is connected to the port (e.g., if the port is detached), the requested electricity for the corresponding port is zero. The master device controller can define the initial number of DOWN devices as zero and the initial number of UP devices as zero (box 302). UP ports are those whose requested electricity is greater than or equal to a threshold. In one implementation, the threshold is SP / N. In another implementation, the threshold can be chosen as (SP / N)-1 to avoid any decimal conversion issues. The master controller compares the RP of each port with a threshold (box 304) and counts the number of UP ports and DOWN ports (boxes 306-310). In the REDISTRIBUTE_UNUSED_LOAD state, the master controller attempts to reallocate any remaining or unused power load from DOWN ports to UP ports (if any). After counting the number of UP ports and DOWN ports, the master controller can check whether the number of UP ports is zero or the total number of ports N (box 312). If no ports are requested to transfer power greater than or equal to the threshold, the master controller does not need to reallocate power among the ports, and each port maintains a fair power sharing of SP / N. If all ports are requested to transfer power greater than or equal to the threshold, there will be no unused power load to be reallocated by the master controller. If the number of UP ports is zero or N, the master controller does not need to or cannot reallocate power, changes its state to RUNNING, and continues to monitor port state changes (box 314).

[0061] If the number of UP ports is not equal to 0 or N, the master controller remains in the REDISTRIBUTE_UNUSED_LOAD state and continues to reduce the power allocated to DOWN ports and subsequently increase the power allocated to UP ports. The master controller calculates a first value SP / N-DOWN(RP) for each DOWN port and sums each first value to obtain PDOWN(TOTAL) (box 316). The master controller calculates a second value PUP(TOTAL) = (PB-SP / N)*UP(COUNT) for all UP ports (box 318). The master controller calculates a third value as the minimum of the first and second values: REDISTRIBUTE_POWER = MIN(PDOWN(TOTAL), PUP(TOTAL)) (box 320). The master controller then reduces the PDP of each DOWN port by allocating MAX((SP-REDISTRIBUTE_POWER) / N,RP) of power to each DOWN port (box 322), where RP is the requested power for the corresponding DOWN port. Then, the master device controller enters the WAIT_FOR_SLAVE_COMPLETE or WAIT_FOR_MASTER_COMPLETE state to ensure that the PDP value for all DOWN ports has been successfully updated (Box 324).

[0062] Once the PDP values ​​for all DOWN ports have been successfully updated, the master controller returns to the REDISTRIBUTE_UNUSED_LOAD state. The master controller increments the PDP of each UP port by allocating (SP+REDISTRIBUTE_POWER) / N power to each UP port (box 326). The master controller then enters the WAIT_FOR_SLAVE_COMPLETE or WAIT_FOR_MASTER_COMPLETE state to ensure that the PDP values ​​for all UP ports have been successfully updated (box 328). The master controller then changes its state to RUNNING and monitors for port state changes (box 330).

[0063] Figure 4 This is a schematic diagram of a finite state machine (FSM) 400 of a slave device controller in a multi-port PD system according to one embodiment. The FSM 400 can be executed by processing logic including hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software, firmware, or a combination thereof. In one embodiment, the FSM 400 can be executed by any processing device described herein. In one embodiment, the FSM 400 is executed by a slave device controller, for example... Figure 1The LS is executed from the processing logic of the device controller 114. In one embodiment, the device controller executes a firmware-based method that performs operations associated with the following states. In another embodiment, the device controller has embedded code or logic and is configured to execute instructions to perform operations associated with the following states.

[0064] The function of the slave device controller is to respond to the master device controller, for example... Figure 1 The LS master controller 112 receives a command, triggers a PDP change for the slave port associated with the slave controller, and notifies the master controller of the slave port status. The slave controller notifies the master controller of the slave port connection status (e.g., whether the slave port is attached to a receiving device), and notifies the master controller when the PDP change of the slave port is successfully completed. The slave controller receives periodic heartbeat messages from the master controller at predefined rule intervals (tHeartBeat) to check for communication failures. The slave controller sends a heartbeat acknowledgment message to the master controller to confirm receipt of the heartbeat message. If the slave controller does not receive a heartbeat message within a threshold time period (tCommunicationFailure), a communication failure may occur. In the event of a communication failure with the master controller, the slave controller can perform necessary power budget reductions. In one embodiment, when a communication failure occurs, the slave port's PDP is greater than the fair sharing value SP / N, and the slave controller performs necessary power budget reductions by updating the slave port's PDP to the fair sharing value. In another implementation, when a communication failure occurs, the PDP of the slave device port is less than or equal to the fair share value SP / N, and the slave device controller performs the necessary power budget reduction by taking no action.

[0065] During the operation of a multi-port PD system, the slave device controller operates in various states. First, when the multi-port PD system starts, the slave device controller is in the WAIT_FOR_ATTACH state (box 402). The slave device controller remains in the WAIT_FOR_ATTACH state as long as the slave device port is not attached. In the WAIT_FOR_ATTACH state, the slave device controller can receive commands from the master device controller to trigger a PDP change for the slave device port. When the slave device controller updates the PDP of the slave device port and is in the process of changing the PDP, the slave device controller enters the WAIT_FOR_LOAD_CHANGE_COMPLETE state (box 404). When the slave device controller sends a notification to the master device controller that the PDP change for the slave device port was successful, the slave device controller exits the WAIT_FOR_LOAD_CHANGE_COMPLETE state. When the PDP change is complete, the slave device controller returns to the WAIT_FOR_ATTACH state.

[0066] If the receiving device is connected to the slave port, the slave port becomes attached, and the slave controller enters the RUNNING state (box 406), in which it provides power to the receiving device. The slave controller remains in the RUNNING state when attached and when no PDP change is being performed. While in the RUNNING state, the slave controller can receive commands from the master controller to trigger a PDP change on the slave port. When the slave controller updates the PDP of the slave port and while the PDP change is in progress, the slave controller enters the WAIT_FOR_LOAD_CHANGE_COMPLETE state (box 404). When the slave controller sends a notification to the master controller that the PDP change on the slave port was successful, the slave controller exits the WAIT_FOR_LOAD_CHANGE_COMPLETE state. When the PDP change is complete, the slave controller returns to the RUNNING state. If the receiving device disconnects from the slave port, the slave port becomes detached, and the slave controller returns to the WAIT_FOR_ATTACH state (box 402).

[0067] Figure 5 This is a schematic diagram of an FSM500, the master device controller of a multi-port PD system according to one embodiment. The FSM500 can be executed by processing logic including hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software, firmware, or a combination thereof. In one embodiment, the FSM 500 can be executed by any processing device described herein. In one embodiment, the FSM 500 is executed by a master device controller, such as... Figure 1 The processing logic of the LS master device controller 112 is executed. In one embodiment, the master device controller executes a firmware-based method that performs operations associated with the following states. In another embodiment, the master device controller has embedded code or logic and is configured to execute instructions to perform operations associated with the following states. The master device controller may be Figure 1 The LS master device controller 112, and the multi-port PD system can be Figure 1 The multi-port PD system 100. The role of the master device controller is to continuously track the port connection status of each port, including slave ports and master ports. The master device controller can be associated with a master port and determine the port connection status of the master port. The master device controller can determine the port connection status of a slave port by receiving notifications from the corresponding slave device controller. The master device controller sends commands to the slave device controller to update the PDP of the corresponding slave port. When the corresponding PDP has been successfully updated, the master device controller receives a notification or indication from the slave device controller. If necessary, the master device controller can update the PDP of the master port. The master device controller can send periodic heartbeat messages to the slave device controller at predefined rule intervals (tHeartBeat) to monitor for communication failures. If the master device controller does not receive a heartbeat acknowledgment from the slave device controller within a threshold time (tCommunicationFailure), a communication failure with the slave device controller may occur. In the event of a communication failure with the slave device controller, the master device controller can perform necessary power budget reductions. In one implementation, when a communication failure occurs, the PDP of the master device port is greater than the fair sharing value SP / N, and the master device controller performs the necessary power budget reduction by updating the PDP of the master device port to the fair sharing value. In another implementation, when a communication failure occurs, the PDP of the master device port is less than or equal to the fair sharing value SP / N, and the master device controller performs the necessary power budget reduction by taking no action.

[0068] In one implementation, when a receiving device connects to a port or disconnects from a slave device port, causing the port to become attached or detached respectively, the master device controller can determine to redistribute power among the ports. In some cases, such as when the receiving device malfunctions or connects intermittently to a port, the port connection state may change rapidly. If the port connection state changes within a threshold debounce time tDebounce, the master device controller considers it invalid. The threshold debounce time is a time parameter that, when at least one other port has been attached, a change in port connection state should remain consistent within this time parameter to be considered valid.

[0069] During the operation of a multi-port PD system, the master device controller operates in various states. First, when the multi-port PD system starts up, the master device controller is in the DETERMINE_PORT_CONNECT_STATUS state (box 502). See reference... Figure 2 As described in box 208, in the DETERMINE_PORT_CONNECT_STATUS state, the master device controller determines the port connection status of each port, including the master device port and the slave device port. (See reference...) Figure 2 and Figure 3 As described, the master device controller determines how to distribute power between ports based on port connection status.

[0070] When the port connection status of each port is known, the master device controller enters the DISTRIBUTE_LOAD state (box 504). The DISTRIBUTE_LOAD state is the first level of PDP allocation. When the master device controller is in the DISTRIBUTE_LOAD state, it can perform actions such as... Figure 2The actions described in boxes 210, 212, 214, 224, 226, 230, and 232 are as follows: If no attached port exists, the master controller allocates a fair shared PDP of SP / N to each port. If an attached port exists, the master controller first allocates (SP-PB) / (N-1) PDPs to each unattached port, and then allocates PB of PDPs to the attached port. In both cases, the master controller then enters the WAIT_FOR_SLAVE_COMPLETE state and the WAIT_FOR_MASTER_COMPLETE state (boxes 506 and 508), respectively. In some implementations, the master controller may be in both the WAIT_FOR_SLAVE_COMPLETE and WAIT_FOR_MASTER_COMPLETE states simultaneously. In other implementations, the master controller may initially be in the WAIT_FOR_SLAVE_COMPLETE state and subsequently in the WAIT_FOR_MASTER_COMPLETE state, or it may initially be in the WAIT_FOR_MASTER_COMPLETE state and subsequently in the WAIT_FOR_SLAVE_COMPLETE state. In the WAIT_FOR_SLAVE_COMPLETE state, the master controller waits to receive notification from each slave controller that the PDP for the corresponding slave port has been successfully updated. In the WAIT_FOR_MASTER_COMPLETE state, the master controller waits for the PDP for the master port to be successfully updated. When the PDP changes for all ports are complete, the master controller returns to the DISTRIBUTE_LOAD state. When PDP allocation (e.g., load sharing) is completed for the previously determined port connection state, the master controller enters the RUNNING state (box 512). When the master controller is in the RUNNING state, it can perform actions such as... Figure 2 Box 218 and Figure 3 The actions described in boxes 314 and 330. After completing power distribution for each port for the last determined port connection state, the master controller enters the RUNNING state. Any change in the port connection state will trigger the master controller state to DETERMINE_PORT_CONNECT_STATUS (box 502). It should be noted that in typical applications, the master controller spends the most time in the RUNNING state (compared to other states).

[0071] If there are more than one attached port, the master controller assigns a fair shared PDP to each port and enters the REDISTRIBUTE_UNUSED_LOAD state (box 510). While in the REDISTRIBUTE_UNUSED_LOAD state, the master controller can perform actions such as... Figure 3 The actions described in boxes 302, 304, 305, 308, 310, 312, 316, 318, 320, 322, and 328. In the REDISTRIBUTE_UNUSED_LOAD state, the master controller attempts to reallocate power from ports that are not attached or ports with receivers attached with low power requests (DOWN ports) to ports with receivers attached with high power requests (UP ports). The master controller then enters the WAIT_FOR_SLAVE_COMPLETE and WAIT_FOR_MASTER_COMPLETE states (boxes 506 and 508), respectively. When all port PDP changes are complete, the master controller returns to the REDISTRIBUTE_UNUSED_LOAD state. When the PDP reallocation for the previously determined port connection state is complete (e.g., load sharing), the master controller enters the RUNNING state (box 512). While in the RUNNING state, the master controller can perform actions such as... Figure 2 Box 218 and Figure 3 The actions described in boxes 314 and 330. After completing power distribution for each port for the last determined port connection state, the master controller enters the RUNNING state. Any change in port connection state will trigger the master controller state to DETERMINE_PORT_CONNECT_STATUS (box 502). It should be noted that in typical applications, the master controller spends the most time in the RUNNING state (compared to other states).

[0072] Figure 6 This is a schematic diagram 600 of a FSM (Functional Module) for handling communication failures between a master device controller and a slave device controller according to one embodiment. The FSM 600 can be executed by processing logic including hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software, firmware, or a combination thereof. In one embodiment, the FSM 600 can be executed by any processing device described herein. In one embodiment, the FSM 600 is executed by a controller, such as... Figure 1 The processing logic of the LS master device controller 112 is used to execute this. In another embodiment, the FSM 600 is controlled by a controller such as... Figure 1The LS is executed from the processing logic of the device controller 114. In one embodiment, the controller executes a firmware-based method that performs operations associated with the following states. In another embodiment, the controller has embedded code or logic and is configured to execute instructions to perform operations associated with the following states.

[0073] Communication failures can occur at any time, and during any state of the master and slave controllers. The master controller sends periodic heartbeat messages to the slave controller at predefined regular intervals (tHeartBeat) to monitor for communication failures. The slave controller receives the heartbeat messages and may send a heartbeat acknowledgment message to the master controller to confirm receipt. If, within a threshold time period (tCommunicationFailure), the slave controller does not receive a heartbeat message from the master controller, and the master controller does not receive a heartbeat acknowledgment from the slave controller, a communication failure may have occurred between the slave and master controllers. In the event of a communication failure between the master and slave controllers, both the master and slave controllers can perform necessary power budget reductions.

[0074] If, during a communication failure, the PDP of the master port is greater than the fair share value SP / N, the master controller can perform the necessary power budget reduction by updating the PDP of the master port to the fair share value. If, during a communication failure, the PDP of the master port is less than or equal to the fair share value SP / N, the master controller performs the necessary power budget reduction by taking no action. When a necessary power budget reduction occurs, the master controller enters the WAIT_FOR_MASTER_COMPLETE state (box 602) and returns to its previous state when the necessary power budget reduction is complete. The WAIT_FOR_MASTER_COMPLETE state of box 602 can be related to... Figure 5 The WAIT_FOR_MASTER_COMPLETE state of box 508 is the same.

[0075] If, during a communication failure, the PDP of the slave device port is greater than the fair share value SP / N, the slave device controller performs the necessary power budget reduction by updating the PDP of the slave device port to the fair share value. If, during a communication failure, the PDP of the slave device port is less than or equal to the fair share value SP / N, the slave device controller can perform the necessary power budget reduction by taking no action. When a necessary power budget reduction occurs, the slave device controller enters the WAIT_FOR_LOAD_CHANGE_COMPLETE state (box 604) and returns to its previous state when the necessary power budget reduction is complete. The WAIT_FOR_LOAD_CHANGE_COMPLETE state of box 604 can be related to... Figure 4 The WAIT_FOR_LOAD_CHANGE_COMPLETE state is the same as that of box 404.

[0076] Figure 7 This is a flowchart of a power sharing initialization method 700 according to one embodiment. Method 700 can be executed by processing logic including hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software, firmware, or a combination thereof. In one embodiment, method 700 can be executed by any processing device described herein. Method 700 can be implemented to determine the role (e.g., master or slave) of each controller in a multi-port PD system.

[0077] Method 700 begins with processing logic determining a load-sharing role (e.g., master or slave) for each port and its corresponding controller in a multi-port PD system (box 702). In one implementation, each port of the multi-port PD system is associated with a controller, and one controller is assigned the role of master controller, while the remaining controllers are assigned the role of slave controller. In another implementation, each controller of the multi-port PD system may be associated with a group of two or more ports, and one controller is assigned the role of master controller, while the remaining controllers are assigned the role of slave controller. In yet another implementation, the multi-port PD system may have a single controller associated with a group of two or more ports, and this single controller is assigned the role of master controller and configured to distribute power among the groups of two or more ports. In some implementations, the master controller initiates a master FSM, and the master controller communicates with the slave controllers via a communication interface to initiate a slave FSM. Once each port has been assigned a role, system power (SP) and port budget or port power (PB) are configured (box 704). System power is the total power that the multi-port PD system can output. Port power is the maximum power that any given port can provide. At box 706, the processing logic checks whether the controller is a master device controller or a slave device controller.

[0078] If the controller is a slave controller, the processing logic registers a slave firmware routine to receive commands from the master device (box 708). The slave firmware routine can be stored on the slave controller associated with the slave port. Once the processing logic has registered the slave routine, it sends an event to the master controller (box 710). As described herein, the event can be a sub-state within a state. The firmware routine can perform different operations within the state based on the current event value. The event can be a SLAVE FM_READY event to notify the master controller that the slave firmware routine is stored on the slave controller and that the slave controller is ready to communicate with the master controller. In box 712, the processing logic initializes the slave controller in a defined state. The processing logic can initialize the slave controller by sending an event such as EVT_RUNNING and by setting a state. In one implementation, the state is set, for example, to refer to... Figure 4 The described WAIT_FOR_ATTACH. Once the slave device controller is initialized, the processing logic can run the load-sharing slave FSM. In one implementation, the load-sharing slave FSM is... Figure 4 The FSM 400. (See reference...) Figure 8 and Figure 9To describe it in further detail, at point B 716, the slave device controller can respond to commands from the master device controller.

[0079] In box 706, if the processing logic determines that the controller is the master controller, the processing logic can create an event to initialize the master controller by creating the event and setting the state of the master controller (box 718). This event can be an EVT_POLL_SLAVE (polling slave event) event, and the state of the master controller is set, for example, to refer to... Figure 5 The described DETERMINE_PORT_CONNECT_STATUS. Once the master device controller is initialized, the processing logic runs the load-sharing master FSM (block 720). In one implementation, the load-sharing master FSM is Figure 5 The FSM500. At point A 722, the master device controller is operational and can perform actions such as... Figure 2 and Figure 3 The described action. Point A722 can be compared with... Figure 2 Point A 202 is the same.

[0080] Figure 8 This is a flowchart of a method 800 operating according to one embodiment of a slave device controller. Method 800 can be executed by processing logic including hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software, firmware, or a combination thereof. In one embodiment, method 800 can be executed by any processing device described herein. In one embodiment, method 800 is executed by a slave device controller, for example... Figure 1 The LS is executed from the processing logic of the device controller 114. In one embodiment, the device controller executes a firmware-based method that performs the following operations. In another embodiment, the device controller has embedded code or logic and is configured to execute instructions to perform the following operations.

[0081] Return to reference Figure 8 Method 800 begins at point B 802, and it may occur in situations such as... Figure 7 The description refers to the initialization from the device controller. Point B 802 can be... Figure 7 Point B 716. The slave device controller is associated with the slave device port. If the slave device controller is from the master device controller, for example... Figure 1 If the LS master controller 112 receives a command (block 804), it can implement a method at point C 806 to respond to the command. See reference... Figure 9The method at point C is described in further detail. If the slave device controller detects a communication failure (box 808), it can implement a method at point D 810 to handle the communication failure. If the slave device controller does not receive a command from the master device controller and no communication failure is detected, the slave device controller may be in one of three operating states.

[0082] In one implementation, when the slave device port is not attached (no receiving device is connected to the slave device port), the slave device controller is in a first state, WAIT_FOR_ATTACH. In the first state, the slave device controller waits for a receiving device to connect and waits for the slave device port to subsequently become attached. The slave device controller detects a first event (EVT_ENTRY) (box 812). If the first event is EVT_ENTRY, the slave device controller checks whether the slave device port is attached (box 814). If the slave device port is not attached, the slave device controller returns to the previously running state at point B 802. If the slave device port is attached, the slave device controller sends a first notification (ATTACH notification) (box 816) to the master device controller to notify the master device controller that the slave device port is attached. The slave device controller creates a second event (EVT_RUNNING) (box 818) and changes its current state (STATE) to RUNNING.

[0083] Returning to box 812, if the first event is not EVT_ENTRY, the slave device controller can check if the slave device port is detached (box 820). If the slave device port is not detached, the slave device controller can return to the previously running state at point B 802. If the slave device port is detached, the slave device controller can send a second notification (DETACH notification) (box 822) to the master device controller to notify the master device controller that the slave device port is detached. The slave device controller can create a second event (EVT_RUNNING) (box 824).

[0084] In another implementation, when the slave device controller receives a command from the master device controller to update or change the PDP of the slave device port, the slave device controller is in the second state WAIT_FOR_LOAD_CHANGE_COMPLETE. The slave device controller is in the second state while the PDP change of the slave device port is in progress. The slave device controller updates the PDP of the slave device port and then checks whether the PDP change is complete (box 826). If the PDP change is not complete, the slave device controller returns to the previously run state at point B 802. If the PDP change is complete, the slave device controller updates its current state (STATE) to its old state (OLD_STATE) (box 828).

[0085] In another implementation, the slave device controller is in the third state, RUNNING. When the slave device port is attached, the slave device controller is in the third state, and no PDP change has been performed on the slave device port. The slave device controller checks whether the slave device port is detached (box 830). If the slave device port is not detached, the slave device port returns to its previously running state at point B 802. If the slave device port is detached, the slave device controller creates a third event (EVT_ENTRY) and changes its state to the first state (WAIT_FOR_ATTACH) (box 832).

[0086] Figure 9 This is a flowchart of a method 900 for processing commands from a slave device controller according to one embodiment. Method 900 can be executed by processing logic including hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software, firmware, or a combination thereof. In one embodiment, method 900 is executed by a slave device controller, for example... Figure 1 The LS slave device controller 114 executes its processing logic. In one embodiment, the slave device controller executes a firmware-based method that performs the following operations. In another embodiment, the slave device controller has embedded code or logic and is configured to execute instructions to perform the following operations. When the slave device controller receives data from the master device controller, for example... Figure 1 When the LS master device controller 112 receives a command, it can implement method 900.

[0087] When the slave device controller receives a command from the master device controller, method 900 begins at point C 806. Point C 806 and Figure 8 The point C806 is the same. Figure 8 At box 804, the slave device controller determines that it has received a command from the master device controller. At box 902, the slave device controller determines whether the command is the first command (e.g., SET PDP) to change or update the PDP of the slave device port associated with the slave device controller. If the command is the first command to change or update the PDP of the slave device port, the slave device controller sets the PDP change variable (PDP_CHANGE) to true (box 904). The PDP change variable can be a binary value such as true / false, zero / one, etc. The slave device controller updates its old state (OLD_STATE) to its current state (STATE) (box 906). The slave device controller updates its current state (STATE) to WAIT_FOR_LOAD_CHANGE_COMPLETE (box 908). The WAIT_FOR_LOAD_CHANGE_COMPLETE state can be as shown in the reference... Figure 8The second state described. The device controller returns to the previously running state at point B 802.

[0088] At box 902, if the slave device controller determines that the command is not the first command to change or update the PDP of the slave device port, the slave device controller may check whether the command is a second command (e.g., HEARTBEAT) sent by the master device controller to detect a communication failure between the master device controller and the slave device controller (box 910). The second command may be a heartbeat message from the master device controller. If the slave device controller determines that the command is a heartbeat message, the slave device controller stops and starts slave heartbeats (box 912). The slave device heartbeat is sent by the slave device controller to the master device controller to acknowledge receipt of the heartbeat message. The slave device controller returns to its previous operating state at point B 802. In one embodiment, the master device controller sends heartbeat messages at a predefined time interval (tHeartBeat). The time interval may be the duration in seconds for the master device controller to send heartbeat messages. Alternatively, tHeartBeat may be other time quantities. If the slave device controller does not receive a heartbeat message within a threshold time quantity (tCommunicationFailure), the slave device controller determines that there is a communication failure with the master device controller. If the master controller does not receive a heartbeat acknowledgment from the slave controller within a threshold time period, the master controller determines that there is a communication failure with the slave controller. Once a communication failure is detected, if the PDP of each port of the master and slave controllers was previously greater than the fair shared value, both the master and slave controllers may update the PDP of their respective ports to the fair shared value.

[0089] At box 910, if the slave device controller determines that the command is not a heartbeat message from the master device controller, the slave device controller checks whether the command is a third command (e.g., GET_SLAVE_STATUS) sent by the master device controller to obtain the port connection status of the slave device port (box 914). The slave device controller may receive a third command when the master device controller queries the slave device controller for the port connection status of the slave device port. If the slave device controller determines that the command is a third command, the slave device controller notifies the master device controller of the port connection status of the slave device port (box 916). The slave device controller can notify the master device controller of the port connection status by returning the slave device port status. The slave device port status can be ATTACH or DETACH, depending on whether the receiving device is connected to or not connected to the slave device port. In box 914, if the slave device controller determines that the command is not a third command, the slave device controller returns to the previous operating state at point B 802.

[0090] Figure 10 This is a flowchart of a method 1000 for handling communication failures of a slave device controller according to one embodiment. Method 1000 can be executed by processing logic including hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software, firmware, or a combination thereof. In one embodiment, method 1000 can be executed by a slave device controller, for example... Figure 1 The LS slave device controller 114 executes the following. In one embodiment, the slave device controller executes a firmware-based method that performs the following operations. In another embodiment, the slave device controller has embedded code or logic and is configured to execute instructions to perform the following operations. When the slave device controller determines that there is communication between the slave device controller and the master device controller, for example... Figure 1 When there is a communication failure between the LS master device controllers 112, method 1000 can be implemented.

[0091] When the slave device controller determines that a communication failure exists between the slave device controller and the master device controller, method 1000 begins at point D 810. Point D 810 and Figure 8 Point D is the same as point 810. Figure 8 At box 808, the slave device controller determines that a communication failure exists. Once a communication failure is detected, the slave device controller can check whether the PDP of the slave device port associated with the slave device controller is greater than the fair shared PDP value (box 1002). The fair shared PDP value is equal to the total system power (SP) divided by the total number of ports (N) (e.g., SP / N). The total number of ports includes the master device port and each slave device port. In one embodiment, the total number of ports is two, and the slave device controller checks whether the PDP value of the slave device port is greater than 50% of the total system power. In other embodiments, the total number of ports is more than two, and the slave device controller checks whether the PDP value of the slave device port is greater than SP / N.

[0092] If, in block 1002, the slave device controller determines that the PDP of the slave device port is greater than the fair shared PDP value, then the slave device controller reduces the PDP value to the fair shared PDP value (block 1004). In one embodiment, the total number of ports is two, and the slave device controller reduces the PDP value of the slave device port to 50% of the total power. In other embodiments, the total number of ports is greater than two, and the slave device controller reduces the PDP value of the slave device port to SP / N. In yet another embodiment, the total number of ports is two, and the slave device controller reduces the PDP value of the slave device port to SP / 2. In block 1006, the slave device controller updates its old state (OLD_STATE) to its current state (STATE). The slave device controller updates its current state (STATE) to WAIT_FOR_LOAD_CHANGE_COMPLETE (block 1008). The WAIT_FOR_LOAD_CHANGE_COMPLETE state can be as referenced... Figure 8 The second state is described. The device controller returns to the previous operating state at point B 802. Returning to box 1002, if the device controller determines that the PDP of the device port is less than the fair shared PDP value, the device controller does not take any further action and returns to the previous operating state at point B 802.

[0093] Figure 11A This is a block diagram of various multiport power adapters 1100a configured to dynamically and intelligently distribute power between ports using a firmware-based method, according to one embodiment. As indicated by similar reference numerals, the multiport power adapter 1100a may be similar to... Figure 1A multi-port PD system 100. A multi-port power adapter 1100a includes a master device port 102 and one or more slave device ports 104. The master device port 102 can be controlled by a master device controller 112. The slave device ports 104 can be controlled by corresponding slave device controllers 114. A power converter 108 converts the input voltage to a different voltage. In the described embodiment, the power converter 108 is a DC-DC power converter. In one embodiment, the multi-port power adapter 1100a is a multi-port USB-C rear-seat car charger. In another embodiment, the multi-port power adapter 1100a is part of a rear-seat entertainment system of a car. The rear-seat entertainment system may include an on-chip display system (SoC), and one or more displays or other power-consuming devices may be connected to the display system SoC. In another embodiment, the multi-port power adapter 1100a is part of the main control unit of a car. The main control unit of the car may include a USB hub, and power-consuming devices may be connected to the USB hub. The power-consuming device can consume power from the same source as both the master port 102 and the slave port 104, or it can consume power from different sources. When the power-consuming device consumes power from the same source as both the master port 102 and the slave port 104, a firmware-based approach can dynamically and intelligently distribute power among the master port 102, the slave port 104, and each of the power-consuming devices.

[0094] In other embodiments, the multi-port power adapter 1100a may be part of a multi-port USB-C charger in a vehicle, car, truck, van, ship, aircraft, building, house, etc. In other embodiments, the multi-port power adapter 1100a may be a multi-port USB-C wall charger, a multi-port USB-C power bank, a multi-port USB-C power hub, a shared multi-port power adapter, etc. In other embodiments, the multi-port power adapter 1100a may use ports other than USB-C ports and may be a multi-port wall charger, a multi-port power hub, a multi-port power bank, etc. In other embodiments, the multi-port power adapter 1100a may use ports other than USB-C, such as wall sockets, micro USB ports, etc. In some embodiments, the ports of the multi-port USB-C power adapter 1100a may not be entirely identical. For example, the multi-port USB-C power adapter may include multiple USB Type-C ports and multiple other ports such as USB-A, micro USB, and USB-A 3.0 ports.

[0095] The firmware-based approach can be implemented using a multi-port power adapter 1100a to dynamically share total system power among connected USB-C / PD charging ports or multi-port USB-C / PD controllers by sensing the power demand of connected receiving devices. The multi-port power adapter distributes available power among the ports regardless of the connection order. In some embodiments, the multi-port power adapter 1100a may include additional power receiving devices or power-consuming devices 1150, such as video displays, audio outputs, etc. In some embodiments, the firmware-based approach can be applied to any resource allocation.

[0096] Figure 11B This is an illustration of a multi-port AC power adapter 1100b configured to dynamically and intelligently distribute power using a firmware-based method, according to one embodiment. In one embodiment, the multi-port AC power adapter 1100b may be a wall power adapter including a master device port 102, a slave device port 104, and a power port 1150. The master device port 102 may be controlled by a master device controller (…). Figure 11B (not shown) can be controlled by the slave device controller (and the slave device port 104 can be controlled by the slave device controller). Figure 11B (Not shown) Control. An AC-DC converter (not shown) converts the input AC supply voltage into a DC voltage to be supplied to the master controller and slave controller. In one embodiment, the multi-port AC power adapter 1100b can be configured to perform operations for distributing system power between master port 102 and slave port 104, while each port 1150 can provide a fixed port power. In other embodiments, port 1150 can be configured as a slave port, and the multi-port AC power adapter 1100b can be configured to perform operations for distributing system power between master port 102, slave port 104, and port 1150.

[0097] Despite Figure 11B While shown as a wall adapter, the multiport AC power adapter 1100b can be another type of multiport AC power adapter, for example, that can be found in vehicles, cars, trucks, vans, ships, airplanes, buildings, houses, etc.

[0098] Figure 12This is a block diagram illustrating a system 1200 for use in USB Power Delivery (USB-PD) according to some embodiments. System 1200 may include a peripheral subsystem 1210, which includes multiple components for USB Power Delivery (USB-PD). Peripheral subsystem 1210 may include: a peripheral interconnect 1211 including a clock module, and a peripheral clock (PCLK) 1212 for providing clock signals to the various components of peripheral subsystem 1210. Peripheral interconnect 1211 may be a peripheral bus such as a single-level or multi-level Advanced High-Performance Bus (AHB) and may provide a data and control interface between peripheral subsystem 1210, CPU subsystem 1230, and system resources 1240. Peripheral interconnect 1211 may include controller circuitry such as a Direct Memory Access (DMA) controller, which may be programmed to transfer data between peripheral blocks without input, control, or burden from CPU subsystem 1230.

[0099] Peripheral interconnect 1211 can be used to couple components of peripheral subsystem 1210 to other components of system 1200. Coupled to peripheral interconnect 1211 may be multiple general purpose input / output (GPIO) 1215s for transmitting and receiving signals. GPIO 1215 may include circuitry configured to implement various functions such as pull-up, pull-down, input threshold selection, input and output buffer enable / disable, single multiplexing, etc. GPIO 1215 may also implement other functions. One or more timer / counter / pulse width modulator (TCPWM) 1217s may also be coupled to peripheral interconnects and include circuitry for implementing timing circuitry (timers), counters, pulse width modulator (PWM) decoders, and other digital functions that can operate on I / O signals and provide digital signals to system components of system 1200. The peripheral subsystem 1210 may also include one or more serial communication blocks (SCBs) 1219 for implementing serial communication interfaces such as I2C, Serial Peripheral Interface (SPI), Universal Asynchronous Receiver / Transmitter (UART), Controller Area Network (CAN), Clock Extended Peripheral Interface (CXPI), etc.

[0100] For USB power delivery applications, peripheral subsystem 1210 may include USB power delivery subsystem 1220 which is coupled to a peripheral interconnect and includes a USB-PD module group 1221 for USB power delivery. The USB-PD module 1221 may be coupled to the peripheral interconnect 1211 via USB-PD interconnect 1223. USB-PD module 1221 may include: an analog-to-digital converter (ADC) module for converting various analog signals into digital signals; an error amplifier (AMP) for regulating the output voltage on the VBUS line according to the PD protocol; a high-voltage (HV) regulator for converting the power supply voltage into a precise voltage (e.g., 3.5V to 5V) to power system 1200; a low-side current sensing amplifier (LSCSA) for accurately measuring load current; an overvoltage protection (OVP) module and an overcurrent protection (OCP) module for providing overcurrent and overvoltage protection on the VBUS line with configurable thresholds and response times; one or more gate drivers for external power field-effect transistors (FETs) used in USB power delivery in a supplier and consumer configuration; and a communication channel PHY (CC BB PHY) module for supporting communication on the Type-C communication channel (CC) line. USB-PD module 1221 may also include a charger detection module for determining the presence of charging circuitry and coupled to system 1200, and a VBUS discharge module for controlling voltage discharge on the VBUS line. The discharge control module can be configured to couple to a power node or an output (power receiving) node on the VBUS line and discharge the voltage on the VBUS line to a desired voltage level (i.e., the voltage level negotiated in the PD protocol). The USB power delivery subsystem 1220 may also include a pad 1227 for external connections and electrostatic discharge (ESD) protection circuitry 1229, which may be required on a Type-C port. The USB-PD module 1221 may also include a bidirectional communication module for supporting bidirectional communication with another controller, such as the primary-side controller and secondary-side controller of a flyback converter.

[0101] GPIO 1215, TCPWM 1217, and SCB 1219 can be coupled to input / output (I / O) subsystem 1250, which may include a high-speed (HS) I / O matrix 1251 coupled to multiple GPIOs 1253. GPIO 1215, TCPWM 1217, and SCB 1219 can be coupled to GPIO 1253 via the HS I / O matrix 1251.

[0102] System 1200 may further include a central processing unit (CPU) subsystem 1230 for processing commands, stored program information, and data. CPU subsystem 1230 may include one or more processing units 1231 for executing instructions and reading from and writing to memory locations in a plurality of memories. Processing units 1231 may be processors suitable for operation in integrated circuit (IC) or system-on-chip (SOC) devices. In some embodiments, processing units 1231 may be optimized for low-power operation utilizing a large number of clock-gated parameters. In this embodiment, various internal control circuitry may be implemented for the operation of the processing units under various power states. For example, processing unit 1231 may include a wake-up interrupt controller (WIC) configured to wake the processing unit from a sleep state, thereby allowing power to be cut off when the IC or SOC is in a sleep state. CPU subsystem 1230 may include one or more memories, including flash memory 1233, static random access memory (SRAM) 1235, and read-only memory (ROM) 1237. Flash memory 1233 may be a non-volatile memory (NAND flash, NOR flash, etc.) configured to store data, programs, and / or other firmware instructions. Flash memory 1233 may include a read accelerator and may improve access time by integration within CPU subsystem 1230. SRAM 1235 may be a volatile memory configured to store data and firmware instructions accessible by processing unit 1231. ROM 1237 may be configured to store boot routines, configuration parameters, and other firmware parameters and settings that do not change during operation of system 1200. SRAM 1235 and ROM 1237 may have associated control circuitry. Processing unit 1231 and memory may be coupled to system interconnect 1239 to route signals to and from various components of CPU subsystem 1230 to other blocks or modules of system 1200. System interconnect 1239 may be implemented as a system bus, such as a single-level or multi-level AHB. System interconnect 1239 may be configured as an interface to couple various components of CPU subsystem 1230 to each other. System interconnect 1239 can be coupled to peripheral interconnect 1211 to provide a signal path between components of CPU subsystem 1230 and peripheral subsystem 1210.

[0103] System 1200 may also include multiple system resources 1240, including a power module 1241, a clock module 1243, a reset module 1245, and a test module 1247. Power module 1241 may include a sleep control module, a wake-up interrupt control (WIC) module, a power-on reset (POR) module, multiple voltage references (REF), and a PWRSYS module. In some embodiments, power module 1241 may include circuitry that allows system 1200 to draw power from and / or supply power to external sources at different voltage and / or current levels and supports controller operation in different power states, such as active, low-power, or sleep states. In various embodiments, more power states can be implemented as system 1200 scales down to achieve desired power consumption or output. Clock module 1243 may include a clock control module, a watchdog timer (WDT), an internal low-speed oscillator (ILO), and an internal master oscillator (IMO). Reset module 1245 may include a reset control module and an external reset (XRES) module. Test module 1247 may include modules for controlling and entering test modes, as well as test control modules for analog and digital functions (digital test and analog DFT).

[0104] System 1200 can be implemented in a monolithic (e.g., single) semiconductor die. In other embodiments, various parts or modules of system 1200 can be implemented on different semiconductor dies. For example, the memory module of CPU subsystem 1230 can be on-chip or discrete. In other embodiments, discrete die circuitry can be packaged into a single multi-chip module, or kept discrete and arranged as discrete elements on a circuit board (or in a USB cable connector).

[0105] System 1200 can be implemented in multiple application environments to provide USB-PD functionality. In each application environment, an IC controller or SOC implementing System 1200 can be arranged and configured in an electronic device (e.g., a USB-enabled device) to perform operations according to the techniques described herein. In one example implementation, System 1200 can be arranged and configured in a power adapter for a personal computer (PC) such as a laptop computer, notebook computer, etc. In another example implementation, System 1200 can be arranged and configured in a power adapter (e.g., a wall charger) for a mobile electronic device such as a smartphone, tablet computer, etc. In another example implementation, System 1200 can be arranged and configured in a wall socket configured to provide power via a USB Type-A and / or Type-C port. In another example implementation, System 1200 can be arranged and configured in a car charger configured to provide power via a USB Type-A and / or Type-C port. In yet another example implementation, System 1200 can be arranged and configured in a rechargeable power bank and then provide power to another electronic device via a USB Type-A or Type-C port. In other embodiments, the system, such as system 1200, may be configured with the power switch gate control circuit described herein and may be arranged in various other USB-enabled electronic or electromechanical devices.

[0106] It should be understood that the system 1200, implemented on or as an IC controller, can be deployed in different applications, which may vary depending on the type of power supply used and the direction of power transmission. For example, in the case of a car charger, the power supply is a car battery providing DC power, while in the case of a power adapter, the power supply is an AC wall socket. Furthermore, in the case of a PC power adapter, the power transmission flow is from the power provider device to the power consumer device, while in the case of a power bank, the power transmission flow may be in both directions, depending on whether the power bank operates as a power provider (e.g., supplying power to another device) or as a power consumer (e.g., charging itself). For these reasons, the various applications of system 1200 should be considered in an illustrative rather than limiting sense.

[0107] Figure 13 This is a flowchart of a method 1300 for dynamically distributing total system power among ports according to one embodiment. Method 1300 can be executed by processing logic including hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software, firmware, or a combination thereof. In one embodiment, method 1300 can be executed by any processing device described herein. In one embodiment, method 1300 is executed by a controller, for example... Figure 1The LS master device controller 112 processes the method. In another embodiment, method 1300 is executed by the controller, for example... Figure 1 The processing logic of the LS slave controller 114 is executed. In one embodiment, the controller executes a firmware-based method that performs the following operations. In another embodiment, the controller has embedded code or logic and is configured to execute instructions to perform the following operations. In some embodiments, the operation of method 1300 may be distributed between the master controller and the slave controller.

[0108] Return to reference Figure 13 Method 1300 begins with the processing logic determining the port connection status of each USB-C / PD port in the multi-port PD system (box 1302). The port connection status indicates the number of connected devices. The processing logic determines the power requirements of each device (box 1304). The processing logic dynamically allocates system power among each USB-C / PD port, independent of the device connection order (box 1306), and method 1300 ends.

[0109] In another implementation, to dynamically allocate system power, the processing logic determines a sequence for the devices. The processing logic sequentially allocates a portion of the system power to each USB-C / PD port. This portion is equal to the system power divided by the number of USB-C / PD ports. After allocating the portion to each USB-C / PD port, the processing logic determines the unused power of the system. The processing logic reallocates the unused power to at least one of the USB-Type-C / PD ports. In one implementation, the processing logic reallocates the unused power among ports connected to devices having a power demand (or requested power) greater than the portion allocated to the USB-Type-C / PD ports.

[0110] In one implementation, the order is a descending order of the devices' power requirements. In other implementations, the order can be a random order of the devices, the order in which the devices are connected, or another order.

[0111] In another embodiment, to determine the power requirement of each device, the processing logic determines a first power requirement of a first device connected to a first USB-C / PD port and a second power requirement of a second device connected to a second USB-C / PD port. In one embodiment, the processing logic determines that the second power requirement is less than the first power requirement. The processing logic allocates half of the system power to the first USB-C / PD port and half of the system power to the second USB-C / PD port. The processing logic determines the remaining power as the difference between half of the system power and the second power requirement, and allocates the remaining power to the first USB-C / PD port in addition to the half of the system power already allocated to the first USB-C / PD port. In other embodiments, the processing logic may also allocate a portion of the remaining power to USB-C / PD ports other than the first USB-C / PD port.

[0112] In another implementation, the processing logic determines a change in the port connection state of one or more USB-C / PD ports. In one implementation, a change in port connection state indicates that no device is connected to any USB-C / PD port. In one implementation, the processing logic is initialized when no device is connected to any USB-C / PD port, and in response to the change in port connection state, the processing logic allocates a portion of the system power to each USB-C / PD port. In one implementation, the portion is equal to the system power divided by the number of USB-C / PD ports. Alternatively, the portion may be equal to a portion of the total system power, and each portion may be a different portion of the total system power, which, when added together, equals the total system power. In another implementation, a change in port connection state indicates that a device connected to a USB-C / PD port has been disconnected, and no device is connected to any USB-C / PD port. In response to the change in port connection state, the processing logic allocates a portion of the system power to each USB-C / PD port in order from the port with the highest power budget to the port with the lowest power budget.

[0113] In another implementation, a change in port connection state indicates that only the first device is connected to the first USB-C / PD port. Processing logic allocates a certain amount of system power to the first USB-C / PD port. In one implementation, this certain amount is equal to the first device's first power requirement. In another implementation, this certain amount may be greater than the first device's first power requirement. In yet another implementation, this certain amount may be less than the first device's first power requirement but greater than a fair share portion, which is equal to the system power divided by the number of USB-C / PD ports. Processing logic determines a remaining power equal to the difference between the system power and the certain amount of power allocated to the first USB-C / PD port. In response to a change in port connection state, processing logic allocates a portion of the remaining power to each unconnected USB-C / PD port, this portion being equal to the remaining power divided by the number of unconnected USB-C / PD ports. Alternatively, processing logic allocates a portion of the remaining power. This portion may be equal to a portion of the remaining power, and each portion may be a different part of the total system power, which, when added together, equals the remaining power. In response to a change in port connection status, the processing logic allocates a portion of the remaining power to each USB-C / PD port in order from the port with the highest power budget to the port with the lowest power budget.

[0114] In another implementation, a change in port connection state indicates that a subset of multiple devices are connected to a subset of multiple USB-C / PD ports. The subset of multiple devices is more than one device. Processing logic determines the order of the subsets of multiple devices. The processing logic sequentially allocates a portion of the system power, equal to the system power divided by the number of USB-C / PD ports, to each USB-C / PD port. Alternatively, the processing logic allocates a portion of the system power. This portion may be equal to a portion of the system power, and each portion may be a different portion of the system power, which, when added together, equals the remaining power. After allocating the portion to each USB-C / PD port, the processing logic determines the unused power of the system power. The processing logic reallocates the unused power to at least one of the multiple USB-C / PD ports.

[0115] In one implementation, the order is a descending order of the power demands of a subset of the devices. In other implementations, the order may be a random order of the subsets of devices, the order in which the subsets of devices are connected, or another order.

[0116] In another implementation, the processing logic determines whether the change in port connection state is valid. The processing logic determines whether the change in port connection state remains consistent for a specified duration. If the change in port connection state does not remain consistent for the specified duration, the processing logic ignores the change in port connection state. If the port connection state remains consistent for the specified duration, the processing logic reallocates system power among each USB-C / PD port.

[0117] In another embodiment, the processing logic detects a communication failure between the first controller and the second controller. In one embodiment, the processing logic may be the processing logic of the first controller. In another embodiment, the processing logic may be the processing logic of the second controller. The processing logic performs power budget reduction in response to detecting a communication failure. The processing logic performs power budget reduction by allocating a portion of the system power to a subset of the USB-C / PD ports. The portion is equal to the system power divided by the number of USB-C / PD ports. In one embodiment, the processing logic allocates the portion to each USB-C / PD port. In another embodiment, the processing logic allocates the portion to both the first and second controllers. In one embodiment, if the first controller previously had a power allocation greater than the portion, the processing logic allocates the portion only to the first controller, and if the second controller previously had a power allocation greater than the portion, the processing logic allocates the portion only to the second controller.

[0118] In another embodiment, the processing logic determines the load-sharing role of the controller of the first port coupled to the USB-C / PD port. The load-sharing role can be either a master or a slave device. In one embodiment, the processing logic determines the controller's load-sharing role as a master device. The processing logic polls one or more slave devices via a communication interface and starts the master device's finite state machine. Each of the one or more slave devices is another controller coupled to one of the USB-C / PD ports. In another embodiment, the processing logic determines the controller's load-sharing role as a slave device. The processing logic registers the controller with the master device via a communication interface to receive commands from the master device. The processing logic starts the slave device's finite state machine. The master device is a second controller coupled to the second port.

[0119] In one implementation, when the controller's load-sharing role is that of a slave device, the processing logic determines whether a master device command has been received from the master device. The master device command is at least one of the following: a first command to set the power delivery power (PDP) for a first port coupled to the controller; a second command to start or stop heartbeat signaling between the slave and master devices via the communication interface; or a third command to provide the master device with the port connection status of the first port. The processing logic determines whether a communication failure has occurred between the master and slave devices via the communication interface. If the processing logic determines that a communication failure has occurred, and the slave device's power budget is greater than the fair sharing allocation, the processing logic adjusts the slave device's power budget for the first port to the fair sharing allocation. If the slave device's power budget is less than the fair sharing allocation, the processing logic does not adjust the slave device's power budget. The processing logic monitors changes in the port connection status of the first port, and if the processing logic detects a change in the port connection status of the first port, it reports the change to the master device via the communication interface.

[0120] In another implementation, when the controller's load-sharing role is that of a master device, the processing logic determines whether a communication failure has occurred between the master and slave devices via the communication interface. If the processing logic determines that a communication failure has occurred, and the master device's power budget is greater than the fair sharing allocation, the processing logic adjusts the master device's power budget coupled to the first port of the controller to the fair sharing allocation. If the master device's power budget is less than the fair sharing allocation, the processing logic does not adjust the master device's power budget. In one implementation, the processing logic determines the port connection status of each USB-C / PD port to indicate that more than one USB-C / PD port is connected to multiple devices. The processing logic determines the order of the power demands of the multiple devices and sequentially allocates a first portion (or a first share) of the system power to each USB-C / PD port. The first portion is equal to the system power divided by the number of USB-C / PD ports. After allocating the first portion to each USB-C / PD port, the processing logic reallocates unused system power to one or more USB-C / PD ports, wherein one or more USB-C / PD ports are coupled to one or more devices whose power demands are greater than the first portion. This order may be a descending order of the devices' power demands. Alternatively, the order can be a random order of the devices, the order in which the devices are connected, or another order.

[0121] In another implementation, the processing logic determines the port connection status of each USB-C / PD port to indicate that only the first port is connected to the first device. The processing logic allocates a certain amount of system power to the first port. In one implementation, this amount is equal to the first power requirement of the first device. In another implementation, the amount may be greater than the first power requirement of the first device. In yet another implementation, the amount may be less than the first power requirement of the first device but greater than a fair share, which is equal to the system power divided by the number of USB-C / PD ports. The processing logic determines the order of the power budget for the multiple USB-C / PD ports and allocates a second portion (or second share) of the remaining power to the remaining set of USB-C / PD ports in sequence, the remaining power being the difference between the system power and the first power requirement. The second portion is equal to the remaining power divided by the number in the remaining set. This order may be a descending order of the power requirements of the devices. Alternatively, the order may be a random order of the devices, the order in which the devices are connected, or another order.

[0122] In another implementation, the processing logic determines the port connection status of each USB-C / PD port to indicate that no device is connected to any USB-C / PD port. The processing logic determines the order of power budgets for the USB-C / PD ports and sequentially allocates a first portion of the system power to each USB-C / PD port. This first portion is equal to the system power divided by the number of USB-C / PD ports. This order can be a descending order of the devices' power requirements. Alternatively, the order can be a random order of the devices, the order in which the devices are connected, or another order.

[0123] In the above description, some parts of the specific implementation are presented based on algorithms and symbolic representations of operations on data bits within computer memory. These algorithmic descriptions and representations are means by which those skilled in the art of data processing most effectively communicate the essence of their work to others skilled in the art. Here, an algorithm is generally conceived as a self-consistent sequence of steps that produce a desired result. These steps require physical operations on physical quantities. Although not mandatory, these quantities are usually in the form of electrical or magnetic signals that can be stored, transmitted, combined, compared, and otherwise manipulated. It has been shown that, primarily for general reasons, it is sometimes convenient to refer to these signals as bits, values, elements, symbols, characters, items, numbers, etc.

[0124] However, it should be remembered that all these and similar terms will be associated with appropriate physical quantities and are merely convenient labels applied to those quantities. Unless otherwise stated, it is evident from the above discussion that, throughout the description, the use of terms such as “determine,” “allocate,” “dynamically allocate,” “redistribute,” “ignore,” “reassign,” “detect,” “execute,” “polling,” “register,” “monitor,” etc., refers to the actions and processes of a computing system or similar electronic computing device that manipulate and convert data representing physical (e.g., electronic) quantities in the registers and memories of the computing system into other data representing physical quantities similarly represented in the memory or registers of the computing system or other such information storage, transmission, or display devices.

[0125] The terms “example” or “exemplary” are used herein to mean as an example, instance, or illustration. Any aspect or design described herein as “example” or “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, the use of the terms “example” or “exemplary” is intended to present concepts in a specific manner. As used in this application, the term “or” is intended to mean inclusive “or” rather than exclusive “or.” That is, unless otherwise stated or becomes clear from the context, “X comprises A or B” is intended to mean any natural substitution of inclusion. That is, if X comprises A; X comprises B; or X comprises both A and B, then “X comprises A or B” is satisfied in any of the foregoing cases. Furthermore, unless otherwise stated or clearly indicated from the context, the articles “a” and “an” used in this application and the appended claims should generally be construed as meaning “one or more.” Additionally, the use of the terms “implementation” or “an implementation” or “implementation” or “one embodiment” throughout the document is not intended to mean the same implementation or implementation unless so described.

[0126] The embodiments described herein may also relate to means for performing the operations described herein. Such means may be specifically constructed for a desired purpose, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in a computer. Such a computer program may be stored in a non-transitory computer-readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic cards or optical cards, flash memory, or any type of medium suitable for storing electronic instructions. The term "computer-readable storage medium" should be understood to include a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) storing one or more sets of instructions. The term "computer-readable medium" should also be understood to include any medium capable of storing, encoding, or carrying a set of instructions for machine execution and enabling the machine to perform any one or more methods of this embodiment. Therefore, the term "computer-readable storage medium" should be understood to include, but is not limited to, solid-state memory, optical media, magnetic media, and any medium capable of storing a set of instructions for machine execution and enabling the machine to perform any one or more methods of this embodiment.

[0127] The methods and demonstrations presented herein are not inherently related to any particular computer or other device. Various general-purpose systems can be used with the program based on the teachings herein, or it may prove convenient to construct more specialized devices to perform the required method steps. The necessary structures for various such systems will appear in the description below. Furthermore, this embodiment is described without reference to any particular programming language. It should be understood that the teachings of the embodiments described herein can be implemented using various programming languages.

[0128] The foregoing description sets forth numerous specific details, such as examples of specific systems, components, methods, etc., to provide a good understanding of several embodiments of this disclosure. It should be understood that the foregoing description is intended to be illustrative and not restrictive. Many other embodiments will become apparent to those skilled in the art upon reading and understanding the foregoing description. Therefore, the scope of this disclosure should be determined by reference to the appended claims and the full scope of their equivalents.

Claims

1. A control method, comprising: The controller determines the port connection status of multiple USB ports, which indicates that multiple devices are connected, wherein at least one of the multiple USB ports is a USB Type-C power delivery port; The controller determines the power requirements of each of the plurality of devices; The controller dynamically distributes system power among each of the plurality of USB ports, regardless of the connection order of the plurality of devices; The controller determines the change in the port connection state; In response to the change in the port connection state remaining consistent for a specified duration, the controller redistributes the system power among each of the plurality of USB ports; The controller detects a communication failure between itself and another controller associated with power delivery to one of the plurality of USB ports; and In response to the detection of the communication failure, the controller performs a power budget reduction, wherein performing the power budget reduction includes: reallocating a portion of the system power to each of the plurality of USB ports.

2. The control method according to claim 1, wherein, Dynamically distributing the system power includes: The controller determines the order of power demand from the plurality of devices; and The controller allocates a portion of the system power to each of the plurality of USB ports based on the power demand.

3. The control method according to claim 1, wherein, Dynamically allocating the system power also includes: After allocating a portion of the system power to each of the plurality of USB ports, the controller determines the amount of unused power within the system power; and The controller redistributes the amount of unused power to at least one of the plurality of USB ports.

4. The control method according to claim 1, wherein, Determining the power requirement of each of the plurality of devices includes: Determine the first power requirement of a first device connected to the first USB port of the plurality of USB ports; Determine a second power requirement for a second device connected to a second USB port among the plurality of USB ports, wherein the second power requirement is less than the first power requirement; Distribute half of the system power to the first USB port and half of the system power to the second USB port; The remaining power is determined as the difference between the second power demand and half of the system power; and The remaining power is allocated to the first USB port.

5. The control method according to claim 1, further comprising: The controller determines that the change in the port connection status indicates that no device is connected to the plurality of USB ports; as well as In response to the change in the port connection state, the controller allocates a portion of the system power to each of the plurality of USB ports.

6. The control method according to claim 1, further comprising: The controller determines that the change in the port connection state indicates that only the first device is connected to the first USB port among the plurality of USB ports; The controller allocates a certain amount of system power to the first USB port, and the certain amount is equal to the first power demand of the first device. The controller determines the remaining power relative to the first USB port, the remaining power being equal to the difference between the system power and the first power demand; as well as In response to the change in the port connection state, the controller allocates a portion of the remaining power to each of the plurality of USB ports that is not connected.

7. The control method according to claim 1, further comprising: The controller determines that the change in the port connection state indicates that a subset of the plurality of devices are connected to a subset of the plurality of USB ports, and the subset of the plurality of devices is more than one device; The controller determines the order in which the power requirements of a subset of the plurality of devices are required; The controller allocates a portion of the system power to each of the plurality of USB ports based on the power demand. After allocating a portion of the system power to each of the plurality of USB ports, the controller determines the amount of unused power in the system power; as well as The controller redistributes the amount of unused power to at least one subset of the plurality of USB ports.

8. The control method according to claim 1, further comprising: The controller determines whether the change in the port connection state remains consistent over the specified duration; as well as In response to the port connection state change being inconsistent over the specified duration, the controller ignores the port connection state change.

9. The control method according to claim 1, further comprising: The controller determines the load-sharing role of the controller as a master device or a slave device, and the controller is coupled to the first port among the plurality of USB ports; as well as In response to determining that the load-sharing role of the controller is the master device, the controller polls one or more slave devices via the communication interface and starts the master device finite state machine, each of the one or more slave devices being another controller coupled to one of the plurality of USB ports; or In response to determining that the load-sharing role of the controller is the slave device, the controller registers with the master device through the communication interface to receive commands from the master device and start the slave device finite state machine, wherein the master device is a second controller coupled to the second port of the plurality of USB ports.

10. The control method according to claim 9, further comprising: The slave device determines whether it has received a master device command from the master device, wherein the master device command is at least one of the following: a first command to set the power transmission power of the first port, a second command to start or stop the heartbeat signal transmission between the slave device and the master device through the communication interface, or a third command to provide the port connection status of the first port; The slave device determines whether a communication failure has occurred between the master device and the slave device via the communication interface, and in response to the communication failure, adjusts the slave device power budget on the first port to a fair sharing allocation of the system power, wherein the slave device power budget is greater than the fair sharing allocation; and The slave device monitors changes in the port connection status of the first port and, in response to the changes in the port connection status of the first port, reports the changes to the master device through the communication interface.

11. The control method according to claim 9, further comprising: The master device determines whether a communication failure has occurred between the master device and the slave device through the communication interface, and in response to the communication failure, adjusts the master device power budget of the first port to the fair sharing allocation of the system power, wherein the master device power budget is greater than the fair sharing allocation; as well as i) In response to determining the port connection status, instruct more than one of the plurality of USB ports to be connected to the device. The master device determines the order in which the power requirements of the multiple devices are required; The master device allocates a first portion of the system power to each of the plurality of USB ports based on the power demand. as well as After allocating a first portion of the system power to each of the plurality of USB ports, the host device reallocates an amount of unused power from the system power to one or more of the plurality of USB ports, which are coupled to one or more devices having a power requirement higher than the first portion of the system power. ii) In response to determining the port connection status, instructing only the first port among the plurality of USB ports to be connected to the first device, The master device allocates a certain amount of system power to the first port, and the certain amount is equal to the first power demand of the first device. as well as The master device allocates a second portion of the remaining power to the remaining set of the plurality of USB ports, the remaining power being the difference between the system power and the first power demand; or iii) In response to determining that the port connection status indicates that no device is connected to the plurality of USB ports, the master device distributes the first portion of the system power to each of the plurality of USB ports.

12. A control system, comprising: The first USB Type-C Power Delivery USB-C / PD port; Second USB port; A first controller is operatively coupled to the first USB-C / PD port and the second USB port; Communication interface; as well as A second controller is coupled to the first controller via the communication interface. The second controller is coupled to control the second USB port, and the first controller is coupled to control the first USB-C / PD port. The first controller is configured to: Determine the port connection status of the first USB-C / PD port and the second USB port, wherein the port connection status indicates that the first device is connected to the first USB-C / PD port and the second device is connected to the second USB port; Determine the first power demand of the first device and the second power demand of the second device; System power is dynamically distributed between the first USB-C / PD port and the second USB port, regardless of the connection order of the first USB-C / PD port and the second USB port; Determine the change in the port connection status between the first USB-C / PD port and the second USB port; In response to the change in the port connection state remaining consistent for a specified duration, the system power is redistributed between the first USB-C / PD port and the second USB port; Detecting communication failures between the first controller and the second controller; and In response to the detection of the communication failure, a power budget reduction is implemented. The implementation of the power budget reduction includes: reallocating a portion of the system power to the first USB-C / PD port and the second USB port.

13. The control system according to claim 12, further comprising: A first power converter is coupled to the first controller and a power source that supplies power to the system; A second power converter, coupled to the power source; A first power MOSFET is coupled between the first power converter and the first USB-C / PD port, and the first power MOSFET is controlled by the first controller; as well as A second power MOSFET is coupled between the second power converter and the second USB port, and the second power MOSFET is controlled by the second controller.

14. The control system according to claim 13, wherein, The first power converter is a first DC-to-DC converter of the shared multiport power adapter, wherein the second power converter is a second DC-DC converter of the shared multiport power adapter.

15. The control system according to claim 14, wherein, The shared multi-port power adapter is part of the vehicle's main control unit, the vehicle's rear-seat entertainment system, or the vehicle's rear-seat charger.

16. The control system according to claim 13, wherein, The first power converter is a first AC-DC converter of the shared multiport power adapter, wherein the second power converter is a second AC-DC converter of the shared multiport power adapter, wherein the shared multiport power adapter is part of a multiport wall charger, a multiport power hub, or a multiport power bank.

17. A USB Type-C Power Delivery (USB-C / PD) controller, comprising: The first terminal is coupled to the first USB-C / PD port among the multiple USB ports of the multiport adapter; A terminal set coupled to a communication interface, the communication interface being coupled to at least a second USB-C / PD controller, the second USB-C / PD controller being coupled to a second USB-C / PD port; as well as Processing circuitry, coupled to the first terminal and the terminal set, the processing circuitry being used for: Determine the port connection status of the plurality of USB ports, wherein the port connection status indicates that the plurality of devices are connected; Determine the power requirements of each of the plurality of devices; System power is dynamically distributed among each of the plurality of USB ports, regardless of the connection order of the plurality of devices. Determine the change in the port connection status; In response to the change in the port connection state remaining consistent for a specified duration, the system power is redistributed among each of the plurality of USB ports; Detect communication failures between the USB Type-C Power Delivery USB-C / PD controller and the second USB-C / PD controller; as well as In response to the detection of the communication failure, a power budget reduction is implemented. Specifically, implementing the power budget reduction includes redistributing a portion of the system power to each of the plurality of USB ports.

18. The USB-C / PD controller according to claim 17, wherein, In order to dynamically allocate the system power, the processing circuit is used to: Determine the order of power requirements for the multiple devices; as well as Based on the power demand, a portion of the system power is allocated to each of the plurality of USB ports.

19. The USB-C / PD controller according to claim 18, wherein, In order to dynamically allocate the system power, the processing circuit is also used to: After allocating a portion of the system power to each of the plurality of USB ports, the amount of unused power in the system power is determined; as well as The amount of unused power is redistributed to at least one of the plurality of USB ports.

20. The USB-C / PD controller according to claim 17, wherein, The processing circuit is also used for: The change in the port connection status indicates that no device is connected to the plurality of USB ports; and In response to the change in the port connection state, a portion of the system power is allocated to each of the plurality of USB ports based on the power demand.

21. The USB-C / PD controller according to claim 17, wherein, The processing circuit is also used for: The change in the port connection status indicates that only the first device is connected to the first USB-C / PD port among the plurality of USB ports; Allocate a certain amount of system power equal to the first power demand of the first device; Determine the remaining power, which is the difference between the system power and the first power demand; as well as In response to the change in the port connection status, a portion of the remaining power is allocated to each of the plurality of USB ports that is not connected, based on the power demand.

Images