CN113189907A - Vehicle-mounted system recovery method and device - Google Patents

Abstract

The embodiment of the application provides a vehicle-mounted system recovery method and a device, wherein the method comprises the following steps: after the MCU determines that the vehicle-mounted system cannot be normally started from the system chip, the starting mode of the vehicle-mounted system is switched to a standby starting mode, the standby starting mode is used for starting the vehicle-mounted system from a standby medium, a mirror image of system data of the vehicle-mounted system is stored in the standby medium, then the MCU powers on the system chip, so that the vehicle-mounted system is started from the standby medium, at the moment, the system chip can write the system data in the standby medium onto the system chip in a flashing mode, and the vehicle-mounted system can be recovered to be normal after being repeatedly started. In the whole recovery process, maintenance personnel only need to provide a standby medium for storing system data, so that on one hand, the operation is simple, the risk of misoperation of the maintenance personnel is reduced, on the other hand, the machine does not need to be dismounted or replaced, and the user experience is improved.

Description

Vehicle-mounted system recovery method and device

Technical Field

The present application relates to the field of automotive electronics, and more particularly, to a method and an apparatus for recovering an onboard system.

Background

In order to gradually improve the riding experience of users, the vehicle-mounted system is more and more intelligent. When the vehicle-mounted system is normally started, various functions such as automatic driving, auxiliary driving, navigation, entertainment and the like can be realized, but in actual use, the vehicle-mounted system is often damaged, so that a user cannot normally use the vehicle-mounted system.

The traditional method is to re-write the software for the user by a maintenance person changing or removing the machine. For users, the method not only wastes a lot of time, but also has the risk of human maintenance misoperation, and the user experience is not good.

Disclosure of Invention

The application provides a vehicle-mounted system recovery method and device, so that under the condition that the vehicle-mounted system is damaged, a maintenance worker can complete recovery of the vehicle-mounted system only by providing a standby medium in which system data are stored, operation is simple, the risk of misoperation of the maintenance worker is reduced, and user experience is improved.

In a first aspect, the present application provides a vehicle-mounted system recovery method, including: a Motor Control Unit (MCU) determines that the vehicle-mounted system cannot be started normally from a system chip; the MCU switches the starting mode of the vehicle-mounted system into a standby starting mode, the standby starting mode is used for starting the vehicle-mounted system from a standby medium, and a mirror image of system data of the vehicle-mounted system is stored in the standby medium; the MCU powers on the system chip to enable the vehicle-mounted system to be started from the standby medium; and the MCU controls the system chip to write the system data in the standby medium onto the system chip in a flashing manner.

Based on above-mentioned technical scheme, MCU confirms that on-vehicle system can't start the back, the reserve start mode of accessible starts on-vehicle system from reserve medium, and then control system chip writes the system data in the reserve medium on the system chip, whole on-vehicle system's recovery process need not tear the machine or change the machine, maintenance personal only need with reserve medium insert reserve medium interface can, moreover, the operation is simple, and maintenance personal misoperation's risk has been reduced, also can avoid tearing the machine or changing the bad experience that brings for the user simultaneously.

With reference to the first aspect, in some possible implementation manners of the first aspect, the determining, by the MCU, that the vehicle-mounted system cannot be normally started from the system chip includes: and if the MCU does not receive a handshake signal of successful startup of the vehicle-mounted system within a preset time after the system chip is powered on, determining that the vehicle-mounted system cannot be started normally from the system chip.

With reference to the first aspect, in some possible implementation manners of the first aspect, if the MCU does not receive a successful start-up handshake signal of the vehicle-mounted system within a preset time period after the system chip is powered on, it is determined that the vehicle-mounted system cannot be normally started from the system chip, including: and the MCU powers on the system chip for multiple times, and does not receive a handshake signal of successful start-up of the vehicle-mounted system within a preset time length after each power-on, so that the vehicle-mounted system cannot be normally started from the system chip.

Optionally, the spare medium may include: secure Digital (SD) card, Universal Serial Bus (USB) flash disk, embedded multimedia card (EMMC), or Universal Flash Storage (UFS).

With reference to the first aspect, in some possible implementations of the first aspect, the method further includes: the MCU determines whether the standby medium is inserted into the standby medium interface by detecting the level of the standby medium detection pin; when the level of the standby medium detection pin is high, the standby medium is not inserted into the standby medium interface; when the level of the standby medium detection pin presents a low level, the standby medium is inserted into the standby medium interface.

