Domain controller wake-up system

Abstract

The application discloses a domain controller wake-up system, which uses two start programs, namely a fast start program and a normal start program; when the domain controller chip is not started for the first time, a first start boot program is used to load the fast start program, the fast start program only performs a wake-up function, a wake-up frame message is sent in a CAN message sending mode through a GPIO to wake up other domain controller sub-nodes related to a gateway domain; then, a second start boot program is used to load the normal start program, the normal start program is used to set related peripherals and items required for normal start, a CAN routing environment is loaded, and a CAN routing function is enabled. The domain controller wake-up system can realize fast start of the domain controller sub-nodes, can realize fast start between different domain controller sub-nodes of the gateway domain, improves the sending and receiving efficiency of the wake-up frame, and shortens the start time of the vehicle domain controller.

Description

Technical Field

[0001] This invention relates to intelligent connected vehicle technology, and in particular to a domain controller wake-up system. Background Technology

[0002] With the advancement of automotive technology, the demand for intelligent and connected vehicles is increasing, and the overall vehicle electronic and electrical architecture is gradually evolving from a distributed architecture to a centralized domain controller architecture. Each domain controller integrates a large number of application functions. As users' demands for driving experience increase, these application functions are becoming increasingly complex and bulky, forcing domain controllers to compromise on startup speed to meet these functional requirements. In existing technologies, the startup of child nodes and between domain controllers is controlled by wake-up frames. However, wake-up frames can only be sent via the CAN protocol stack after the domain controller has reached the application stage. This results in unsatisfactory vehicle startup speed, long user waiting times, and a poor user experience. Therefore, improving the sending and receiving efficiency of wake-up frames and shortening the startup time of the vehicle's domain controllers has become an urgent technical problem to be solved. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a domain controller wake-up system that can improve the efficiency of sending and receiving wake-up frames and shorten the startup time of the vehicle domain controller.

[0004] To solve the above-mentioned technical problems, the present invention provides a domain controller wake-up system, which includes a domain controller chip, wherein the domain controller chip is configured with a first boot program, a fast boot program, a second boot program, a normal boot program and an application program;

[0005] When the domain controller chip is not being started for the first time, the following steps are included:

[0006] S1. The first bootloader guides the fast bootloader into normal operating mode;

[0007] S2. After the quick startup program enters the normal working mode, the running system is the minimum system. The minimum system sequentially enables the domain controller chip system clock, initializes the domain controller chip GPIO, sends a wake-up frame 01 to the CAN bus 01 by simulating a CAN message through GPIO, and enables the second startup boot program to run.

[0008] S3. When the second bootloader runs, it guides the normal bootloader into normal working mode;

[0009] S4. When the normal startup program enters the normal working mode, it first sets the relevant peripherals and the items required for normal startup, and loads the CAN routing environment to enable CAN routing capability. The domain controller chip will realize the routing forwarding of the wake-up frame CAN message from one CAN line to other CAN lines according to the routing table set in the software or hardware system; finally, it makes the application run.

[0010] S5. When the application runs, it will activate various vehicle functions.

[0011] Preferably, the CAN routing environment includes CAN firmware and CAN driver.

[0012] Preferably, in step S1, the first bootloader first initializes the device to ensure the internal and external environment for the fast bootloader to run, and then sets up the kernel, loads the operating system in the fast bootloader, and guides the fast bootloader into normal working mode.

[0013] Perform device initialization, including hardware device initialization, memory space mapping, stack initialization, and memory initialization.

[0014] Preferably, in step S2, sending the wake-up frame 01 to the CAN bus 01 by simulating a CAN message via GPIO includes the following steps:

[0015] Step S201. Set the relevant CAN port status of the main control register MSCR, set the relevant CAN port to GPIO drive mode, and set the STB pin of the relevant CAN port to low level to enable the transceiver of the relevant CAN; until the CAN port status of all CAN lines that need to send wake-up frame messages are set by the domain controller chip.

[0016] Step S202. Sequentially parse whether the state of each CAN bit in the wake-up frame message is high or low;

[0017] Step S203. Obtain the CAN bit time length of the current CAN line;

[0018] Step S204. Set the GPIO output value according to the current CAN bit time level signal high or low;

[0019] Step S205. Delay the timer by one CAN bit time length;

[0020] Step S206. Repeat steps S204 to S205 until all CAN bit information of the wake-up frame message on the current CAN line has been completely sent through GPIO simulation.

[0021] Step S207. Repeat steps S203 to S206 until all wake-up frames on all CAN lines with wake-up requirements have been sent.

[0022] Preferably, in step S205, the CAN bit time length = CAN bit time / system crystal oscillator period;

[0023] CAN bit time = 1 / baud rate on the CAN line;

[0024] The system clock is a crystal oscillator clock, which is the internal clock of the chip and does not need to be synchronized with an external clock.

