Enhanced over-the-air programming of power management integrated circuits

Abstract

The subject technology provides for upgrading firmware in a power management integrated circuit (PMIC) of an automotive system using over-the-air (OTA) updates, which is challenging due to limited storage in the PMIC. The automotive system includes a first ECU including a first PMIC and a first processor, and a second ECU including a second PMIC and a second processor. During an OTA update of the second PMIC, the first processor is available as a master device and the second PMIC is available as a slave device. The first processor can initiate the OTA update of the second PMIC and determine that the OTA update is successfully completed. Based on the OTA update being successfully completed, the first processor powers up the second processor and disables a connection between the first processor and the second PMIC to allow the OTA update between the second processor and the first PMIC.

Description

Background Technology

[0001] This application relates to power management systems for electric vehicles, such as enhanced over-the-air programming of power management integrated circuits. Summary of the Invention

[0002] This subject matter technology provides a method for upgrading firmware in the power management integrated circuit (PMIC) of an automotive system using over-the-air (OTA) updates, which is challenging due to the limited storage in the PMIC. This subject matter technology utilizes multiple electronic control units (ECUs) connected via a shared communication bus to orchestrate OTA updates, thereby improving reliability through integrity checks and retries. The OTA process involves sequentially programming the PMIC and managing the power state to prevent system failure. Attached Figure Description

[0003] Certain features of the present subject matter are set forth in the appended claims. However, for purposes of explanation, several embodiments of the present subject matter are illustrated in the following figures.

[0004] Figure 1A A schematic top view illustrating an example embodiment of a vehicle based on one or more specific embodiments is shown.

[0005] Figure 1B A schematic side view illustrating an example embodiment of a vehicle based on one or more specific embodiments is shown.

[0006] Figure 2 An exemplary block diagram of a power management system according to one or more specific implementations is illustrated, the power management system including a power management integrated circuit and a peripheral processor.

[0007] Figure 3 An exemplary block diagram illustrating enhanced over-the-air programming of a power management integrated circuit between interconnected vehicle electronic control units according to one or more specific implementations is shown.

[0008] Figure 4 It is a flowchart illustrating exemplary operations for enhanced over-the-air programming of power management integrated circuits according to one or more specific implementations. Detailed Implementation

[0009] The detailed description set forth below is intended as a description of various configurations of the subject matter and is not intended to represent the only configuration in which the subject matter can be practiced. The accompanying drawings are incorporated herein and form part of the detailed description. The detailed description includes specific details in order to provide a thorough understanding of the subject matter. However, those skilled in the art will clearly understand that the subject matter is not limited to the specific details set forth herein and can be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid confusion with the concepts of the subject matter.

[0010] In the automotive industry, over-the-air (OTA) software updates are increasingly being adopted to upgrade vehicle features throughout their operational lifespan, thereby facilitating the development of software-defined vehicles. These software updates are typically implemented on most processors integrated into various onboard electronic control units (ECUs), which have the ability to reprogram non-volatile storage media that retains their executable images. This allows vehicles to incorporate new features and address software-related issues without requiring physical service center visits or frequent hardware upgrades.

[0011] The power supplies supporting ECU components are becoming increasingly complex, integrating additional functionality related to safety, interior features, vehicle power modes, and wake-up requirements to improve efficiency and range. These power updates are beneficial for maintaining vehicle performance and functionality. Because power management integrated circuits (PMICs) are characterized by relatively small non-volatile memory capacities, traditional OTA update methods cannot be directly applied.

[0012] In one or more specific implementations, the PMIC performs several functions in addition to powering the ECU components. These functions include voltage monitoring of both internal and external rails, temperature monitoring of critical hot spots on the board, processor monitoring via a watchdog timer, secure communication with the processor using cyclic redundancy check, and controlled state transitions in response to processor or PMIC failure by powering off.

[0013] These functionalities may require complex firmware logic implemented within the PMIC, stored in non-volatile memory to allow retrieval during operation. The available non-volatile memory in a PMIC is significantly smaller, measured in kilobytes (KB), compared to the megabytes (MB) of memory used in processors. Due to this limited storage capacity, traditional OTA programming methods cannot rely on redundant memory to mitigate the risk of corruption during firmware updates.

[0014] This technology provides a master processor for monitoring PMIC error responses and initiating retries of the OTA update process until successful completion. As the PMIC integrates more features, the need for a dedicated internal MCU within the system has been greatly reduced, thus preventing the master processor role from being executed within the local ECU. Since vehicles contain multiple ECUs interconnected via a communication bus, utilizing a processor from peripheral processor 220 as the master processor for managing OTA programming presents an efficient approach.

[0015] The technologies described in this paper reduce reliance on additional MCUs, optimize resource utilization within vehicles, and ensure that PMIC firmware remains updated to reflect evolving vehicle characteristics. OTA updates may include support for new vehicle power modes, wake-up requests for efficiency and range improvements, additional monitoring capabilities, and software modifications to address issues identified during field operations.