With reference to the first aspect, in some possible implementations of the first aspect, the method further includes: and after receiving the prompt of completing the flash, the MCU controls the vehicle-mounted system to start from the system chip again.

In a second aspect, the present application provides an on-board system recovery apparatus, comprising means for implementing the method of the first aspect as well as any one of the possible implementations of the first aspect. It should be understood that the respective modules or units may implement the respective functions by executing the computer program.

In a third aspect, the present application provides an on-board system recovery apparatus, including a processor, where the processor is configured to execute the on-board system recovery method described in any one of the possible implementation manners of the first aspect.

The apparatus may also include a memory to store instructions and data. The memory is coupled to the processor, which when executing instructions stored in the memory, may implement the methods described in the above aspects. The apparatus may also include a communication interface for the apparatus to communicate with other devices, which may be, for example, a transceiver, circuit, bus, module, or other type of communication interface.

Optionally, the vehicle-mounted system recovery apparatus in the second aspect or the third aspect is an MCU.

In a fourth aspect, the present application provides a chip system comprising at least one processor configured to support the implementation of the functionality referred to in the first aspect and any one of the possible implementations of the first aspect, for example, to receive or process data and/or information referred to in the above methods.

In one possible design, the system-on-chip further includes a memory to hold program instructions and data, the memory being located within the processor or external to the processor.

The chip system may be formed by a chip, and may also include a chip and other discrete devices.

Optionally, the system chip is configured in the MCU.

In a fifth aspect, the present application provides a computer-readable storage medium comprising a computer program which, when run on a computer, causes the computer to carry out the method of the first aspect as well as any one of the possible implementations of the first aspect.

In a sixth aspect, the present application provides a computer program product comprising: a computer program (which may also be referred to as code, or instructions), which when executed, causes a computer to perform the first aspect and the method of any possible implementation of the first aspect.

It should be understood that the second aspect to the sixth aspect of the present application correspond to the technical solutions of the first aspect of the present application, and the beneficial effects achieved by the aspects and the corresponding possible implementations are similar and will not be described again.

Drawings

Fig. 1 is a schematic view of an application scenario provided in an embodiment of the present application;

fig. 2 is a schematic structural diagram of an intelligent cabin system 200 provided in an embodiment of the present application;

FIG. 3 is a schematic flow chart diagram of an in-vehicle system recovery method 300 provided by an embodiment of the present application;

FIG. 4 is a detailed flowchart of a vehicle system recovery method according to an embodiment of the present disclosure;

FIG. 5 is a schematic block diagram of an in-vehicle system recovery apparatus provided in an embodiment of the present application;

fig. 6 is another schematic block diagram of an on-board system recovery device provided in an embodiment of the present application.

Detailed Description

The technical solution in the present application will be described below with reference to the accompanying drawings.

Fig. 1 is a schematic view of an application scenario provided in an embodiment of the present application. An application scenario of the method provided by the embodiment of the present application will be described below with reference to fig. 1.

With the continuous development of internet technology and automobile technology, the vehicle-mounted system is more and more intelligent, not only can realize functions such as navigation and driving assistance, but also can provide entertainment items such as audio and video playing. Fig. 1 shows an example of a schematic structural diagram of a vehicle-mounted system recovery method provided in an embodiment of the present application, where as shown in fig. 1, a vehicle-mounted system is installed on the vehicle, the vehicle-mounted system includes a display screen, and the vehicle-mounted system provides various functions for a user through the display screen. The vehicle-mounted system can realize the above functions when being normally started and operated, but in the actual use process, the condition that the vehicle-mounted system cannot be normally started may occur, and particularly, the vehicle-mounted system cannot be started from a system chip. This situation may also be referred to as "tiling" of the on-board system. In this case, the abnormal power failure of the vehicle may be caused, or the data in the system chip of the vehicle-mounted system may be damaged. The traditional method for solving the problem is to replace or remove the machine for the user and rewrite the vehicle-mounted system for the user, the method is not only complex in operation, but also has a high risk of human misoperation, and the user is also poor in experience due to replacement or removal of the machine, and particularly, the user who love the vehicle, such as a dead person, complains about very large.

The application provides a vehicle-mounted system recovery method, which can switch the starting mode of a vehicle-mounted system into a standby starting mode by an MCU (micro control unit) after the vehicle-mounted system changes bricks, performs flash recovery of system data, only needs to provide a standby medium, does not need additional equipment, is simple to operate, reduces the risk of misoperation of working personnel, and improves user experience.