[0025] The CAN bit time refers to the time required for one binary bit in the wake-up frame message data segment to be transmitted on the bus.

[0026] Preferably, in step S204, the CAN port transmit pin is pulled high by GPIO control to simulate the high level state of the CAN bit in the wake-up frame message; the CAN port transmit pin is pulled low by GPIO control to simulate the low level state of the CAN bit in the wake-up frame message.

[0027] Preferably, in step S204, the control register position of the corresponding CAN port transmit pin is found, and the high or low level of the CAN port transmit pin is controlled by writing a value to the control register position.

[0028] Preferably, in step S205, the system clock is first called to obtain the start time, and then the system clock is continuously obtained in the logic lock until the increase of the system clock reaches the length of a CAN bit, and then the logic lock is released to proceed to the next step.

[0029] Preferably, in step S2, the domain controller chip GPIO is initialized by setting the relevant attributes of the control registers of the ports for the CAN port transmit pin and enable pin required for the wake-up frame message, while the control register attributes of other irrelevant ports do not need to be set.

[0030] Preferably, the domain controller chip is provided with a non-volatile memory area and a static memory.

[0031] The normal startup program is stored in the non-volatile memory area;

[0032] Step S3 includes the following steps:

[0033] Step S301. The second bootloader first initializes the device to ensure the internal and external environment for the normal bootloader to run;

[0034] Perform device initialization, including hardware device initialization, memory space mapping, stack initialization, and memory initialization;

[0035] Step S302. The second bootloader mirrors the code of the normal bootloader into the static memory;

[0036] Step S303. The second bootloader sets the kernel, loads the operating system of the normal bootloader, and boots the normal bootloader in the static memory into normal working mode.

[0037] Preferably, the domain controller wake-up system further includes a power output control module;

[0038] The power output control module is used to periodically detect wake-up sources. When a wake-up source is detected, it supplies power to the domain controller chip and guides the domain controller chip into normal operating mode.

[0039] Preferably, after the domain controller chip is powered on, it determines whether it is the first boot. If it is not the first boot, then proceed to step S1, where the first boot loader runs to guide the fast boot program into normal working mode; if it is the first boot, then proceed directly to step S3, where the second boot loader runs to guide the normal boot program into normal working mode.

[0040] Preferably, the initial state of the wake-up domain inside the domain controller chip is 1, and after the application finishes running, the wake-up domain state is set to 0;

[0041] When the domain controller chip is powered on, if the internal wake-up domain state is 1, the second bootloader is selected to run; if the internal wake-up domain state is 0, the first bootloader is selected to run.

[0042] Preferably, the domain controller chip has a hibernation mode random access memory, and the fast startup program is stored in the hibernation mode random access memory.

[0043] Preferably, the hibernation mode memory has a separate power supply system, which provides normal power supply when the domain controller chip is in hibernation mode.

[0044] Preferably, step S5 includes the following steps:

[0045] Step S501. Activate all vehicle functions;

[0046] Step S502. Periodically monitor whether the domain controller chip has a sleep requirement. If so, proceed to step S503; otherwise, proceed to step S502.

[0047] Step S503. Set the wake-up domain state to 0;

[0048] Step S504. Mirror the code of the fast startup program in the non-volatile memory area to the hibernation mode memory;

[0049] Step S505. Execute the domain controller chip's sleep procedure until the sleep conditions are met, causing the domain controller chip to enter a low-power mode.

[0050] Preferably, in step S5, when starting each vehicle function, the relevant peripheral drivers of the domain controller chip will be reinitialized, so that the CAN routing table information set in the normal startup procedure is updated, and the domain controller chip will configure CAN message routing according to the new CAN routing table.

[0051] Preferably, step S4 includes the following steps:

[0052] Step S401. Initialize the functional modules necessary for the domain controller chip in the normal startup procedure;

[0053] Step S402. Initialize the system clock required by the domain controller chip during the normal startup procedure;

[0054] Step S403. Initialize the wake-up frame interrupt timer in the normal startup procedure, so that the wake-up frame interrupt timer starts counting with the period of the system clock;

[0055] Step S404. Initialize the port attributes required for the system to run in the normal startup procedure, that is, configure the domain controller chip I / O pin attributes related to the system to run in the normal startup procedure;

[0056] Step S405. Load CAN firmware, that is, mirror the binary file of the CAN firmware required by the CAN driver to the corresponding location in the system kernel space, so that the CAN driver can call it when the domain controller chip sends and receives CAN messages;

[0057] Step S406. CAN driver initialization;

[0058] Step S407. Set the CAN port status;

[0059] Step S408. Message routing and forwarding are performed according to the CAN routing table rules;

[0060] Configure the initialization settings for other functional modules of the normal startup program.