[0016] Figure 1A An example top view of a vehicle 100 is illustrated. As further described herein, the vehicle 100 may include ECUs (e.g., ECU 160 and ECU 170) in the front portion 130 of the vehicle 100. In one or more embodiments, ECU 150 is operable on a component on a first side of the longitudinal axis of the vehicle 100, while ECU 160 is operable on a component on a second side of the longitudinal axis. The longitudinal axis may be defined as a virtual line extending from the front to the rear of the vehicle 100 along its center, dividing the vehicle 100 into a first (e.g., left) side and a second (e.g., right) side. ECUs (e.g., ECU 150, ECU 160) are embedded systems capable of controlling one or more electrical systems or subsystems within the vehicle 100.

[0017] Figure 1B An example side view of vehicle 100 is illustrated. As shown, vehicle 100 may include one or more battery packs, such as a high-voltage (HV) battery pack 110 (e.g., 450V), which may be located near the central body portion 135 of vehicle 100. The HV battery pack 110 may be coupled to one or more electrical systems of vehicle 100 to supply power to the electrical systems. In one or more embodiments, ECU 150 or ECU 160 may be communicatively connected to each other or have power distributed to each other, and the power or other operation of the electronic components of vehicle 100 may be functionally redundant.

[0018] In one or more embodiments, vehicle 100 may be an electric vehicle having one or more electric motors that use electricity from HV battery pack 110 to drive the wheels 102 of vehicle 100. In one or more embodiments, vehicle 100 may also include or alternatively include one or more chemically powered engines, such as gas-powered engines or fuel cell-powered motors. For example, electric vehicles may be fully electric or partially electric (e.g., hybrid or plug-in hybrid). In various embodiments, vehicle 100 may be a fully automated vehicle capable of operating on roads without a human operator or driver, a partially autonomous vehicle capable of operating on some roads without a human operator or driver or capable of operating on roads under the supervision of a human operator, a driverless vehicle capable of operating on roads or other paths without any human occupants, or a human-operated (non-automatic) vehicle configured for human operation.

[0019] exist Figure 1B In the example, vehicle 100 may be implemented as a truck (e.g., a pickup truck) with battery pack 110. As shown, HV battery pack 110 may include one or more battery modules 115, which may include one or more battery cells 120. However, this is merely illustrative, and in other specific implementations, HV battery pack 110 may be provided without any battery modules 115 (e.g., in a cell-to-pack configuration).

[0020] like Figure 1B As shown, vehicle 100 may include a support structure, such as chassis 125 (e.g., frame, internal frame, or other support structure). Chassis 125 may support various components of vehicle 100. As shown, in some embodiments, chassis 125 may span the front portion 130 (e.g., hood or cover portion), central body portion 135, and rear portion 140 (e.g., luggage compartment, payload, or trunk portion) of vehicle 100. In one or more embodiments, HV battery pack 110 may be mounted on chassis 125 (e.g., within one or more of the front portion 130, central body portion 135, or rear portion 140). In one or more other embodiments, the HV battery pack 110 may include one or more buses (e.g., one or more current collector elements) or be electrically coupled to the one or more buses, wherein the one or more buses may include conductive material to connect or otherwise electrically couple the battery module 115 or battery cell 120 to other electrical components of the vehicle 100 to provide power to various systems or components of the vehicle 100.

[0021] In one or more specific embodiments, vehicle 100 may be implemented as another type of electric truck, electric delivery vehicle, electric motor vehicle, electric car, electric motorcycle, electric scooter, electric bus, electric passenger or commercial truck, hybrid vehicle or other vehicle, such as sea or air transport, aircraft, helicopter, submarine, ship or drone, or any other mobile device having a battery pack 110 (e.g., which powers the propulsion or drive components of the mobile device).

[0022] Automakers are moving towards software-defined vehicles, where vehicle features continue to evolve via software updates even after the vehicle has been sold. Vehicles may undergo software modifications during use, including two years or more after purchase. Over-the-air (OTA) software updates enable upgrades to the programmable hardware within the vehicle. Programmable hardware components allow for software updates via OTA mechanisms. Processors across various vehicle hardware systems can be designed to be upgradeable, with software images stored in dedicated non-volatile memory on each processor's respective circuit board.

[0023] While processors, including traditional central processing units (CPUs), execute advanced software, power management hardware manages the sequencing of power-on processes and performs monitoring functions. These components can contribute to both system efficiency and operational safety. As the complexity of power management devices increases, they may incorporate their own firmware. Firmware can execute on specific hardware components, and due to this increased complexity, non-volatile storage devices can be integrated within the power management hardware to support firmware execution.

[0024] Over-the-air (OTA) updates allow software fixes to be applied remotely without user intervention. This firmware update capability has been extended to PMICs to introduce similar benefits. However, implementing OTA updates for PMICs is challenging due to storage constraints. Traditional non-volatile memory solutions in processors offer memory capacities in the megabyte range, while PMICs typically contain only a few gigabytes of memory. Because of these storage limitations, conventional OTA methods relying on redundant firmware executable images may not be feasible for PMICs.

[0025] In one or more specific implementations, this subject matter provides efficient programming of PMIC firmware to enable OTA updates within the memory constraints of power management hardware. This subject matter also helps achieve firmware upgradability comparable to processor firmware updates, while maintaining reliability standards.