The following describes the vehicle-mounted system recovery method provided in the embodiment of the present application in detail by taking an intelligent cabin system as an example, and it should be understood that the intelligent cabin system is only an example of the vehicle-mounted system. One possible product form of intelligent cabin system is a System On Chip (SOC), which may be referred to as intelligent cabin SOC, for example.

For better understanding of the embodiments of the present application, the following first describes in detail the structure of the intelligent cabin applicable to the onboard system recovery method provided by the present application with reference to fig. 2. Fig. 2 is a schematic structural diagram of an intelligent cabin system provided in an embodiment of the present application.

As shown in fig. 2, the intelligent cabin system 200 may include: the intelligent vehicle comprises an intelligent cabin SOC, an MCU, a camera, one or more display screens, a Digital Signal Processing (DSP), a USB (universal serial bus), an SD card cassette, an SD card detection pin, a starting mode pin, a communication interface and other peripherals. It should be understood that the SD card is only an example of a spare medium, and the SD card socket is an example of a spare medium interface. The SD card line is connected to the external SD card cassette, the starting mode pin and the SD card detection pin of the intelligent cabin SOC are connected to the MCU, and the display screen, the camera, the USB and the DSP are connected to the intelligent cabin SOC. The MCU may perform power management, Controller Area Network (CAN) management, CAN diagnosis, and the like. The intelligent cabin SOC is mainly responsible for display of a display screen, camera management, DSP control, USB and management of other peripheral equipment. The display screen can be used for displaying application programs, menus, options and the like, and can also be used as an operation interface contacted when the vehicle-mounted equipment is adjusted. The communication interface is used for realizing communication connection between the MCU and the intelligent cabin SOC.

For example, in this embodiment of the application, the intelligent cockpit system may display a prompt message indicating that the system data is successfully written by the mirror image through the display screen, so as to prompt a maintenance worker to pull out the SD card from the SD card socket. The MCU can be used for electrifying the SOC of the intelligent cabin, controlling the switching of the starting modes of the system of the intelligent cabin and the like. The level state presented by the detection pin of the SD card can be used for reflecting whether the SD card is inserted into the SD card socket or not. The SD card holder is an example of a media interface. The media interface may be used to identify the media. For example, the SD card socket may be used to identify an SD card. The embodiment of the present application is not limited to the type of media and the type of media interface. For example, the SD card may be replaced with a USB flash drive, a USB interface may be used to identify the USB flash drive, and so on. Embodiments of the present application include, but are not limited to, the foregoing.

It is to be understood that the illustrated structure of the embodiment of the present application does not constitute any limitation to the intelligent cabin system 200. In other embodiments, the intelligent cabin system 200 may include more or fewer components than shown, or combine certain components, or split certain components, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The following describes in detail a vehicle-mounted system recovery method provided in an embodiment of the present application with reference to the accompanying drawings. It should be understood that the embodiments shown below will describe the specific flow of the method with the MCU as the execution subject, but should not constitute any limitation to the execution subject of the method. The method provided by the embodiment of the present application can be executed as long as it is possible to execute a program in which codes of the method provided by the embodiment of the present application are recorded.

Fig. 3 is a schematic flowchart of an in-vehicle system recovery method provided in an embodiment of the present application. The method 300 shown in fig. 3 may include S310 to S350, and the respective steps of fig. 3 will be described in detail below.

S310, the MCU determines whether the vehicle-mounted system can be started normally from the system chip.

The normal starting means that the vehicle-mounted system can be started from the system chip after the MCU powers on the system chip.

Take intelligent cockpit SOC as an example. After the MCU powers on the intelligent cabin SOC, the intelligent cabin system can be started from the SOC, and the intelligent cabin SOC can be started normally. If the intelligent cabin system cannot be started from the SOC, the SOC of the intelligent cabin cannot be started normally.

One possible implementation manner is that the system chip may send a handshake signal of successful startup to the MCU after power-on. The MCU can judge whether the vehicle-mounted system is normally started or not by receiving the handshake signal of successful startup of the vehicle-mounted system or not. For example, if the MCU receives a handshake signal indicating that the vehicle-mounted system is successfully started, the MCU may determine that the vehicle-mounted system is normally started from the system chip, and the vehicle-mounted system may normally operate and use. If the MCU does not receive the handshake signal of successful startup of the vehicle-mounted system, the MCU can determine that the vehicle-mounted system cannot be started normally from the system chip.

