Self-guiding starting and control right transfer method and device of power supply system

Abstract

The application discloses a self-guiding starting and control right handover method and device of a power supply system, and belongs to the technical field of power supply systems. The method comprises the following steps: powering on a power brick and loading a starting program, and then judging whether an MCU is in a ready state. When the MCU is not ready, the system enters a self-guiding mode and outputs a voltage for powering on and resetting the MCU. The power brick continues to judge whether the MCU is successfully started, performs a handshake check with the MCU to verify the legality of the MCU after confirming that the starting is successful, and when it is confirmed that the MCU is legal, the control right is handed over to the MCU and a control mode is switched, and then the power brick gradually increases output power. The application can realize reliable cold starting between the power brick and the external MCU without significantly increasing hardware cost and complexity, and ensure output safety and controllable authentication during the starting process.

Description

Technical Field

[0001] This invention relates to the field of power supply technology, and in particular to a method for self-booting and control handover of a power supply system, as well as an apparatus for implementing the method. Background Technology

[0002] In traditional integrated DC-DC power systems, the control MCU (Microcontroller Unit) and the power module reside within the same physical unit. The MCU receives power directly from the input power supply, and the two can start up and work together without an additional communication link. However, as power systems evolve towards higher power density, greater flexibility, and lower cost, distributed power architectures are gradually becoming mainstream. In distributed architectures, to achieve thermal logic separation—physically isolating the heat-generating power stage from the temperature-sensitive control logic—while reducing the complexity and manufacturing cost of a single module, the control MCU is often externalized to the power module, issuing control commands via a communication bus (such as CAN, I²C, etc.). While this architecture offers advantages in heat dissipation optimization and modular design, it also introduces a critical startup challenge: the "cold start paradox." The DC-DC power module requires commands from the external MCU to start up and regulate its output, but the external MCU itself requires the output power from the DC-DC module to complete power-on initialization and software loading. This creates a mutually dependent closed loop during startup, preventing the system from entering its normal operating state.

[0003] To address the aforementioned cold start problem, existing technologies primarily propose three solutions. First, the independent auxiliary power supply solution, which involves configuring an independent auxiliary power module for the external MCU, enabling it to start without relying on the output of the main DC-DC module. While this solution fundamentally solves the power supply dependency problem, it significantly increases the system's hardware cost, size, and complexity, reducing overall integration, making it difficult to implement, especially in space-constrained or cost-sensitive applications. Second, the pre-charging circuit solution, which involves connecting a large-capacity energy storage capacitor in parallel at the output of the DC-DC module, using the stored energy to provide a brief start-up power to the MCU at power-on. However, capacitor capacity is limited by size and cost, and the stored energy is usually insufficient to support the MCU in completing the full initialization process and software loading, especially in systems with long MCU startup processes or numerous peripherals, making reliability difficult to guarantee. Third, the fixed duty cycle startup solution, where the power brick outputs a preset voltage with a fixed and safe duty cycle after power-on, without relying on MCU commands, and then takes over control after the MCU starts up. While this solution is simple to implement and requires no additional hardware, its fixed output parameters make it unable to adapt to different load conditions and input voltage variations. This poses a safety hazard of overload or uncontrolled output in scenarios with fluctuating input voltage or sudden load changes. Furthermore, in fixed duty cycle mode, the power brick lacks a safety authentication mechanism with the controller, making it impossible to verify whether the MCU is in a healthy and controllable state. If the MCU starts abnormally or the communication link fails, the power brick will remain in an uncontrolled output state for an extended period, leading to serious safety risks.

[0004] Therefore, how to achieve reliable cold start between the power brick and the external MCU in a distributed DC-DC power supply architecture without significantly increasing hardware costs and complexity, and ensure output safety and certification controllability during the startup process, is a technical problem that urgently needs to be solved.