[0026] Figure 2An exemplary block diagram of a power management system 200 according to one or more embodiments is illustrated, the power management system including a PMIC 210 (e.g., PMIC 1), a peripheral processor 220 (e.g., processor 1), a peripheral processor 240, and a power regulator circuit 250. In one or more embodiments, power distribution and system control are managed by the power management integrated circuit (e.g., PMIC 210). A register-mapped memory space is contained within the PMIC 210, containing multiple pages designated for different functionalities. A first page 212 (e.g., page 0 - user registers) is configured to store user-configurable registers. A second page (e.g., page 1 - non-volatile memory control) is used to manage interaction with non-volatile memory. A third page (e.g., page 2 - preconfigurable state machine) contains logic for predefined power states, while a fourth page (e.g., page 3 - watchdog) is implemented to provide watchdog functionality for system reliability. PMIC 210 is integrated with non-volatile memory 230, which receives register-mapped memory space as input to retain critical configuration data. Peripheral processor 220 is coupled to PMIC 210 via a bidirectional communication bus (e.g., I2C) to facilitate data exchange and control signals (e.g., clock). Peripheral processor 240 is coupled to PMIC 210 via a bidirectional communication bus (e.g., I2C) to facilitate data exchange and control signals across the ECU domain. Power regulator circuitry 250 provides voltage regulation and power distribution, receiving power from a renewable source such as battery pack 110 and generating a stable output voltage, including a 5V power regulator supplying 5V output to components requiring higher voltage levels and a 3.3V power regulator providing 3.3V output for logic and low-power circuitry. Both PMIC 210 and peripheral processor 220 receive power from power regulator circuitry 250, with PMIC 210 receiving both 3.3V and 5V inputs. In one or more embodiments, PMIC 210 and peripheral processor 220 belong to the same ECU. In one or more other embodiments, PMIC 210 and peripheral processor 240 belong to different ECUs.

[0027] In one or more embodiments, PMIC 210 performs multiple functions within the automotive system. PMIC 210 can monitor the voltage levels supplied to various components on the printed circuit board (PCB) and perform safety monitoring functions such as temperature tracking and processor status monitoring. PMIC 210 can facilitate secure communication with the processor and manage system stability to prevent cascading failures by shutting down malfunctioning components. In one or more other embodiments, PMIC 210 may be responsible for powering the entire automotive system, acting as the first component to initialize and subsequently distribute power across various voltage rails.

[0028] In traditional power management systems, power management devices operate under the control of a host controller or main processor due to limited onboard intelligence. In one or more other implementations, advancements in PMIC capabilities allow these devices to independently manage control flow. For example, a PMIC can perform sequential operations, monitor system status, and dynamically adapt control flow. This eliminates the need for a host controller previously required for PMIC operation. Given the limited storage capacity of power management devices such as the PMIC 210, efficient firmware upgrade methods are beneficial for promoting robust firmware execution, as failures at this level could disrupt the entire automotive system due to its role as the main power supply.

[0029] In one or more specific implementations, processor OTA updates utilize an A / B redundancy approach. This redundancy approach may involve maintaining two copies of the firmware, where a primary (A) copy is executed by default, and a secondary (B) copy is used as the update target. During the upgrade, copy B is programmed and verified before switching execution from A to B. This approach improves reliability by preventing the system from switching to a corrupted firmware version due to power loss or integrity failure during programming. Execution remains on a stable copy, such as the primary A copy, until verification is complete. While this redundancy may increase storage requirements, the enhanced reliability can be beneficial.

[0030] In PMICs, storage constraints introduce challenges to implementing traditional A / B redundancy methods. Unlike processors that utilize external non-volatile storage devices with configurable capacity, PMIC storage devices are integrated within the IC and pre-determined by the vendor. This can limit flexibility in storage allocation, thus restricting the feasibility of OTA update mechanisms such as traditional A / B redundancy methods. In one or more implementations, traditional A / B redundancy methods used in the processor may not be suitable for PMIC firmware updates because only a single copy of the firmware can exist on the PMIC. During an OTA update, the existing firmware is overwritten, eliminating the ability to revert to a previous operating state in the event of an update failure. To address these limitations, embodiments of the subject matter provide the use of multiple interconnected ECUs. In a vehicle architecture, multiple ECUs can communicate via a dedicated bus. By utilizing these existing communication links, interconnected ECUs can be used to perform the OTA update process, facilitating firmware programming on the PMIC. In one or more other implementations, system reliability can be maintained by utilizing a peripheral processor that continuously verifies the integrity of the OTA update throughout the process.

[0031] In one or more embodiments, a bidirectional communication bus implemented as an I2C interface is selected as the communication protocol due to its ability to function in a master-slave configuration, thereby allowing a single master device to communicate with multiple slave devices. For example, PMIC 210 can operate as a slave device, with peripheral processor 220 acting as the master device. Communication with a particular PMIC can be determined by its unique slave device address. In this example, peripheral processor 220 acts as the master device, engaging with the slave PMIC (e.g., PMIC 210) via an I2C interface, thereby enabling controlled programming and updates across the power management system. In one or more other embodiments, peripheral processor 240 can also act as the master device at different times than peripheral processor 220, engaging with the slave PMIC (e.g., PMIC 210) via an I2C interface.