In a possible design, if the MCU does not receive a successful start-up handshake signal of the vehicle-mounted system within a preset time period after the system chip is powered on, it is determined that the vehicle-mounted system cannot be normally started from the system chip. It should be understood that the preset time period may be a preset value, and may be 30 seconds or 1 minute, and the length of the preset time period is not limited in the embodiment of the present application. The preset time length can be configured in the MCU in advance, the MCU can automatically start timing after the system chip is powered on, and the vehicle-mounted system can not be started normally from the system chip under the condition that the timed time length reaches the preset time length and does not receive a handshake signal from the system chip.

In order to avoid misjudgment, the MCU can also judge whether the vehicle-mounted system can be started from the system chip according to the receiving condition of the handshake signals after multiple times of power-on. Illustratively, the MCU may repeatedly execute the following steps until the number of repetitions reaches a preset value, or, a handshake signal is received: and within a preset time length after the system chip is powered on, a handshake signal of successful start-up of the vehicle-mounted system is not received, and the system chip is reset.

If the MCU receives a handshake signal of successful startup within a preset time after one or more times of electrification, the MCU indicates that the vehicle-mounted system can be started normally from the system chip, and the execution of the steps can be stopped. And if the MCU does not receive the handshake signal of successful startup after multiple times of power-on, determining that the vehicle-mounted system cannot be started normally from the system chip. The preset value of the power-on times is not limited in the embodiment of the present application, and may be, for example, two times, three times, or more times.

In an example, the MCU powers on the intelligent cabin SOC, if the handshaking signal of the intelligent cabin SOC successfully started up is not received within the preset time, the intelligent cabin SOC is reset, and the power is turned on again, so that the MCU does not receive the handshaking signal of the intelligent cabin SOC successfully started up for three times, and the MCU determines that the intelligent cabin SOC cannot be started up normally.

In another example, the MCU powers on the intelligent cabin SOC, does not receive a handshake signal that the intelligent cabin SOC is successfully powered on within a preset time period, resets the intelligent cabin SOC, and powers on again, and after the MCU powers on, the MCU receives the handshake signal that the intelligent cabin SOC is successfully powered on, and the intelligent cabin SOC enters a normal start mode, that is, the intelligent cabin SOC can be started normally.

It should be understood that setting the preset duration and powering on the system chip for multiple times can avoid the MCU from misjudging to some extent.

After determining whether the vehicle-mounted system can be started normally from the system chip, the MCU can execute different steps according to the judgment result. For example, in the case where the slave system chip cannot be normally started, S320 to S350 are executed; in case of being able to start up normally from the system chip, S360 may be executed to start up the in-vehicle system directly from the system chip. Since the process of starting the on-board system from the system chip can be referred to the prior art, the detailed description is omitted here for brevity. The processing in the case where normal boot from the system chip is impossible is explained in detail herein.

And S320, switching the starting mode of the vehicle-mounted system to a standby starting mode by the MCU.

The backup start mode is used for starting the vehicle-mounted system from a backup medium, wherein a mirror image of system data of the vehicle-mounted system is stored in the backup medium, and the backup medium is identified through a backup medium interface. The standby medium detection pin is connected with the standby medium interface from the inside, when the vehicle-mounted system is normally started from the system chip, the original starting mode pin normally runs, and when the vehicle-mounted system cannot be normally started from the system chip, the MCU switches the starting mode of the vehicle-mounted system into the standby starting mode, namely switches the starting mode pin into the standby medium detection pin. The spare medium may be any storage medium, and the type of the spare medium is not limited in the embodiments of the present application.

The mirror image is a storage form of a file, a completely same copy of data of one disk on the other disk is the mirror image, and a specific series of files are made into a single file according to a certain format so as to be convenient for a user to use. In the embodiment of the present application, the mirror image of the system data includes all data of the vehicle-mounted system, such as a system file, partition table information, a boot file, and the like. After the MCU determines that the vehicle-mounted system cannot be started from the system chip normally, the level of the standby medium detection pin can be detected so as to determine whether the standby medium is inserted into the standby medium interface. The spare media interface may be, for example, the SD card socket described above, for identifying an SD card; the USB flash drive can also be a USB interface used for identifying a USB flash drive, and can also be other interfaces used for identifying a spare medium.