[0005] The information disclosed in this background section is intended only to enhance the understanding of the overall background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0006] The purpose of this invention is to provide a self-booting startup and control handover device for a power system, which can achieve reliable cold startup between the power brick and the external MCU without significantly increasing hardware costs and complexity, and ensure output safety and controllable authentication during the startup process.

[0007] To achieve the above objectives, embodiments of the present invention provide a method for self-booting and control handover of a power supply system, wherein the power supply system includes a power brick and an MCU separately disposed from the power brick, and the method includes the following steps:

[0008] The power brick is powered on and the startup program is loaded;

[0009] The power brick determines whether the MCU is in a ready state;

[0010] The power brick enters a self-booting mode when the MCU is not in a ready state, so as to output a voltage to power-on reset the MCU;

[0011] The power brick determines whether the MCU has started successfully.

[0012] After confirming that the MCU has started successfully, the power brick performs a handshake verification with the MCU and determines the legitimacy of the MCU based on the verification result.

[0013] When the power brick confirms that the MCU is valid, it transfers control to the MCU and switches the control mode, and the power brick further gradually increases the output power.

[0014] In one or more embodiments of the present invention, the voltage output by the power brick for power-on reset of the MCU includes:

[0015] In autonomous boot mode, the power brick sets a fixed PWM duty cycle and limits the output current to output a voltage used to power up and reset the MCU.

[0016] In one or more embodiments of the present invention, the MCU power-on reset includes:

[0017] The SBC receives the voltage output from the power brick module and powers on to start.

[0018] After the SBC starts, it outputs voltage to the MCU to power on and reset the MCU.

[0019] In one or more embodiments of the present invention, the power brick determines whether the MCU has started successfully, including

[0020] The power brick determines whether it receives a handshake request from the MCU within a preset time.

[0021] If the power brick receives a handshake request within a preset time, it determines that the MCU has started successfully; if the power brick does not receive a handshake request within a preset time, it determines that the MCU has not started successfully.

[0022] In one or more embodiments of the present invention, after determining that the MCU has failed to start, the power brick performs the following steps:

[0023] a. Power brick triggers SBC reset used to control MCU reset;

[0024] b. The power brick determines whether the MCU has been successfully reset;

[0025] c. After the power brick determines that the MCU has not been successfully reset, it repeats steps a~b.

[0026] d. The power brick determines whether the number of repeated executions exceeds a preset value;

[0027] e. When the power brick determines that the number of repeated executions exceeds a preset value, it enters the fault shutdown mode and shuts down all outputs.

[0028] In one or more embodiments of the present invention, the power brick and the MCU perform a handshake verification, and the legitimacy of the MCU is determined based on the verification result, including:

[0029] The power brick receives a control request sent by the MCU;

[0030] The power brick further generates a random challenge code and sends it to the MCU;

[0031] The power brick further receives the response code generated by the MCU based on the random challenge code;

[0032] The power brick further determines whether the response code matches the expected value;

[0033] The power brick determines that the MCU is valid if the response code matches the expected value, or it determines that the MCU is invalid if the response code does not match the expected value.

[0034] In one or more embodiments of the present invention, transferring control to the MCU and switching control modes includes:

[0035] The power brick sends a handover confirmation signal to the MCU, disables the fixed duty cycle output in the self-boot mode, enables the external command receiving function, and sets up a watchdog to monitor the MCU status.

[0036] The power brick receives and executes control commands sent by the MCU.

[0037] In one or more embodiments of the present invention, the power brick gradually increases the output power, including

[0038] Receive the first control command sent by the MCU, and adjust the output power to a first preset value according to the first control command;

[0039] After a first preset time period, a second control command sent by the MCU is received, and the output power is adjusted to a second preset value according to the second control command, wherein the second preset value is greater than the first preset value;

[0040] After a second preset time period, the system receives a third control command from the MCU and adjusts the output power to the rated value according to the third control command.

[0041] In one or more embodiments of the present invention, the power brick further includes gradually increasing the output power:

[0042] The power brick determines whether it receives a control command from the MCU within a first preset time.

[0043] The power brick triggers an alarm if it does not receive the control command within the first preset time.

[0044] The power brick determines whether it receives a control command sent by the MCU within a second preset time.

[0045] If the power brick does not receive the control command within the second preset time, it enters the autonomous guidance mode.

[0046] In one or more embodiments of the present invention, after receiving a control command, the power brick further determines whether it is within a reasonable range, and if it exceeds the reasonable range, it determines that the command is abnormal and refuses to execute the command.

[0047] The present invention also discloses a self-booting startup and control handover device for a power system, the power system including a power brick and an MCU separately disposed from the power brick, the device including a control module disposed within the power brick, the control module being configured to perform the following steps:

[0048] Power on and load the startup program;

[0049] Determine if the MCU is in a ready state;

[0050] When the MCU is not in a ready state, it enters the self-booting mode to output a voltage used to power-on reset the MCU;

[0051] Determine if the MCU has started successfully;

[0052] After confirming that the MCU has started successfully, a handshake verification is performed with the MCU, and the legitimacy of the MCU is determined based on the verification result;

[0053] Once the MCU is confirmed to be legitimate, control is transferred to the MCU and the control mode is switched to gradually increase the output power.

[0054] Compared with the prior art, (1) the self-booting startup and control handover method of the present invention can solve the problem of cold start paradox. That is, in the present invention, there is no need to configure an additional auxiliary power supply or a complex pre-charging circuit. The power brick itself can independently complete the power supply startup of the external MCU, thereby effectively reducing the device cost and design complexity of the system and improving the system integration.

[0055] (2) The present invention can also achieve a safe and controllable startup process. That is, in the autonomous guidance mode, all parameters output by the power brick (including voltage, current, frequency, etc.) are strictly limited within the preset safety range to ensure that the startup phase will not cause impact on the load. At the same time, identity authentication is achieved through a challenge-response mechanism to ensure that only a legitimate controller can take over the control of the power brick, which has a high degree of security.

[0056] (3) The present invention can also achieve a smooth transition of control, that is, the switching process between autonomous guidance mode and external control mode is smooth and seamless, with no sudden changes or transient overshoots in the output, and does not affect the normal operation of the load. In addition, the gradual power release strategy further ensures the stability of the system in the initial stage of startup, and avoids system instability caused by a sudden increase in power.

[0057] (4) The present invention also has strong fault tolerance capability, that is, when the external MCU fails to start or communication abnormality occurs during operation, the power brick can automatically return to a safe state or actively trigger the output shutdown to put the system in a safe protection state. Attached Figure Description

[0058] Figure 1 This is a schematic diagram of a distributed power supply system structure according to an embodiment of the present invention;

[0059] Figure 2 This is a flowchart of a self-booting startup and control handover method according to an embodiment of the present invention;

[0060] Figure 3 This is a flowchart of self-booting startup and control handover according to an embodiment of the present invention;

[0061] Figure 4 This is a timing diagram of the autonomous guidance mode according to an embodiment of the present invention;

[0062] Figure 5 This is a flowchart of the handshake verification process according to an embodiment of the present invention;

[0063] Figure 6 This is a timing diagram of the switching from autonomous guidance mode to externally controlled mode according to an embodiment of the present invention;

[0064] Figure 7 This is an exception handling flowchart according to an embodiment of the present invention;

[0065] Figure 8 This is a schematic diagram of a power enhancement process according to an embodiment of the present invention;

[0066] Figure 9 This is a schematic diagram of the structure of a self-booting and control handover device according to an embodiment of the present invention. Detailed Implementation

[0067] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings, but it should be understood that the scope of protection of the present invention is not limited to the specific embodiments.

[0068] Unless otherwise expressly stated, throughout the specification and claims, the term "comprising" or its variations such as "including" or "comprises" shall be understood to include the stated elements or components without excluding other elements or other components.