[0061] Preferably, the functional modules necessary for the normal startup process include the chip's power supply module, reset control module, and system integration module;

[0062] The system clocks required for a normal startup procedure include the phase-locked loop (PLL) clock and peripheral clocks.

[0063] Preferably, in step S405, the CAN driver initialization includes setting the working mode of the CAN controller, the CAN bus clock frequency, the CAN bus message format, the CAN message transmit / receive buffer, and the CAN interrupt service, which are used to ensure the driver configuration required for normal CAN message transmission and reception, as well as configuring the CAN routing table information in the software or hardware system.

[0064] In step S406, setting the CAN port status includes setting the CAN controller operating mode of all CAN lines where the wake-up frame message is located to startup mode, and setting the STB pin attributes of the wake-up frame CAN port.

[0065] Preferably, when the CAN port STB pin on the CAN line where the wake-up frame message is located is initialized to a low level in step S404, step S406 does not need to set the CAN port STB pin attribute of the wake-up frame; otherwise, step S406 sets the CAN port STB pin attribute of the wake-up frame to a low level.

[0066] Preferably, in step S407, after setting the initialization configuration of other functional modules of the normal startup program, the following steps are performed:

[0067] S4071. Periodically check whether the wake-up frame interrupt timer has reached the predetermined sending time of the wake-up frame. If it has, proceed to step S4073; otherwise, proceed to step S4072.

[0068] S4072. Perform a built-in watchdog register overload operation (commonly known as the watchdog feeding operation in embedded development), and then execute step S4071;

[0069] S4073. Set the wake-up frame message format as required, and then call the CAN driver interface to send the wake-up frame message to the CAN bus;

[0070] S4074. Set the target of the next stage startup of the domain controller chip to the application program, and proceed to step S5.

[0071] The domain controller wake-up system of this invention uses two startup programs: a fast boot program and a normal boot program. When the domain controller chip is not starting up for the first time, the first startup boot program loads the fast boot program, which only performs the wake-up function. It quickly sends a wake-up frame 01 message to wake up other domain controller sub-nodes (other domain controllers) in the gateway domain by simulating CAN message transmission via GPIO. Then, the second startup boot program loads the normal boot program, which sets up the relevant peripherals and items required for normal startup, loads the CAN routing environment, enables the CAN routing function, and has the ability to route and forward wake-up frame messages from other domain controller sub-nodes (other domain controllers) in the gateway domain. Finally, the normal boot program guides the system program to jump to the application program. The application program starts various vehicle functions, and the CAN firmware does not need to be loaded again during the application program stage. This domain controller wake-up system, when the domain controller chip is not being started for the first time, advances the transmission of the wake-up frame 01 message to the fast boot program execution phase, enabling rapid startup of domain controller sub-nodes; it also advances the transmission and reception of wake-up frame messages from other domain controller sub-nodes (domain controllers) in the gateway domain to the normal boot program execution phase, enabling rapid startup between different domain controller sub-nodes (domain controllers) in the gateway domain. This domain controller wake-up system improves the transmission and reception efficiency of wake-up frames, shortens the overall vehicle domain controller startup time, and enhances the user experience. Attached Figure Description

[0072] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0073] Figure 1 This is a schematic diagram of the structure of an embodiment of the domain controller wake-up system of the present invention;

[0074] Figure 2 This is a schematic diagram illustrating the working process of an embodiment of the domain controller wake-up system of the present invention;

[0075] Figure 3 This is a schematic diagram illustrating the GPIO-simulated CAN message transmission process of an embodiment of the domain controller wake-up system of the present invention.

[0076] Figure 4 This is a schematic diagram of the normal startup procedure loading process of an embodiment of the domain controller wake-up system of the present invention. Detailed Implementation

[0077] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0078] The terms "first," "second," and similar words used in this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Words such as "including" or "comprising" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Words such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0079] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0080] It should be noted that the terms "wake-up frame," "wake-up frame 01," "wake-up frame 02," etc., used in the specification, claims, and drawings of this invention are used to describe objects of communication types, and are not necessarily limited to describing specific object types. It should be understood that different types of objects fall within the scope of protection of this application when implemented using the same method.

[0081] Example 1

[0082] like Figure 1 As shown, the domain controller wake-up system includes a domain controller chip, which is configured with a first boot program, a fast boot program, a second boot program, a normal boot program, and an application program.

[0083] like Figure 2 As shown, when the domain controller chip is not starting up for the first time, the following steps are performed:

[0084] S1. The first bootloader guides the fast bootloader into normal operating mode;

[0085] S2. After the quick startup program enters the normal working mode, the running system is the minimum system. The minimum system sequentially enables the domain controller chip system clock, initializes the domain controller chip GPIO, sends a wake-up frame 01 to the CAN bus 01 by simulating a CAN message through GPIO, and enables the second startup boot program to run.