It should be appreciated that the backup media detect pin is internally connected to the backup media interface, and the level state of the backup media detect pin may reflect whether the backup media is inserted into the backup media interface. When the level of the standby medium detection pin is low, the standby medium is inserted into the standby medium interface; when the level of the spare medium detection pin is high level, the spare medium is not inserted into the spare medium interface.

Illustratively, the MCU monitors the level of the backup medium detection pin, and when the level of the backup medium detection pin is low, it may determine that a backup medium is inserted into the backup medium interface, and switch the start mode of the vehicle-mounted system to the backup start mode, that is, switch the start mode pin to the backup medium detection pin.

By way of example, and not limitation, the backup media may include: SD card, USB flash drive, EMMC or UFS.

S330, the MCU powers on the system chip so that the vehicle-mounted system is started from the standby medium.

The MCU switches the starting mode of the vehicle-mounted system into a standby starting mode, namely the vehicle-mounted system can be started from a standby medium. Wherein the starting of the vehicle-mounted system from the standby medium is understood as that the vehicle-mounted system loads the mirror image of the system data from the standby medium so as to start the vehicle-mounted system.

Illustratively, the backup medium stores a mirror image of system data of the vehicle-mounted system, the MCU powers on the system chip again, the vehicle-mounted system enters a backup start mode, and the vehicle-mounted system starts after the mirror image of the system data is loaded from the backup medium.

And S340, the MCU controls the vehicle-mounted system to write the system data in the standby medium onto the system chip in a flashing manner.

It should be understood that the vehicle-mounted system cannot be started from the system chip normally, and in the case that the system data on the system chip is damaged, the system data stored in the backup medium can be written onto the system chip.

The system data comprises system files, starting data, partition table information and the like of the vehicle-mounted system, the files are stored in the standby medium in a mirror image mode, and the system data in the standby medium is written on the system chip in a flashing mode, namely the system mirror image of the vehicle-mounted system is written on the system chip in a flashing mode.

One possible implementation manner is that after the vehicle-mounted system is started from the standby medium, the MCU control system chip writes the mirror image of the system data in the standby medium into the system chip in a flashing manner, so that the vehicle-mounted system can be started from the system chip normally. It should be understood that the system chip stores a flash program, which can be used for flash of the mirror image of the system data. The specific process of system data flashing can be referred to in the prior art, and embodiments of the present application are not described in detail herein.

And S350, the MCU controls the vehicle-mounted system to restart from the system chip.

And after the system data on the system chip is completely written, the MCU controls the vehicle-mounted system to start from the system chip again and enters a normal starting mode.

For example, after the system data is flushed, the MCU may receive a prompt signal indicating that the system data of the vehicle-mounted system is flushed successfully, and at this time, the system chip may be reset and powered on again, and after the system chip is powered on, a handshake signal indicating that the vehicle-mounted system is successfully started may be received, and the vehicle-mounted system enters a normal start mode. The specific process of the normal start mode can be referred to in the prior art and will not be described in detail here.

Optionally, after the system data is written, the vehicle-mounted system may prompt the user through the display screen, and after the user sees the prompt, the user may pull the spare medium out of the spare medium interface.

Next, the vehicle-mounted system takes an intelligent cabin system as an example, the standby medium takes an SD card as an example, and a specific flow of the vehicle-mounted system recovery method is described with reference to fig. 4, where fig. 4 is a specific flow chart of the vehicle-mounted system recovery method provided in the embodiment of the present application.

In an example, the MCU powers on the intelligent cabin SOC, further determines whether a handshake signal that the intelligent cabin system is successfully started up is waited for within a preset time period, and if the handshake signal that the intelligent cabin system is successfully started up is received within the preset time period, the normal start process is entered, and if the handshake signal is not received, the intelligent cabin SOC is reset, the MCU powers on the intelligent cabin SOC again, and continues to determine whether a handshake signal that the intelligent cabin system is successfully started up is received, and repeats the above process three times, and if the handshake signal that the intelligent cabin system is successfully started up is received in a process in which the MCU powers on the intelligent cabin SOC again many times, the normal start mode is entered. And if the starting-up successful handshake signals are not received for three times, the MCU monitors the level state of the detection pin of the SD card and detects whether the SD card is inserted. If the level is set to a high level state, it indicates that the SD card socket has no SD card inserted, and the system cannot complete recovery and needs to insert the SD card. If the level is in a low level state, it indicates that an SD card is inserted into the SD card seat, the MCU switches the starting mode of the intelligent cabin system into the SD card for starting, and powers on the intelligent cabin SOC again, after the power is on, the intelligent cabin system is started from the SD card, the intelligent cabin SOC writes the mirror image of the system data stored in the SD card into the SOC in a swiping mode, after the swiping is completed, prompt information is displayed through a display screen for prompting maintenance personnel to write successfully, the maintenance personnel extracts the SD card, the intelligent cabin system is restarted and enters a normal starting mode, and then the swiping and recovering process of the intelligent cabin system can be completed.