[0069] Combination Figure 1 The diagram shown illustrates the structure of a distributed power system. This power system includes an MCU and power bricks, which are physically separated, such as being mounted on different PCBs. The power brick refers to a standardized, modularly packaged DC-DC power conversion module.

[0070] Furthermore, the self-booting startup and control handover method for a power supply system disclosed in this invention, based on the aforementioned power supply system, introduces a power brick autonomous booting mode and a secure handshake mechanism. This allows the power brick to first establish a safe and stable base output voltage without external MCU intervention, providing the necessary power for startup to the external MCU. After the MCU powers on and successfully completes authentication, system control is then orderly transferred to the MCU. The entire startup process requires no independent auxiliary power module or large-capacity pre-charge capacitor; the power brick itself can independently complete the power supply startup and control handover to the external MCU. While ensuring startup safety and authentication reliability, this significantly reduces the system's hardware cost, size, and complexity, effectively overcoming the cold start paradox in existing technologies.

[0071] Specifically, in combination Figures 2-4 As shown, the self-booting and control transfer method includes the following steps:

[0072] S100, the power brick is powered on and the startup program is loaded;

[0073] Specifically, the embedded logic chip (such as an FPGA, Field-Programmable Gate Array) integrated within the power brick automatically reads the boot program (i.e., the logic configuration file) from the ROM (Read-Only Memory) after the system is powered on, thus enabling the embedded logic chip to boot. By enabling the embedded logic chip to automatically load the boot program upon power-up, it gains autonomous boot capability.

[0074] S200, the power brick determines whether the MCU is in a ready state;

[0075] Specifically, after the embedded logic chip integrated within the power brick powers on, it further detects the status of the external MCU to determine whether it is in a ready state. This ready state includes, but is not limited to, the MCU having completed startup. In practical implementation, the embedded logic chip can detect whether the MCU is in a ready state through methods including, but not limited to, the following: the power brick detects the MCU status through the SBC (System Basis Chip), i.e., the power brick determines whether the MCU is in a ready state through the MCU status monitoring pin of the SBC. Here, the SBC is a highly integrated dedicated chip that integrates power management, communication transceiver, security monitoring, etc.; another example is that the power brick determines whether it has received a message from the MCU via the CAN bus indicating that the MCU is in a ready state, etc. Specific settings can be configured according to actual needs.

[0076] S300, the power brick enters self-boot mode when the MCU is not in a ready state, to output a voltage used to power-on reset the MCU;

[0077] Specifically, when the power brick confirms that the MCU is in a ready state, it does not enter the self-booting mode, but directly outputs the voltage used to power on and reset the MCU.

[0078] When the power brick confirms that the MCU is not in a ready state, it enters the self-booting mode. In self-booting mode, the power brick can independently complete the basic voltage output by setting parameters such as a fixed PWM (Pulse-Width Modulation) duty cycle and limiting the output current. As shown in the figure, after the power brick is powered on, the embedded logic chip starts and enters the self-booting mode when the MCU is not in a ready state. At this time, a PWM duty cycle of 25% can be set, while the current is limited to 5A, ultimately outputting a 12V voltage. This implementation method can complete the basic voltage establishment during the startup phase without complex control logic. Of course, in practical implementation, in self-booting mode, it is optimal to limit the output voltage to the minimum operating voltage limit of the external controller (e.g., 5V ± 5%), set the current limit to 30%-50% of the normal mode, and reduce the switching frequency by 50%.

[0079] It is understood that in other embodiments, open-loop voltage control or open-loop current control can also be used to output a safe startup voltage under no feedback conditions. Both the above alternatives and the fixed duty cycle method can provide stable and reliable startup conditions for subsequent operation before the system feedback loop is established.