[0032] Because the I2C interface only supports a single master device, peripheral processor 220 may not directly update its own PMIC (e.g., PMIC 210). This limitation arises because PMIC 210 powers peripheral processor 220. If peripheral processor 220 attempts to update its own PMIC (e.g., PMIC 210) while relying on that PMIC for power, a failure scenario may occur where peripheral processor 220 becomes inactive during the update process. To avoid this problem, control is transferred to peripheral processor 240.

[0033] In one or more embodiments, the memory space of a peripheral processor, such as peripheral processor 240, can be used as a main processor to facilitate OTA programming of the PMIC firmware. Once an OTA update is initiated by peripheral processor 240, peripheral processor 240 can receive the firmware executable image and extract relevant portions of the executable image for PMIC firmware update. The firmware executable image, received as a single packet from a content source over the network, contains updates for both peripheral processors and the PMIC across multiple ECUs. In one or more embodiments, peripheral processor 240 can temporarily store the firmware executable image and perform a verification check before transmitting the firmware executable image to PMIC 210. During this process, integrity checks can be performed to confirm successful data transmission. If power loss or other catastrophic failure occurs during firmware programming, peripheral processor 240, which continuously monitors the integrity of the OTA update on PMIC 210, can detect the failure and initiate one or more retry attempts. Peripheral processor 240 can remain aware of unsuccessful OTA update attempts and can continue to retry until firmware programming is successfully completed on PMIC 210. If an unrecoverable fault prevents the PMIC 210 from being programmed, the peripheral processor 240 can communicate the failure to the wider system, potentially displaying a message on the vehicle dashboard, indicating that a fault has occurred in one of the ECUs.

[0034] During OTA programming, the peripheral processor 240 can store the firmware executable image in its own memory while concurrently writing data to the PMIC 210. When the peripheral processor 240 programs the PMIC 210, it performs integrity checks, including checksum verification and boot signature verification, to determine that the new firmware image has been correctly written and the PMIC 210 has been successfully initialized. The write operation can be verified using Cyclic Redundancy Check (CRC) or an equivalent checksum verification to ensure data integrity. In one or more other implementations, the peripheral processor 240 attempts to boot an updated PMIC (e.g., PMIC 210) and verifies its operational status by checking a predefined signature indicating a successful update. If a failure occurs during the write process, the original firmware copy is interrupted, and the PMIC 210 enters a non-functional state. To recover from this situation, the peripheral processor 240 initiates a retry mechanism to retry the OTA update until a successful firmware installation is achieved.

[0035] The retry mechanism may include a programmable timeout threshold, which defines the number of retries allowed before a critical hardware problem is determined. If consecutive retries fail, the peripheral processor 240 may notify the wider system, potentially issuing a service alert instructing the user of vehicle 100 to take vehicle 100 to a service station for manual intervention. This approach is consistent with standard OTA failure handling in other domains, where the inability to complete an update even with an available rollback image is considered a critical issue requiring service intervention. In one or more other implementations, if the vehicle manufacturer relies on OTA updates to deliver new features and enhancements, the inability to update the PMIC 210 firmware over time may require repair to restore full system functionality.

[0036] The retry mechanism for OTA updates can be configured to assume all failures are recoverable, allowing for an arbitrary number of retry attempts before determining the failure to be critical. The peripheral processor 240 may initially not distinguish between minor and critical failures, but instead follow a predefined retry procedure to attempt recovery. For transient failures, such as temporary power loss, subsequent retries may successfully complete the OTA update. In one or more other implementations, if the problem is caused by an unrecoverable hardware failure (such as a permanent failure in the internal memory of the PMIC 210 that prevents the PMIC from remaining in its programmed state), this condition may only be detected after multiple failed retries. In some respects, the peripheral processor 240 may determine that additional retries may not resolve the issue and escalate the failure for further intervention. While the retry mechanism may not be dynamically adjusted based on the failure type, repeated failures may indicate a potentially unrecoverable hardware problem, prompting notification to a wider system or triggering a service alert.

[0037] If the PMIC 210 fails to complete an OTA update and the cross-domain recovery mechanism is unavailable, the affected ECU may become non-functional, requiring manual reprogramming at the factory service center. To mitigate this risk, a cross-domain ECU with sufficient memory is used to perform multiple reset attempts and restore the PMIC 210 to an operational state. This enhances system resilience by applying OTA principles to hardware-constrained environments.

[0038] Figure 3 An exemplary block diagram illustrating enhanced over-the-air programming of a power management integrated circuit between interconnected vehicle electronic control units according to one or more embodiments is shown. In one or more embodiments, Figure 3 An example of a power management system 300 is shown, in which ECU 150 is interconnected with ECU 160 via a board-to-board connector, thereby enabling communication and power distribution between the two electronic control units. In one or more embodiments, ECU 150 may be responsible for infotainment functions in vehicle 100, such as display and entertainment system management, while ECU 160 may serve as an autonomous control module responsible for the automatic driving operation of vehicle 100. Figure 3 As shown, ECU 150 and ECU 160 are separated by a depicted boundary representing two different printed circuit boards.