Based on the technical scheme, when the vehicle-mounted system is damaged, after the MCU determines that the vehicle-mounted system cannot be normally started from the system chip, the starting mode of the vehicle-mounted system is switched to a standby starting mode, the standby starting mode is used for starting the vehicle-mounted system from a standby medium, a mirror image of system data of the vehicle-mounted system is stored in the standby medium, then the MCU powers on the system chip to enable the vehicle-mounted system to be started from the standby medium, at the moment, the MCU controls the system chip to write the system data in the standby medium onto the system chip in a flashing mode, the vehicle-mounted system can be normally recovered after being repeatedly started, in the whole recovery process, a maintenance worker only needs to provide the standby medium in which the system data are stored, on one hand, the operation is simple, the risk of misoperation of the maintenance worker is reduced, on the other hand, the machine is not required to be dismounted or replaced, and the user experience is improved.

It is to be understood that the specific flow of the vehicle-mounted system recovery method provided by the embodiment of the present application is described above with reference to the drawings, which are only examples, and each step in the drawings is not necessarily required to be executed, and some steps may be skipped, for example. In addition, the execution sequence of each step is not fixed or limited to that shown in the figures, and the execution sequence of each step should be determined by the function and the inherent logic of each step.

Fig. 5 is a schematic block diagram of an on-board system recovery apparatus 500 provided in an embodiment of the present application. The apparatus 500 may be a chip system, or may also be an apparatus configured with a chip system, so as to implement the vehicle-mounted system recovery method in the foregoing method embodiment. In the embodiment of the present application, the chip system may be composed of a chip, and may also include a chip and other discrete devices. Alternatively, the on-board system recovery device may be, for example, the MCU in fig. 2, or a component configured in the MCU, such as a chip system.

As shown in fig. 5, the apparatus 500 may include a processor 510 and a communication interface 520. Wherein communication interface 520 may be used to communicate with other devices over a transmission medium such that the apparatus used in apparatus 500 may communicate with other devices. The communication interface 520 may be, for example, a transceiver, an interface, a bus, a circuit, or a device capable of performing a transceiving function. The processor 510 may utilize the communication interface 520 to input and output data and is used to implement the in-vehicle system recovery method described in the corresponding embodiment of fig. 3. In particular, the processor 510 may be configured to call a program in the memory to cause the above-mentioned apparatus to perform the method performed by the MCU in the embodiment shown in fig. 3.

Optionally, the apparatus 500 further comprises at least one memory 530 for storing program instructions and/or data. The memory 530 is coupled to the processor 510. The coupling in the embodiments of the present application is an indirect coupling or a communication connection between devices, units or modules, and may be an electrical, mechanical or other form for information interaction between the devices, units or modules. The processor 510 may cooperate with the memory 530. Processor 510 may execute program instructions stored in memory 530. At least one of the at least one memory may be included in the processor.

The specific connection medium between the processor 510, the communication interface 520 and the memory 530 is not limited in the embodiments of the present application. In fig. 5, the processor 510, the communication interface 520, and the memory 530 are connected by a bus 540. The bus 540 is shown in fig. 5 by a thick line, and the connection between other components is merely illustrative and not intended to be limiting. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 5, but this is not intended to represent only one bus or type of bus.

Fig. 6 is another schematic block diagram of an on-board system recovery apparatus 600 according to an embodiment of the present application. As shown in fig. 6, the apparatus 600 may include: a communication unit 610 and a processing unit 620.