[0080] The voltage output from the power brick can be used for the subsequent power-on reset of the MCU. As shown in the figure, the voltage output from the power brick first powers the SBC. After the SBC starts up and stabilizes, it provides the MCU with the corresponding operating voltage (such as 5V). After the MCU completes the power-on reset, it initializes the clock system, communication interface, functional safety (FuSa) state machine, and other core modules in sequence to ensure that it has control capabilities.

[0081] S400, the power brick determines whether the MCU has started successfully;

[0082] Specifically, after the power brick outputs the corresponding voltage to the SBC, the SBC can output the corresponding operating voltage to the MCU to power on and reset the MCU. In some scenarios, the MCU may fail to complete the power-on reset due to various reasons (such as an abnormal external reset circuit), ultimately failing to start successfully. Therefore, the power brick needs to further determine whether the MCU has started successfully to identify any faults. In practice, the power brick can determine whether the MCU has started successfully by detecting whether a handshake request is received within a preset time. When the power brick receives a handshake request within the preset time, such as 5 seconds, it can be determined that the MCU has started successfully, and the subsequent handshake verification process can be further executed. Conversely, when the power brick does not receive a handshake request within the preset time, it can be determined that the MCU has not started successfully, and the MCU reset process can be further executed.

[0083] Furthermore, when the MCU fails to start, the MCU reset process mainly includes the following steps:

[0084] a. The power brick triggers the SBC reset, so that the SBC resets the MCU.

[0085] Specifically, such as Figure 7 As shown, when restarting the MCU, the power brick can send a reset signal to the SBC via GPIO. The SBC then resets the MCU, for example, by controlling the MCU restart and reset via a dedicated RST (Reset) pin. Of course, in other embodiments, when the MCU fails to start, in addition to triggering the SBC reset via GPIO, the eFuse can also be triggered to shut down via GPIO, or the power brick can directly cut off its own input power supply. The specific choice depends on the actual needs.

[0086] b. The power brick determines whether the MCU has been successfully reset. In practice, the power brick can detect the MCU status through the SBC (System Basis Chip) to determine whether the reset was successful.

[0087] c. After the power brick determines that the MCU has not been successfully reset, it repeats steps a~b.

[0088] Since there are various reasons why an MCU reset might fail, and a simple reset cannot resolve the issue if the MCU hardware is damaged, the power brick will trigger an SBC reset again after determining that the MCU reset failed. This will cause the MCU to restart and determine if there is a hardware fault in the MCU.

[0089] d. The power brick determines whether the number of repeated executions exceeds a preset value;

[0090] e. When the power brick determines that the number of repeated executions exceeds a preset value, it enters the fault shutdown mode and shuts down all outputs.

[0091] Specifically, after the MCU is reset several times, the power brick further determines whether the number of repetitions exceeds a preset number, such as 3 times. If the number of repetitions exceeds the preset number, it indicates that restarting the MCU cannot successfully start it. The power brick then enters a fault shutdown mode and shuts down all outputs to avoid hardware damage and other problems.

[0092] S500: After confirming that the MCU has started successfully, the power brick performs a handshake verification with the MCU and determines the legitimacy of the MCU based on the verification result.

[0093] Specifically, such as Figure 5 As shown, after the power brick confirms that the MCU has started successfully, it further performs a handshake verification with the MCU to authenticate its identity and verify the MCU's legitimacy based on the verification result, preventing unauthorized or faulty devices from gaining control. In specific implementation, as shown in the figure, the power brick and MCU perform handshake verification through the following steps:

[0094] First, the MCU sends a control request message to the power brick to start the verification process. As shown in the figure, the MCU sends the control request message to the power brick through the CAN bus.

[0095] Secondly, after the power brick receives the control request message, it generates a random challenge code and sends the challenge code message to the MCU via the CAN bus;

[0096] Secondly, after the MCU receives the challenge code message, it calculates the response code based on the challenge code and sends the response code message to the power brick via the CAN bus. When calculating the response code, the MCU first reads the pre-shared key and calculates the response code using the following formula: Response = HMAC - SHA256(PSK, Challenge || Device ID), where PSK is the pre-shared key, Challenge is the challenge code, and Device ID is the device number where the MCU is located.