[0039] ECU 150 can integrate multiple power management and processing components, including power regulator circuit 250, peripheral processor 220, and PMIC 210, such as Figure 2As described herein, the power regulator circuit 250 receives power from an external source and generates regulated voltage levels for the operation of components within the ECU 150. The PMIC 210 manages power distribution and system control, while the peripheral processor 220 facilitates processing and communication functions with the PMIC 210.

[0040] like Figure 3 As shown, ECU 160 includes multiple power management ICs and processors, thereby facilitating independent power regulation for different processing units. ECU 160 includes a PMIC 360 directly coupled to peripheral processor 240, which provides regulated power to support the operation of peripheral processor 240. In one or more other embodiments, ECU 160 includes a PMIC 380 directly coupled to peripheral processor 390, which supplies power to peripheral processor 390. Including multiple PMICs in ECU 160 allows for efficient power distribution, regulation, and management across different functional blocks within ECU 160.

[0041] In one or more implementations, ECU 150 and ECU 160 can be interconnected via various possible communication interfaces, including board-to-board connectors, PCIe, or Ethernet-based connections. Figure 3 As shown, the board-to-board connector facilitates electrical and data connections for seamless integration between ECU 150 and ECU 160, allowing the system to operate in a coordinated manner as a whole. This communication enables the control, monitoring, and configuration of power management parameters across interconnected ECUs. In one or more other embodiments, the peripheral processor 220 within ECU 150 can be configured to communicate with both PMIC 360 and PMIC 380 in ECU 160 via a separate I2C interface.

[0042] An OTA update process may involve multiple PMICs across two ECUs, thus requiring a controlled sequence for updating the firmware. The PMIC associated with each ECU (e.g., ECU 150, ECU 160) can be the target of the software update process. The OTA update process may utilize an I2C interface, where a dedicated I2C connection between peripheral processors acts as the master device and each PMIC acts as a slave device.

[0043] like Figure 3 As shown, the power management system 300 includes multiplexers 330 and 332, which facilitate switching between different PMICs and dynamic master-slave role changes during OTA update processes. These MUX components can be beneficial in accommodating the possibility of switching the master processor at different stages of the OTA update process.

[0044] In one or more embodiments, OTA updates can be received via a network (e.g., a cellular network), wherein peripheral processor 220 downloads a firmware executable image and stores it in its local memory for use by both ECU 150 and ECU 160. The storage capacity of peripheral processor 220 can be allocated accordingly to store the received firmware executable image. In one or more embodiments, peripheral processor 220 can act as a master device, thereby enabling multiplexer connections to allow communication with PMIC 360 and PMIC 380. Given that peripheral processor 220 can be configured not to directly update PMIC 210, the OTA process can begin with a firmware update for PMIC 360. For example, peripheral processor 220 can enable multiplexer 330 to enable a multiplexer connection between peripheral processor 220 and PMIC 360 via a dedicated I2C interface. In this respect, peripheral processor 220 can access PMIC 360 via the I2C interface using its slave device address and write firmware updates to the memory of PMIC 360. Peripheral processor 220 can check the completion status of OTA updates, where retries are performed as needed. If multiple retries fail, peripheral processor 220 can notify the user of vehicle 100 that PMIC 360 is not functional before disabling the path to PMIC 360. Once PMIC 360 is successfully updated, a similar process is performed on PMIC 380 by reconfiguring the MUX connection, such as disabling the multiplexer connection between peripheral processor 220 and PMIC 360 and enabling the multiplexer connection between peripheral processor 220 and PMIC 380.

[0045] In one or more embodiments, firmware programming for PMIC 360 and PMIC 380 can occur sequentially due to the shared I2C interface with peripheral processor 220. In one or more other embodiments, firmware programming for PMIC 360 and PMIC 380 can be performed in parallel, provided that a separate I2C interface to peripheral processor 220 is allocated for each PMIC. The shared bus slave addressing mechanism ensures that the correct PMIC is the target of OTA updates.

[0046] After updating PMIC 360 and PMIC 380, peripheral processor 220 can power on peripheral processor 240 to initiate a handshake sequence to confirm the readiness of peripheral processor 240. For example, peripheral processor 240 can be configured to power down peripheral processor 220 and enable a second connection between peripheral processor 240 and PMIC 210 upon successful completion of the handshake sequence. In this regard, peripheral processor 240 can take over control from peripheral processor 220 to perform an OTA update of PMIC 210, thereby enabling the relevant multiplexer connection to PMIC 210, keeping peripheral processor 220 powered down during the OTA update of PMIC 210, and writing firmware updates to PMIC 210. In one or more embodiments, peripheral processor 240 can be responsible for initiating a power-down sequence of peripheral processor 220. Peripheral processor 240 can enable multiplexer 330 and then power down peripheral processor 220, thereby facilitating the correct sequencing of operations. In this configuration, combinational logic circuit 340 helps maintain the correct logic level of the enable signal to multiplexer 330, thereby preventing incorrect states that could hinder the OTA update process.