[0086] S3. When the second bootloader runs, it guides the normal bootloader into normal working mode;

[0087] S4. When the normal startup program enters the normal working mode, it first sets the relevant peripherals and the items required for normal startup, and loads the CAN routing environment to enable CAN routing capability. The domain controller chip will realize the routing forwarding of the wake-up frame CAN message from one CAN line to other CAN lines according to the routing table set in the software or hardware system; finally, it makes the application run.

[0088] S5. When the application runs, it will activate various vehicle functions.

[0089] Preferably, the CAN routing environment includes CAN firmware and CAN driver, etc.

[0090] The domain controller wake-up system in Example 1 uses two startup procedures: a fast boot procedure and a normal boot procedure. When the domain controller chip is not being started for the first time, the first startup program loads the fast boot procedure, which only performs the wake-up function. It quickly sends a wake-up frame 01 message via GPIO to simulate CAN message transmission, waking up other domain controller sub-nodes (other domain controllers) in the gateway domain. Then, the second startup program loads the normal boot procedure, which sets up relevant peripherals and necessary items for normal startup, loads the CAN routing environment, enables CAN routing, and provides the ability to route and forward wake-up frame messages from other domain controller sub-nodes (other domain controllers) in the gateway domain. Figure 1 As shown, it can receive CAN messages from other domain controller sub-nodes (other domain controllers) to CAN line 01 via wake-up frames 02, and can route the received CAN messages via wake-up frames 02 to CAN bus 02; the normal startup program will eventually guide the system program to jump to the application program, and the application program will start various vehicle functions. The application program does not need to load the CAN firmware again.

[0091] The domain controller wake-up system in Embodiment 1, when the domain controller chip is not being started for the first time, advances the transmission of the wake-up frame 01 message to the fast boot program execution phase, enabling fast startup of the domain controller sub-nodes; it also advances the transmission and reception of wake-up frame messages from other domain controller sub-nodes (domain controllers) in the gateway domain to the normal boot program execution phase, enabling fast startup between different domain controller sub-nodes (domain controllers) in the gateway domain; this domain controller wake-up system improves the transmission and reception efficiency of wake-up frames, shortens the startup time of the entire vehicle domain controller, and improves the user experience.

[0092] Example 2

[0093] Based on the domain controller wake-up system of Embodiment 1, in step S1, the first boot loader first initializes the device to ensure the internal and external environment for the fast boot program to run, and then sets up the kernel, loads the operating system in the fast boot program, and guides the fast boot program into normal working mode.

[0094] Perform device initialization, including hardware initialization, memory space mapping, stack initialization, and memory initialization, to ensure the internal and external environment for fast boot program operation.

[0095] Example 3

[0096] Based on the domain controller wake-up system of Embodiment 1, in step S2, as follows: Figure 3 As shown, sending wake-up frame 01 to CAN bus 01 via GPIO to simulate a CAN message includes the following steps:

[0097] Step S201. Set the relevant CAN port status of the main control register (MSCR) of the domain controller chip, set the relevant CAN port to GPIO drive mode, and set the STB pin of the relevant CAN port to low level to enable the transceiver of the relevant CAN; until the CAN port status of all CAN lines of the domain controller chip that need to send wake-up frame messages is set.

[0098] Step S202. Sequentially parse whether the state of each CAN bit in the wake-up frame message is high or low;

[0099] Step S203. Obtain the CAN bit time length of the current CAN line;

[0100] Step S204. Set the GPIO output value according to the current CAN bit time level signal high or low;

[0101] Step S205. Delay the timer by one CAN bit time length;

[0102] Step S206. Repeat steps S204 to S205 until all CAN bit information of the wake-up frame message on the current CAN line has been completely sent through GPIO simulation.

[0103] Step S207. Repeat steps S203 to S206 until all wake-up frames on all CAN lines requiring wake-up have been sent. Since the baud rates on different CAN lines may differ, steps S203 to S206 need to be repeated multiple times.

[0104] Preferably, in step S205, the CAN bit time length = CAN bit time / system crystal oscillator period, that is, how many system crystal oscillator periods correspond to one CAN bit time on the target CAN line;

[0105] CAN bit time = 1 / baud rate on the CAN line;

[0106] The system clock is a crystal oscillator clock, which is the internal clock of the chip and does not need to be synchronized with an external clock.

[0107] The CAN bit time refers to the time required for one binary bit in the wake-up frame message data segment to be transmitted on the bus.

[0108] Preferably, in step S204, the CAN port transmit pin is pulled high by GPIO control to simulate the high level state of the CAN bit in the wake-up frame message; the CAN port transmit pin is pulled low by GPIO control to simulate the low level state of the CAN bit in the wake-up frame message.