[0097] Finally, after receiving the response code, the power brick verifies it to determine the legitimacy of the MCU. During response code verification, the power brick first reads the pre-shared key and calculates the expected value using the following formula: Expected = HMAC - SHA256(PSK, Challenge || Device ID), where PSK is the pre-shared key, Challenge is the challenge code, and Device ID is the device number where the MCU resides. Finally, the calculated expected value is compared with the response code to determine if they are the same. If they are the same, the MCU is legitimate; if they are different, the handshake verification process is repeated. If the handshake verification process is executed more than a preset number of times, such as more than 3 times, the system enters a fault lockout mode.

[0098] In this embodiment, the handshake verification process employs a challenge-response mechanism. Specifically, the party being verified receives a random challenge value sent by the verifier, calculates a response value based on the pre-shared key, and returns it. The verifier then compares the received response value with the expected value to complete identity authentication. In other embodiments, the handshake verification process can also be implemented based on TLS / SSL handshakes of digital certificates, preset password matching, etc., and can be set according to actual needs; this application does not impose any restrictions on this.

[0099] When the S600 power brick confirms that the MCU is valid, it transfers control to the MCU and switches the control mode, and the power brick further gradually increases the output power.

[0100] Specifically, in combination Figures 2-4 as well as Figure 6 As shown, when the power brick confirms the MCU's legitimacy, it transfers control to the MCU, achieving a seamless switch from autonomous boot mode to externally controlled mode, thus avoiding sudden changes in output voltage / current. In practice, during the control transfer, the power brick sends a handover confirmation signal to the MCU to initiate the transfer. The power brick disables the fixed duty cycle output in autonomous boot mode, enables external command reception, and sets a watchdog timer to monitor the MCU's status and prevent system malfunction from causing loss of control. Once the power brick transfers control to the MCU, it enters external control mode, where the MCU can send control commands to the power brick to control the corresponding power output.

[0101] like Figure 8As shown, to avoid damage to components from current surges, the power brick's output power is gradually increased to achieve smooth startup. In specific implementation, in the first stage, the MCU sends control commands to the power brick to control its output power to a first preset value; in the second stage, the MCU sends control commands to control its output power to a second preset value, which is greater than the first preset value; in the third stage, the MCU sends control commands to control its output power to a rated value. The first and second preset values ​​are percentages of the rated value, such as 25% and 50% respectively, and can be set according to actual needs.

[0102] like Figure 7 As shown, when in external control mode, i.e., when the external MCU has control, the power brick also determines whether a control command has been received within a first preset time. If no control command is received within the first preset time, an alarm is triggered. The power brick further determines whether a control command has been received within a second preset time. If no control command is received within the second preset time, it enters autonomous boot mode to proactively switch to a safe output state when the MCU goes offline. Here, the first preset time is, for example, 3 clock cycles, and the second preset time is 10 clock cycles, etc., which can be configured according to actual needs.

[0103] Furthermore, the power brick determines whether each received control command is within a reasonable range. For commands outside the reasonable range, the command is deemed abnormal and execution is rejected, maintaining the current output. In practical implementation, this can be determined by checking if the duty cycle exceeds a preset value; for example, if the duty cycle exceeds 90%, the control command is considered unreasonable.

[0104] The self-booting and control handover method described in this invention can solve the cold start paradox. That is, in this invention, there is no need to configure an additional auxiliary power supply or a complex pre-charging circuit. The power brick itself can independently complete the power supply and startup of the external MCU, thereby effectively reducing the device cost and design complexity of the system and improving the system integration.