[0047] The final handshake between peripheral processor 240 and peripheral processor 220 ensures the successful application of OTA updates to PMIC 210, after which peripheral processor 220 is powered back on by peripheral processor 240. This method facilitates a controlled update sequence while maintaining system integrity and avoiding potential failures due to power dependencies between peripheral processors and their respective PMICs. In one or more other embodiments, separate control interfaces may exist between peripheral processors (e.g., 220, 240, 390) for inter-processor communication, allowing management signaling to acknowledge power status and ensure appropriate conditions for OTA updates.

[0048] The handshake sequence between peripheral processor 220 and peripheral processor 240 can be a specified operation, in which either peripheral processor can initiate communication. This method can help prevent two peripheral processors (e.g., 220, 240) from simultaneously attempting to initiate OTA updates, thereby facilitating a controlled OTA update process.

[0049] In one or more embodiments, the enable signal of each multiplexer (e.g., 330, 332) is controlled by the power state of peripheral processors 220, 240, 390. When a peripheral processor is powered down, it cannot assert the enable signal of the multiplexer, thus requiring the enable signal to originate from an active (or powered-on) peripheral processor. This logic ensures that only the powered-on peripheral processor can control the multiplexer and initiate communication with the PMIC. In one or more embodiments, the multiplexer may remain active during the OTA update process. In one or more other embodiments, the multiplexer may be non-permanently disabled after the OTA update process utilizing the PMIC is completed to prevent interference between ECU 150 and ECU 160 during normal operation.

[0050] In one or more other specific implementations, combinational logic may be input to a multiplexer to determine the state of that multiplexer, such that the combinational logic output allows only one peripheral processor to assert control of the PMIC at any given time. Figure 3 As shown, combinational logic circuit 340 is coupled to multiplexer 330, wherein combinational logic circuit 340 receives power state control signals from each of peripheral processors 220 and 240 to determine whether peripheral processor 220 can assert control of PMIC 360 via multiplexer 330. Similarly, combinational logic circuit 342 is coupled to multiplexer 332, wherein combinational logic circuit 342 receives power state control signals from each of peripheral processors 220 and 390 to determine whether peripheral processor 220 can assert control of PMIC 380 via multiplexer 332. If two or more peripheral processors are powered on, the combinational logic senses that multiple peripheral processors are active, thus deasserting their output signals and keeping the multiplexer disabled. If only one processor is powered on, the combinational logic asserts its output signal to the multiplexer, thus enabling the multiplexer to enable the multiplexer connection between the active peripheral processor and the PMIC to continue OTA updates. In one or more embodiments, each of combinational logic circuits 340 and 342 includes logic gates, such as OR gates, AND gates, NOR gates, XOR gates, etc.

[0051] In one or more implementations, combinational logic ensures that the multiplexer control signals remain stable and function as expected throughout the OTA update process. For example, combinational logic can control the multiplexer's enable signal by providing a stable logic one to the multiplexer's enable signal input to keep the multiplexer active when needed. If the enable signal input remains floating, it may present an indeterminate value. In one or more implementations, the enable signal input may be bound to a weak pull-down resistor to default to logic zero when inactive. In one or more implementations, the enable signal input may be bound to a strong pull-up resistor to assert a logic one when needed. This configuration ensures that the MUX control signals remain stable and function as expected throughout the OTA update process.

[0052] Figure 4 This is a flowchart illustrating the exemplary operation of an enhanced over-the-air programming process 400 for a power management integrated circuit, based on one or more specific implementations. The flowchart may be implemented by the power management system shown and / or described herein. For illustrative purposes, this document primarily refers to… Figure 1A and Figure 1B 100 means of transportation Figure 2 Peripheral processors 220 or 240, Figure 3 The process 400 is described using peripheral processors 390 and / or their various components. However, the process 400 is not limited to... Figure 1A and Figure 1B 100 means of transportation Figure 2 Peripheral processors 220 or 240, Figure 3 The peripheral processor 390, and one or more blocks (or operations) of process 400 may be performed by vehicle 100 and / or other suitable mobile devices, equipment, or systems, or by one or more other structural components. Furthermore, for illustrative purposes, some blocks of process 400 are described herein as occurring sequentially or linearly. However, multiple blocks of process 400 may occur in parallel. Moreover, blocks of process 400 do not need to be performed in the order shown, and / or one or more blocks of process 400 need not be performed and / or may be replaced by other operations.