[0109] Preferably, in step S204, the control can be achieved without GPIO driver by using GPIO control. The control register position of the corresponding CAN port transmit pin is found, and the high or low level of the CAN port transmit pin is controlled by writing a value to the control register position.

[0110] Preferably, in step S205, the system clock is first called to obtain the start time, and then the system clock is continuously obtained in the logic lock until the increase of the system clock reaches the length of a CAN bit, and then the logic lock is released to proceed to the next step.

[0111] In the domain controller wake-up system of Example 3, when a wake-up frame is sent by simulating a CAN message via GPIO, the relevant CAN port status is set by directly writing a value to the corresponding position in the main control register (MSCR) of the domain controller chip. This bypasses the CAN driver configuration and speeds up the wake-up frame sending speed.

[0112] Example 4

[0113] In the domain controller wake-up system based on Embodiment 1, step S2, the method for initializing the GPIO of the domain controller chip, can be achieved by directly setting the relevant control registers. The register setting method is as follows: only the relevant attributes of the CAN port transmit pin and enable pin required for the wake-up frame message need to be set; the attributes of other irrelevant ports do not need to be set.

[0114] Example 5

[0115] The domain controller wake-up system based on Embodiment 1 has a FLASH memory and a static RAM built into the domain controller chip.

[0116] The normal startup program is stored in the non-volatile memory area;

[0117] Step S3 includes the following steps:

[0118] Step S301. The second bootloader first initializes the device to ensure the internal and external environment for the normal bootloader to run;

[0119] Perform device initialization, including hardware device initialization, memory space mapping, stack initialization, and memory initialization, to ensure the internal and external environment for normal program startup.

[0120] Step S302. The second bootloader mirrors the code of the normal bootloader into the static memory;

[0121] Step S303. The second bootloader sets the kernel, loads the operating system of the normal bootloader, and boots the normal bootloader in the static memory into normal working mode.

[0122] Example 6

[0123] Based on implementation one, the domain controller wake-up system further includes a power output control module (PMIC);

[0124] The power output control module (PMIC) is used to periodically detect wake-up sources. When a wake-up source is detected, it supplies power to the domain controller chip and guides the domain controller chip into normal operating mode.

[0125] Example 7

[0126] Based on the domain controller wake-up system of Implementation 6, after the domain controller chip is powered on, it determines whether it is the first time to start. If it is not the first time to start, then step S1 is performed, in which the first startup boot program runs to guide the fast startup program into the normal working mode; if it is the first time to start, then step S3 is performed directly, in which the second startup boot program runs to guide the normal startup program into the normal working mode.

[0127] In the domain controller wake-up system of Embodiment 7, when the domain controller chip starts for the first time, the normal startup program is loaded through the second boot loader, which guides the normal startup program into the normal working mode.

[0128] Example 8

[0129] Based on the domain controller wake-up system of Embodiment 7, the initial state of the wake-up domain inside the domain controller chip is 1, and after the application finishes running, the wake-up domain state is set to 0.

[0130] When the domain controller chip is powered on, it selects the bootloader to run by detecting the wake-up domain state inside the chip. If the wake-up domain state inside the domain controller chip is 1, the second bootloader is selected to run; if the wake-up domain state inside the domain controller chip is 0, the first bootloader is selected to run.

[0131] In the domain controller wake-up system of Example 8, when the domain controller chip is powered on, it selects a bootloader by detecting the internal wake-up domain state. If the internal wake-up domain state is 1, the second bootloader is selected. Thus, during the first power-on startup of the domain controller chip, the domain controller wake-up system is started using the second bootloader. During the hibernation process after the application finishes running, the internal wake-up domain state of the domain controller chip is set to 0, so that the domain controller chip starts the domain controller wake-up system from the first bootloader when it is not the first startup.

[0132] Example 9

[0133] Based on the domain controller wake-up system of Embodiment 8, the domain controller chip is provided with a sleep mode random access memory (Standby RAM), and the fast startup program is stored in the sleep mode random access memory (Standby RAM).

[0134] The standby RAM has a separate power supply system. When the domain controller chip is in sleep mode, the standby RAM is powered normally, and the code data in the standby RAM will not be lost, and it has the ability to load and start quickly.

[0135] Example 10

[0136] In the domain controller wake-up system based on Embodiment 9, step S5 includes the following steps:

[0137] Step S501. Activate all vehicle functions;

[0138] Step S502. Periodically monitor whether the domain controller chip has a sleep requirement. If so, proceed to step S503; otherwise, proceed to step S502.

[0139] Step S503. Set the wake-up domain state to 0, that is, set the startup mode of the wake-up domain inside the domain controller chip to start from the first boot loader. When the domain controller chip completes a sleep cycle and starts up again, the domain controller chip considers this startup to be a non-first startup.