[0105] This invention also enables a safe and controllable startup process. In autonomous boot mode, all parameters output by the power brick (including voltage, current, frequency, etc.) are strictly limited within a preset safety range, ensuring that the startup phase does not impact the load. Simultaneously, a challenge-response mechanism is used for authentication, ensuring that only a legitimate controller can take over control of the power brick, thus providing a high level of security.

[0106] This invention also enables a smooth transition of control, meaning the switching process between autonomous guidance mode and external control mode is smooth and seamless, with no sudden changes or transient overshoots in the output, and does not affect the normal operation of the load. Furthermore, the gradual power release strategy further ensures the stability of the system during the initial startup phase, avoiding system instability caused by a sudden increase in power.

[0107] This invention also possesses strong fault tolerance capabilities. Specifically, when the external MCU fails to start or a communication anomaly occurs during operation, the power brick can automatically revert to a safe state or actively trigger output shutdown, placing the system in a safe protected state. This mechanism complies with functional safety standards such as ISO 26262 and is suitable for high-safety-level automotive electronics and industrial control scenarios.

[0108] The present invention also has broad applicability, that is, the above method is applicable to various distributed power architectures, does not depend on specific MCU models or communication protocols, has good versatility and portability, and is easy to promote and apply across different platforms.

[0109] This invention also discloses a self-booting startup and control handover device for a power supply system, capable of realizing the aforementioned self-booting startup and control handover method. This device introduces a power brick autonomous booting mode and a secure handshake mechanism, enabling the power brick to first establish a safe and stable base output voltage without external MCU intervention, providing the necessary power for startup to the external MCU. After the MCU powers on and successfully completes authentication, system control is then orderly transferred to the MCU. The entire startup process requires no independent auxiliary power module or large-capacity pre-charge capacitor; the power brick itself can independently complete the power supply startup and control handover to the external MCU. While ensuring startup safety and authentication reliability, this significantly reduces the system's hardware cost, size, and complexity, effectively overcoming the cold-start paradox in existing technologies.

[0110] Combination Figure 1 and Figure 9 As shown, the power system includes a power brick and an MCU disposed separately from the power brick. Figure 9 As shown, the device includes a control module, which includes, but is not limited to, an embedded logic chip integrated within the power brick. The control module is configured to perform the following steps:

[0111] Power on and load the startup program;

[0112] Determine if the MCU is in a ready state;

[0113] When the MCU is not in a ready state, it enters the self-booting mode to output a voltage used to power-on reset the MCU;

[0114] Determine if the MCU has started successfully;

[0115] After confirming that the MCU has started successfully, a handshake verification is performed with the MCU, and the legitimacy of the MCU is determined based on the verification result;

[0116] Once the MCU is confirmed to be legitimate, control is transferred to the MCU and the control mode is switched to gradually increase the output power.

[0117] For details on how the control module executes each step, please refer to the above; they will not be repeated here.

[0118] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0119] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0120] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0121] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1The steps of the function specified in one or more boxes.

[0122] The foregoing description of specific exemplary embodiments of the invention is for illustrative and explanatory purposes. These descriptions are not intended to limit the invention to the precise forms disclosed, and it will be apparent that many changes and variations can be made in accordance with the foregoing teachings. The exemplary embodiments were chosen and described in order to explain the specific principles of the invention and its practical application, thereby enabling those skilled in the art to implement and utilize various different exemplary embodiments of the invention, as well as various different choices and variations. The scope of the invention is intended to be defined by the claims and their equivalents.

Claims

1. A method for self-booting startup and control handover of a power supply system, characterized in that, The power system includes a power brick and an MCU separately disposed from the power brick, and the method includes the following steps: The power brick is powered on and the startup program is loaded; The power brick determines whether the MCU is in a ready state; The power brick enters a self-booting mode when the MCU is not in a ready state, so as to output a voltage to power-on reset the MCU; The power brick determines whether the MCU has started successfully. After confirming that the MCU has started successfully, the power brick performs a handshake verification with the MCU and determines the legitimacy of the MCU based on the verification result. When the power brick confirms that the MCU is valid, it transfers control to the MCU and switches the control mode, and the power brick further gradually increases the output power.