[0053] At box 410, with the first PMIC (e.g., Figure 2 The first processor associated with the PMIC 210 (e.g., Figure 2 The peripheral processor 220 can initiate a second PMIC (e.g., Figure 2OTA updates for the second PMIC (PMIC 360). In some aspects, the first PMIC and the second PMIC belong to different ECUs or are located in different domains or regions. In one or more embodiments, the first processor may store a PMIC executable image received via a network. In one or more embodiments, during an OTA update of the second PMIC, at least a portion of the PMIC executable image is stored on the second PMIC. In one or more embodiments, the first processor is configured to initiate an OTA update of the second PMIC by enabling a first connection in the event of a power failure of the second processor.

[0054] At box 420, the first processor determines whether the OTA update of the second PMIC was successfully completed, as referenced in this document. Figure 3 As described. If the OTA update completes successfully, process 400 proceeds to box 430. Otherwise, process 400 proceeds to box 440.

[0055] At block 430, upon successful completion of an OTA update based on the second PMIC, the first processor can power on the second processor associated with the second PMIC and disable the first connection between the first processor and the second PMIC, allowing an OTA update between the second processor and the first PMIC to occur thereafter (if needed). In one or more embodiments, the second processor can be configured to execute a handshake sequence with the first processor to initiate an OTA update for the first PMIC upon successful completion of the OTA update for the second PMIC. The second processor can be configured to: power off the first processor and enable a second connection between the second processor and the first PMIC upon successful completion of the handshake sequence. The second processor can be further configured to: initiate an OTA update for the first PMIC via the second connection, determine that the OTA update for the first PMIC has successfully completed, and power on the first processor and disable the second connection based on the successful completion of the OTA update for the first PMIC to complete the OTA update for the first PMIC. In one or more other embodiments, the first and second connections are controlled by a multiplexer that uses combinational logic circuitry as input to the multiplexer to switch between the first and second connections. In some respects, power status signals from each of the first and second processors are input to combinational logic circuits.

[0056] In block 440, the first processor may retry the OTA update on the second PMIC after each unsuccessful completion of the OTA update on the second PMIC. In one or more embodiments, the first processor may generate a user notification indicating that the second PMIC is inoperable after multiple retries of the OTA update on the second PMIC, and disable the first connection after the user notification. After each retry, process 400 may return to block 420 to determine whether the retried OTA update completed successfully.

[0057] The methods described herein, combining direct sensing, integrated temperature monitoring, and strategic packaging, represent a approach to low-voltage battery management in electric vehicles. The methods, systems, or devices disclosed herein can be incorporated into electric vehicles or other devices. The circuit blocks disclosed herein can be distributed or combined with one or more ECUs or other devices. The methods, systems, or devices disclosed herein can be incorporated into products such as various feature-specific or region-specific electronic control units (ECUs).

[0058] Unless otherwise stated, the term "or" is used inclusively. As used herein, the phrase "at least one of" following a series of items, together with the terms "and" or "or" used to separate any items, modifies the entire list, not each member of the list (i.e., each item). The phrase "at least one of" does not require selection of at least one of each of the listed items; rather, the phrase allows for the inclusion of the meaning of at least one of any of these items, and / or at least one of any combination of these items, and / or at least one of each of these items. By way of example, the phrases "at least one of A, B, and C" or "at least one of A, B, or C" respectively refer to only A, only B, or only C; any combination of A, B, and C; and / or at least one of each of A, B, and C.

[0059] When a component is referred to herein as “connected” or “coupled” to another component, it should be understood that the component may be directly connected to the other component, or that there may be intermediate components between these components. Conversely, when a component is referred to herein as “directly connected” or “directly coupled” to another component, it should be understood that there are no intermediate components in the “direct” connection between these components. However, the presence of a direct connection does not preclude the possibility of other connections having intermediate components.

[0060] The predicates “configured to,” “operable to,” and “programmed to” do not imply any particular tangible or intangible modification of the subject matter, but are intended to be used interchangeably. In one or more embodiments, a processor configured to monitor and control operations or components may also mean that the processor is programmed to monitor and control operations or that the processor is operable to monitor and control operations. Similarly, a processor configured to execute code can be interpreted as a processor programmed to execute code or operable to execute code.

[0061] Phrases such as one aspect, aspect, on the other hand, some aspects, one or more aspects, one implementation, implementation, another implementation, some implementations, one or more implementations, one implementation scheme, implementation scheme, another implementation scheme, some implementation schemes, one or more implementation schemes, one configuration, configuration, another configuration, some configurations, one or more configurations, subject matter technology, disclosure, this disclosure, other variations thereof, and similar phrases are for convenience and do not imply that disclosures relating to such phrases are necessary for the subject matter technology or that such disclosures apply to all configurations of the subject matter technology. Disclosures relating to such phrases may apply to all configurations or one or more configurations. Disclosures relating to such phrases may provide one or more examples. Phrases such as one aspect or some aspects may refer to one or more aspects, and vice versa, and this similarly applies to other foregoing phrases.

[0062] The term “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” or “example” is not necessarily to be construed as preferred or advantageous over other embodiments. Furthermore, with regard to the use of terms such as “comprising,” “having,” etc., in the description or claims, such terms are intended to be inclusive in a manner similar to the term “including,” as interpreted when “including” is used as a transition word in the claims.

[0063] All structural and functional equivalents of elements of the various aspects described throughout this disclosure that are known to a person skilled in the art or will later be known are expressly incorporated herein by reference and are intended to be covered by the claims. Furthermore, nothing disclosed herein is intended to serve the public, whether or not such disclosure is expressly stated in the claims. No claim element should be subject to 35 USC. As defined in paragraph 6 of 112, unless the phrase “component for…” is used to explicitly state the element, or, in the case of a method claim, the phrase “step for…” is used to state the element.

[0064] The foregoing description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not intended to limit them to the aspects shown herein, but are to be consistent with the full scope of the language claims, wherein elements referred to in the singular are not intended to mean “one and only one” but rather “one or more” unless specifically stated otherwise. Unless otherwise specifically stated, the term “some” refers to one or more. Male pronouns (e.g., his) include female and neutral pronouns (e.g., her and its), and vice versa. Titles and subheadings (if any) are used for convenience only and do not limit this disclosure.

Claims

1. A system comprising: A first electronic control unit (ECU), the first electronic control unit including a first power management integrated circuit (PMIC) and a first processor; and The second ECU includes a second PMIC and a second processor. The first processor is configured as follows: Initiate an over-the-air (OTA) update for the second PMIC. Confirm that the OTA update of the second PMIC was successfully completed, and Based on the successful completion of the OTA update based on the second PMIC, the second processor is powered on and the first connection between the first processor and the second PMIC is disabled, thereby allowing OTA updates between the second processor and the first PMIC.

2. The system of claim 1, wherein one or more of the first processor or the second processor stores a PMIC executable image received via a network, and wherein at least a portion of the PMIC executable image is stored on the second PMIC during the OTA update of the second PMIC.

3. The system of claim 1, wherein the first processor is configured to initiate the OTA update of the second PMIC by enabling the first connection in the event of a power failure of the second processor.

4. The system of claim 1, wherein the first processor is further configured to: retry the OTA update on the second PMIC after each unsuccessful completion of the OTA update on the second PMIC.

5. The system of claim 4, wherein the first processor is further configured to: generate a user notification indicating that the second PMIC is nonfunctional after multiple retries of the OTA update on the second PMIC; and disable the first connection after the user notification.

6. The system of claim 1, wherein the second processor is configured to: execute a handshake sequence with the first processor to initiate an OTA update of the first PMIC when the OTA update of the second PMIC is successfully completed.

7. The system of claim 6, wherein the second processor is further configured to: Power off the first processor, and A second connection between the second processor and the first PMIC is enabled when the handshake sequence is successfully completed.

8. The system of claim 7, wherein the second processor is further configured to: The OTA update of the first PMIC is initiated through the second connection. It is determined that the OTA update of the first PMIC was successfully completed, and Based on the successful completion of the OTA update of the first PMIC, the first processor is powered on and the second connection is disabled to complete the OTA update of the first PMIC.

9. The system of claim 7, wherein the first connection and the second connection are controlled by a multiplexer, the multiplexer using combinational logic circuitry as input to the multiplexer to switch between the first connection and the second connection.

10. The system of claim 9, wherein a power status signal from each of the first processor and the second processor is input to the combinational logic circuit.

11. The system of claim 1, wherein the first ECU and the second ECU are connected via a board-to-board connector.

12. A first electronic control unit (ECU), the first electronic control unit comprising: First processor; and First power management integrated circuit (PMIC). The first processor is configured as follows: Initiate an over-the-air (OTA) update for the second PMIC in the second ECU connected to the first ECU. Determine whether the OTA update of the second PMIC was successfully completed. Based on the successful completion of the OTA update of the second PMIC, the second processor in the second ECU is powered on and the first connection between the first processor and the second PMIC is disabled, thereby allowing OTA updates between the second processor and the first PMIC. If the OTA update on the second PMIC fails to complete, a retry of the OTA update on the second PMIC is performed after each unsuccessful completion of the OTA update on the second PMIC.

13. The first ECU of claim 12, wherein the first processor is configured to initiate the OTA update of the second PMIC by enabling the first connection in the event of a power failure of the second processor.

14. The first ECU of claim 12, wherein the first processor is further configured to: retry the OTA update on the second PMIC after each unsuccessful completion of the OTA update on the second PMIC.

15. The first ECU of claim 14, wherein the first processor is further configured to: generate a user notification indicating that the second PMIC is nonfunctional after multiple retries of the OTA update on the second PMIC; and disable the first connection after the user notification.

16. The first ECU of claim 12, wherein the first processor is configured to: execute a handshake sequence with the second processor when the OTA update of the second PMIC is successfully completed, so that the second processor can initiate an OTA update of the first PMIC.

17. A method, the method comprising: An executable image for programming the first PMIC and the second PMIC is received by a first processor associated with the first power management integrated circuit (PMIC); The first processor initiates an over-the-air (OTA) update of the second PMIC; It is confirmed that the OTA update of the second PMIC was successfully completed; as well as Based on the successful completion of the OTA update based on the second PMIC, the first processor powers on the second processor associated with the second PMIC and disables the first connection between the first processor and the second PMIC to allow OTA updates between the second processor and the first PMIC.

18. The method according to claim 17, further comprising: The first processor performs a retry of the OTA update on the second PMIC after each unsuccessful completion of the OTA update on the second PMIC.

19. The method according to claim 18, further comprising: The first processor generates a user notification indicating that the second PMIC is inoperable after multiple retries of the OTA update on the second PMIC; as well as The first processor disables the first connection after receiving the user notification.

20. The method of claim 17, further comprising: When the OTA update of the second PMIC is successfully completed, the first processor executes a handshake sequence with the second processor so that the second processor can initiate an OTA update of the first PMIC.

Images