[0140] Step S504. Mirror the code of the fast startup program in the non-volatile memory area to the hibernation mode memory;

[0141] Step S505. Execute the domain controller chip's sleep procedure until the sleep conditions are met, causing the domain controller chip to enter a low-power mode.

[0142] Preferably, in step S5, when starting each vehicle function, the relevant peripheral drivers of the domain controller chip will be reinitialized, so that the CAN routing table information set in the normal startup procedure is updated, and the domain controller chip will configure CAN message routing according to the new CAN routing table.

[0143] In the domain controller wake-up system of Embodiment 10, the application loads the image of the fast startup program before the domain controller chip goes into sleep mode and sets the startup mode of the domain controller chip wake-up domain to start from the first startup boot program. Since the application does not need to load the CAN firmware again after the domain controller chip goes into sleep mode, the startup time of each vehicle function can be shortened.

[0144] Example 11

[0145] Based on the domain controller wake-up system of Embodiment 9, in step S4, as follows: Figure 4 As shown, the normal startup process includes the following steps:

[0146] Step S401. Initialize the functional modules necessary for the domain controller chip (MCU) in the normal startup procedure;

[0147] Step S402. Initialize the system clock required by the domain controller chip during the normal startup procedure;

[0148] Step S403. Initialize the wake-up frame interrupt timer in the normal startup procedure, so that the wake-up frame interrupt timer starts counting with the period of the system clock;

[0149] Step S404. Initialize the port attributes required for the system to run in the normal startup procedure, that is, configure the domain controller chip I / O pin attributes related to the system to run in the normal startup procedure;

[0150] Step S405. Load CAN firmware, that is, mirror the binary file of the CAN firmware required by the CAN driver to the corresponding location in the system kernel space, so that the CAN driver can call it when the domain controller chip sends and receives CAN messages;

[0151] Step S406. CAN driver initialization;

[0152] Step S407. Set the CAN port status;

[0153] Step S408. Message routing and forwarding are performed according to the CAN routing table rules;

[0154] Configure the initialization settings for other functional modules of the normal startup program.

[0155] After the CAN driver is initialized, the CAN message routing table configured in the domain controller chip is enabled. At this point, the domain controller chip has the ability to route and forward messages on different CAN lines according to the routing table configuration. This message forwarding capability is mainly used to route and forward wake-up frame messages of other domain controller child nodes (domain controllers) in the gateway domain during the normal startup (normal boot) program execution phase of the domain controller chip, so as to realize mutual wake-up between other domain controller child nodes (domain controllers). When the application runs, the CAN driver will be reinitialized, and the new CAN routing table configuration will be updated accordingly. The domain controller chip will then forward messages according to the new CAN routing table rules.

[0156] The other functional modules of the normal startup program are designed to meet the specific needs of the domain controller chip during the startup process.

[0157] Preferably, the functional modules necessary for the normal startup process include the chip's power supply module, reset control module, and system integration module.

[0158] Preferably, the system clocks required during normal startup include the phase-locked loop (PLL) clock and peripheral clocks.

[0159] Preferably, in step S405, the CAN driver initialization includes setting the operating mode of the CAN controller, the CAN bus clock frequency, the CAN bus message format, the CAN message transmit / receive buffer, and the CAN interrupt service, which are the driver configurations required to ensure normal CAN message transmission and reception, as well as configuring the CAN routing table information in the software or hardware system.

[0160] Preferably, in step S406, setting the CAN port status includes setting the CAN controller operating mode of all CAN lines where the wake-up frame message is located to startup mode, and setting the STB pin attributes of the wake-up frame CAN port.

[0161] Preferably, when the CAN port STB pin on the CAN line where the wake-up frame message is located is initialized to a low level in step S404, step S406 does not need to set the CAN port STB pin attribute of the wake-up frame; otherwise, step S406 sets the CAN port STB pin attribute of the wake-up frame to a low level.

[0162] Preferably, in step S407, after setting the initialization configuration of other functional modules of the normal startup program, the following steps are performed:

[0163] S4071. Periodically check whether the wake-up frame interrupt timer has reached the predetermined sending time of the wake-up frame. If it has, proceed to step S4073; otherwise, proceed to step S4072.

[0164] S4072. Perform a built-in watchdog register reload operation (commonly known as the watchdog feeding operation in embedded development) to prevent the domain controller chip from misjudging the system abnormality and causing a reset, and then execute step S4071.

[0165] S4073. Set the wake-up frame message format as required, and then call the CAN driver interface to send the wake-up frame message to the CAN bus;

[0166] S4074. If the target of the next stage of the domain controller chip startup is set to the application, then after the Boot stage ends, step S5 will be performed, that is, the application will run.