Alternatively, the apparatus 600 may correspond to the MCU in the above method embodiments. For example, the apparatus 600 may correspond to the MCU in the above method embodiments, or a component configured in the MCU, such as a chip, a chip system, and the like. Also, the units in the apparatus 600 may be used to implement the corresponding flow executed by the MCU in the method 300 shown in fig. 3. For example, the processing unit 620 may be used to determine that the in-vehicle system cannot be normally started from the system chip; switching a starting mode of the vehicle-mounted system into a standby starting mode, wherein the standby starting mode is used for starting the vehicle-mounted system from a standby medium, and a mirror image of system data of the vehicle-mounted system is stored in the standby medium; powering on a system chip to enable the vehicle-mounted system to start from the standby medium; and the control system chip writes the system data in the standby medium onto the system chip in a flashing mode. For details, reference is made to the detailed description of the method embodiments, which is not repeated herein.

It should be understood that the division of the modules in the embodiments of the present application is illustrative, and is only one logical function division, and there may be other division manners in actual implementation. In addition, functional modules in the embodiments of the present application may be integrated into one processor, may exist alone physically, or two or more modules are integrated into one module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode.

The present application further provides a computer program product, the computer program product comprising: a computer program (which may also be referred to as code, or instructions), which when executed, causes a computer to perform the method performed by the MCU in the embodiment shown in fig. 3.

The present application also provides a computer-readable storage medium having stored thereon a computer program (also referred to as code, or instructions). When said computer program is run, it causes the computer to perform the method performed by the MCU in the embodiment shown in fig. 3.

It should be understood that the processor in the embodiments of the present application may be an integrated circuit chip having signal processing capability. In implementation, the steps of the above method embodiments may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The processor may be a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic device, or discrete hardware components. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor.

It will also be appreciated that the memory in the embodiments of the subject application can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. The non-volatile memory may be a read-only memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an electrically Erasable EPROM (EEPROM), or a flash memory. Volatile memory can be Random Access Memory (RAM), which acts as external cache memory. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), double data rate SDRAM, enhanced SDRAM, SLDRAM, Synchronous Link DRAM (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

Those of ordinary skill in the art will appreciate that the various illustrative logical blocks and steps (step) described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application. In the embodiments provided in the present application, it should be understood that the disclosed apparatus, device and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (10)

1. A vehicle-mounted system recovery method is characterized by comprising the following steps:

the motor control unit MCU determines that the vehicle-mounted system cannot be started normally from the system chip;

the MCU switches a starting mode of the vehicle-mounted system into a standby starting mode, the standby starting mode is used for starting the vehicle-mounted system from a standby medium, and a mirror image of system data of the vehicle-mounted system is stored in the standby medium;

the MCU powers on the system chip so that the vehicle-mounted system is started from the standby medium;

and the MCU controls the system chip to write the system data in the standby medium onto the system chip in a flashing manner.

2. The method of claim 1, wherein the MCU determining that the in-vehicle system cannot be normally started from the system chip comprises:

and if the MCU does not receive a handshake signal of successful startup of the vehicle-mounted system within a preset time after the system chip is powered on, determining that the vehicle-mounted system cannot be started normally from the system chip.

3. The method of claim 2, wherein if the MCU does not receive a successful boot handshake signal of the vehicle-mounted system within a preset time period after powering on the system chip, determining that the vehicle-mounted system cannot be normally started from the system chip comprises:

and the MCU powers on the system chip for multiple times, and does not receive a handshake signal of successful start-up of the vehicle-mounted system within a preset time length after each power-on, so that the vehicle-mounted system cannot be normally started from the system chip.

4. The method of any of claims 1 to 3, wherein the backup medium comprises: a secure digital SD card, a universal serial bus USB flash disk, an embedded multimedia card EMMC or a universal flash memory UFS.

5. The method of claim 1, wherein the method further comprises:

the MCU determines whether the standby medium is inserted into the standby medium interface by detecting the level of the standby medium detection pin;

when the level of the spare medium detection pin is high, the spare medium is not inserted into the spare medium interface; when the level of the standby medium detection pin presents a low level, the standby medium is inserted into the standby medium interface.

6. The method of claim 1, wherein the method further comprises:

and after receiving the prompt of completing the flash, the MCU controls the vehicle-mounted system to restart from the system chip.

7. An in-vehicle system recovery apparatus comprising a processor for executing computer instructions stored in a memory to cause the apparatus to perform the method of any of claims 1 to 6.

8. An on-board system recovery device, characterized by comprising means for implementing the method of any one of claims 1 to 6.

9. A computer-readable storage medium, comprising a computer program which, when run on a computer, causes the computer to perform the method of any one of claims 1 to 6.

10. A computer program product, comprising a computer program which, when executed, causes a computer to perform the method of any one of claims 1 to 6.

Images