2. The method as described in claim 1, characterized in that, The voltage output by the power brick for powering up and resetting the MCU includes: In autonomous boot mode, the power brick sets a fixed PWM duty cycle and limits the output current to output a voltage used to power up and reset the MCU.

3. The method as described in claim 1, characterized in that, The MCU power-on reset includes: The SBC receives the voltage output from the power brick module and powers on to start. After the SBC starts, it outputs voltage to the MCU to power on and reset the MCU.

4. The method as described in claim 1, characterized in that, The power brick determines whether the MCU has started successfully, including... The power brick determines whether it receives a handshake request from the MCU within a preset time. If the power brick receives a handshake request within a preset time, it determines that the MCU has started successfully; if the power brick does not receive a handshake request within a preset time, it determines that the MCU has not started successfully.

5. The method as described in claim 4, characterized in that, After determining that the MCU has failed to start, the power brick performs the following steps: a. Power brick triggers SBC reset used to control MCU reset; b. The power brick determines whether the MCU has been successfully reset; c. After the power brick determines that the MCU has not been successfully reset, it repeats steps a~b. d. The power brick determines whether the number of repeated executions exceeds a preset value; e. When the power brick determines that the number of repeated executions exceeds a preset value, it enters the fault shutdown mode and shuts down all outputs.

6. The method as described in claim 1, characterized in that, The power brick and the MCU perform a handshake verification, and the legitimacy of the MCU is determined based on the verification result. The power brick receives a control request sent by the MCU; The power brick further generates a random challenge code and sends it to the MCU; The power brick further receives the response code generated by the MCU based on the random challenge code; The power brick further determines whether the response code matches the expected value; The power brick determines that the MCU is valid if the response code matches the expected value, or it determines that the MCU is invalid if the response code does not match the expected value.

7. The method as described in claim 1, characterized in that, Transferring control to the MCU and switching control modes includes: The power brick sends a handover confirmation signal to the MCU, disables the fixed duty cycle output in the self-boot mode, enables the external command receiving function, and sets up a watchdog to monitor the MCU status. The power brick receives and executes control commands sent by the MCU.

8. The method as described in claim 1, characterized in that, The power brick gradually increases the output power, including: Receive the first control command sent by the MCU, and adjust the output power to a first preset value according to the first control command; After a first preset time period, a second control command sent by the MCU is received, and the output power is adjusted to a second preset value according to the second control command, wherein the second preset value is greater than the first preset value; After a second preset time period, the system receives a third control command from the MCU and adjusts the output power to the rated value according to the third control command.

9. The method as described in claim 1, characterized in that, The power brick's gradual increase in output power also includes: The power brick determines whether it receives a control command from the MCU within a first preset time. The power brick triggers an alarm if it does not receive the control command within the first preset time. The power brick determines whether it receives a control command sent by the MCU within a second preset time. If the power brick does not receive the control command within the second preset time, it enters the autonomous guidance mode.

10. The method as described in claim 9, characterized in that, After receiving a control command, the power brick also determines whether it is within a reasonable range. If it exceeds the reasonable range, it determines that the command is abnormal and refuses to execute the command.

11. A self-booting startup and control handover device for a power supply system, characterized in that, The power system includes a power brick and an MCU separately disposed from the power brick. The device includes a control module disposed within the power brick, the control module being configured to perform the following steps: Power on and load the startup program; Determine if the MCU is in a ready state; When the MCU is not in a ready state, it enters the self-booting mode to output a voltage used to power-on reset the MCU; Determine if the MCU has started successfully; After confirming that the MCU has started successfully, a handshake verification is performed with the MCU, and the legitimacy of the MCU is determined based on the verification result; Once the MCU is confirmed to be legitimate, control is transferred to the MCU and the control mode is switched to gradually increase the output power.

Images