[0167] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A domain controller wake-up system, characterized in that, It includes a domain controller chip, which is configured with a first bootloader, a fast bootloader, a second bootloader, a normal bootloader, and an application program. When the domain controller chip is not being started for the first time, the following steps are included: S1. The first bootloader guides the fast bootloader into normal operating mode; S2. After the quick startup program enters the normal working mode, the running system is the minimum system. The minimum system sequentially enables the domain controller chip system clock, initializes the domain controller chip GPIO, sends a wake-up frame 01 to the CAN bus 01 by simulating a CAN message through GPIO, and enables the second startup boot program to run. S3. When the second bootloader runs, it guides the normal bootloader into normal working mode; S4. When the normal startup program enters the normal working mode, it first sets the relevant peripherals and the items required for normal startup, and loads the CAN routing environment to enable CAN routing capability. The domain controller chip will realize the routing forwarding of the wake-up frame CAN message from one CAN line to other CAN lines according to the routing table set in the software or hardware system; finally, it makes the application run. S5. When the application runs, it will activate various vehicle functions.

2. The domain controller wake-up system according to claim 1, characterized in that, The CAN routing environment includes CAN firmware and CAN driver.

3. The domain controller wake-up system according to claim 1, characterized in that, In step S1, the first bootloader first initializes the device to ensure the internal and external environment for the fast bootloader to run, and then sets up the kernel, loads the operating system in the fast bootloader, and guides the fast bootloader into normal working mode. Perform device initialization, including hardware device initialization, memory space mapping, stack initialization, and memory initialization.

4. The domain controller wake-up system according to claim 1, characterized in that, In step S2, sending wake-up frame 01 to CAN bus 01 via GPIO to simulate a CAN message includes the following steps: Step S201. Set the relevant CAN port status of the main control register MSCR, set the relevant CAN port to GPIO drive mode, and set the STB pin of the relevant CAN port to low level to enable the transceiver of the relevant CAN; until the CAN port status of all CAN lines that need to send wake-up frame messages are set by the domain controller chip. Step S202. Sequentially parse whether the state of each CAN bit in the wake-up frame message is high or low; Step S203. Obtain the CAN bit time length of the current CAN line; Step S204. Set the GPIO output value according to the current CAN bit time level signal high or low; Step S205. Delay the timer by one CAN bit time length; Step S206. Repeat steps S204 to S205 until all CAN bit information of the wake-up frame message on the current CAN line has been completely sent through GPIO simulation. Step S207. Repeat steps S203 to S206 until all wake-up frames on all CAN lines with wake-up requirements have been sent.

5. The domain controller wake-up system according to claim 4, characterized in that, In step S205, the CAN bit time length = CAN bit time / system crystal oscillator period; CAN bit time = 1 / baud rate on the CAN line; The system clock is a crystal oscillator clock, which is the internal clock of the chip and does not need to be synchronized with an external clock. The CAN bit time refers to the time required for one binary bit in the wake-up frame message data segment to be transmitted on the bus.

6. The domain controller wake-up system according to claim 5, characterized in that, In step S204, the CAN port transmit pin is pulled high by GPIO control to simulate the high level state of the CAN bit in the wake-up frame message; the CAN port transmit pin is pulled low by GPIO control to simulate the low level state of the CAN bit in the wake-up frame message.

7. The domain controller wake-up system according to claim 5, characterized in that, In step S204, the control register position of the corresponding CAN port transmit pin is located, and the high or low level of the CAN port transmit pin is controlled by writing a value to the control register position.

8. The domain controller wake-up system according to claim 5, characterized in that, In step S205, the system clock is first called to obtain the start time, and then the system clock is continuously obtained in the logic lock until the increase of the system clock reaches the length of a CAN bit, and then the logic lock is released to proceed to the next step.

9. The domain controller wake-up system according to claim 1, characterized in that, In step S2, the control registers of the ports for the CAN port transmit pin and enable pin required for the wake-up frame message are set, while the control registers of other unrelated ports do not need to be set, thus initializing the domain controller chip GPIO.

10. The domain controller wake-up system according to claim 1, characterized in that, The domain controller chip is equipped with a non-volatile memory area and a static memory. The normal startup program is stored in the non-volatile memory area; Step S3 includes the following steps: Step S301. The second bootloader first initializes the device to ensure the internal and external environment for the normal bootloader to run; Perform device initialization, including hardware device initialization, memory space mapping, stack initialization, and memory initialization; Step S302. The second bootloader mirrors the code of the normal bootloader into the static memory; Step S303. The second bootloader sets the kernel, loads the operating system of the normal bootloader, and boots the normal bootloader in the static memory into normal working mode.

11. The domain controller wake-up system according to claim 1, characterized in that, The domain controller wake-up system also includes a power output control module; The power output control module is used to periodically detect wake-up sources. When a wake-up source is detected, it supplies power to the domain controller chip and guides the domain controller chip into normal operating mode.

12. The domain controller wake-up system according to claim 1, characterized in that, After the domain controller chip is powered on, it determines whether it is the first time to start. If it is not the first time to start, then proceed to step S1, where the first boot program runs to guide the fast boot program into normal working mode; if it is the first time to start, then proceed directly to step S3, where the second boot program runs to guide the normal boot program into normal working mode.

13. The domain controller wake-up system according to claim 12, characterized in that, The initial state of the wake-up domain inside the domain controller chip is 1. After the application finishes running, the wake-up domain state is set to 0. When the domain controller chip is powered on, if the internal wake-up domain state is 1, the second bootloader is selected to run; if the internal wake-up domain state is 0, the first bootloader is selected to run.

14. The domain controller wake-up system according to claim 13, characterized in that, The domain controller chip has a hibernation mode random access memory, and the fast startup program is stored in the hibernation mode random access memory.

15. The domain controller wake-up system according to claim 14, characterized in that, The hibernation mode memory has a separate power supply system, and the power supply system of the hibernation mode memory provides normal power supply when the domain controller chip is in hibernation mode.

16. The domain controller wake-up system according to claim 14, characterized in that, Step S5 includes the following steps: Step S501. Activate all vehicle functions; Step S502. Periodically monitor whether the domain controller chip has a sleep requirement. If so, proceed to step S503; otherwise, proceed to step S502. Step S503. Set the wake-up domain state to 0; Step S504. Mirror the code of the fast startup program in the non-volatile memory area to the hibernation mode memory; Step S505. Execute the domain controller chip's sleep procedure until the sleep conditions are met, causing the domain controller chip to enter a low-power mode.

17. The domain controller wake-up system according to claim 11, characterized in that, In step S5, when starting each vehicle function, the relevant peripheral drivers of the domain controller chip will be reinitialized, so that the CAN routing table information set in the normal startup procedure will be updated, and the domain controller chip will configure CAN message routing according to the new CAN routing table.

18. The domain controller wake-up system according to claim 11, characterized in that, Step S4 includes the following steps: Step S401. Initialize the functional modules necessary for the domain controller chip in the normal startup procedure; Step S402. Initialize the system clock required by the domain controller chip during the normal startup procedure; Step S403. Initialize the wake-up frame interrupt timer in the normal startup procedure, so that the wake-up frame interrupt timer starts counting with the period of the system clock; Step S404. Initialize the port attributes required for the system to run in the normal startup procedure, that is, configure the domain controller chip I / O pin attributes related to the system to run in the normal startup procedure; Step S405. Load CAN firmware, that is, mirror the binary file of the CAN firmware required by the CAN driver to the corresponding location in the system kernel space, so that the CAN driver can call it when the domain controller chip sends and receives CAN messages; Step S406. CAN driver initialization; Step S407. Set the CAN port status; Step S408. Message routing and forwarding are performed according to the CAN routing table rules; Configure the initialization settings for other functional modules of the normal startup program.

19. The domain controller wake-up system according to claim 18, characterized in that, The necessary functional modules for a normal startup process include the chip's power supply module, reset control module, and system integration module; The system clocks required for a normal startup procedure include the phase-locked loop (PLL) clock and peripheral clocks.

20. The domain controller wake-up system according to claim 18, characterized in that, In step S405, CAN driver initialization includes setting the working mode of the CAN controller, CAN bus clock frequency, CAN bus message format, CAN message transmit / receive buffer, and CAN interrupt service, which are used to ensure the driver configuration required for normal CAN message transmission and reception, as well as configuring the CAN routing table information in the software or hardware system. In step S406, setting the CAN port status includes setting the CAN controller operating mode of all CAN lines where the wake-up frame message is located to startup mode, and setting the STB pin attributes of the wake-up frame CAN port.

21. The domain controller wake-up system according to claim 20, characterized in that, If the STB pin of the CAN port on the CAN line where the wake-up frame message is located is initialized to a low level in step S404, then step S406 does not need to set the STB pin attribute of the wake-up frame CAN port; otherwise, step S406 sets the STB pin attribute of the wake-up frame CAN port to a low level.

22. The domain controller wake-up system according to claim 18, characterized in that, In step S407, after setting the initialization configuration of other functional modules of the normal startup program, the following steps are performed: S4071. Periodically detect whether the wake-up frame interrupt timer has reached the predetermined sending time of the wake-up frame; if it has, proceed to step S4073. Otherwise, proceed to step S4072; S4072. Perform a built-in watchdog register overload operation (commonly known as the watchdog feeding operation in embedded development), and then execute step S4071; S4073. Set the wake-up frame message format as required, and then call the CAN driver interface to send the wake-up frame message to the CAN bus; S4074. Set the target of the next stage startup of the domain controller chip to the application program, and proceed to step S5.

Images