Instrument display screen failure processing method and system, equipment and storage medium

Abstract

The invention provides an instrument display screen failure processing method, system and equipment and a storage medium, and relates to the technical field of vehicle equipment control, and the method comprises the steps that firstly, the running state of an SOC of an instrument display screen controlled through a first low-speed control bus is detected through a hardware arbitration unit; when it is detected that the SOC is abnormal, the SOC is restored to the initial state, and a reset signal is locked; and turning over the bus selection signal, switching the bus control right to the MCU, and controlling the instrument display screen based on the hardware bypass of the second low-speed control bus. Thus, when the main processor SOC is abnormal, the SOC is physically isolated from the system bus immediately through hardware forced reset, and meanwhile, the control right of a bottom layer control bus of an instrument display screen is forcibly switched to the MCU from the SOC. The MCU directly sends an instruction to a driving IC of an instrument screen through the bypass which is just taken over, and key parameters such as the vehicle speed and the gear are displayed in the most basic mode.

Description

Technical Field

[0001] This application relates to the field of vehicle equipment control technology, and in particular to a method, system, device and storage medium for handling instrument display failure. Background Technology

[0002] With the continuous development of automotive electronics technology, fully digital instrument clusters (LCDs) have been widely used in modern cars. LCDs typically employ high-performance system-on-a-chip (SoC) as their core driving component to achieve rich display functions and a good user experience. However, the complex software stack of the SoC has become a major bottleneck in system reliability. For example, abnormal situations such as software deadlock, kernel crashes, or chip-level hardware failures can all cause a "black screen" phenomenon in the LCD. This "black screen" event not only affects the driving experience but also directly violates the ISO 26262 functional safety standard's requirement for the continuous availability of ASIL B / C level critical information (such as vehicle speed and gear).

[0003] Furthermore, when a vehicle's instrument panel goes black due to hardware malfunctions, software errors, or external interference, it poses a significant safety hazard to the driver and affects driving safety. Therefore, ensuring that the instrument panel system continues to display critical information under abnormal conditions is a pressing technical problem that needs to be solved. Summary of the Invention

[0004] To address the above problems, this application provides a method for handling instrument display screen failures, including the following:

[0005] Firstly, this application provides a method for handling the failure of an instrument display screen, the method comprising:

[0006] The hardware arbitration unit detects the operating status of the main processor SOC, which controls the instrument display screen through the first low-speed control bus;

[0007] When the hardware arbitration unit detects an anomaly in the SOC, it restores the SOC to its initial state and locks the reset signal;

[0008] By flipping the bus selection signal and using a hardware bypass circuit, the control of the instrument display screen is switched from the SOC to the instrument safety microcontroller MCU, and the control of the instrument display screen is taken over through the second low-speed control bus.

[0009] Optionally, after switching control of the instrument display screen from the SOC to the instrument safety microcontroller MCU via a hardware bypass circuit, and taking over control of the instrument display screen via a second low-speed control bus, the method further includes:

[0010] After the MCU detects a change in bus control, it immediately executes a preset emergency display task; at the same time, the MCU checks whether the chip select and clock line of the second low-speed control bus are in an idle state.

[0011] When the chip select and clock line of the second low-speed control bus are in an idle state, it is considered that the main processor has completely released the bus and executes the emergency display rendering process.

[0012] Optionally, the emergency display rendering process includes:

[0013] The instrument display screen is initialized via the second low-speed control bus, and a display area is set on the instrument display screen;

[0014] Read the data to be displayed and display the data in the display area.

[0015] Optionally, reading the data to be displayed and displaying the data to be displayed in the display area includes:

[0016] After reading the data to be displayed, the MCU reads the corresponding glyph data from the preset memory, inputs the read glyph data into the constructed row buffer, and sends the data in the row buffer to the display area;

[0017] Repeat the above steps to complete the periodic rendering of the display area.

[0018] Optionally, the method further includes:

[0019] When the SOC is restarted and attempts to recover, it verifies with the MCU through a preset verification protocol;

[0020] Once the preset verification protocol is successfully verified, the SOC gains control.

[0021] Optionally, the SOC anomaly includes:

[0022] The following are possible causes and conditions: the SOC watchdog timer fails to receive a response signal within the specified time, power failure occurs, the SOC temperature exceeds the preset temperature threshold, the SOC clock signal stops, there is no voltage signal on the power cord of the instrument display, and the instrument display fails to display correctly.

[0023] Secondly, this application provides an instrument display screen failure handling system, which includes a hardware arbitration unit, a main processor SOC, a safety microcontroller MCU, a first low-speed control bus, a second low-speed control bus, and a bus switch;

[0024] The hardware arbitration unit is used to detect the operating status of the main processor SOC;

[0025] The SOC is used to control the instrument display screen via a first low-speed control bus.

[0026] The hardware arbitration unit is also used to restore the SOC to its initial state and lock the reset signal when an abnormality is detected in the SOC.

[0027] The bus switcher is used to toggle the bus selection signal when the hardware arbitration unit detects an abnormality in the SOC, and switch the control of the instrument display screen from the SOC to the instrument safety microcontroller MCU through the hardware bypass circuit, and take over the control of the instrument display screen through the second low-speed control bus.

[0028] Optionally, the MCU is also used to immediately execute a preset emergency display task after detecting a change in bus control; and simultaneously detect whether the chip select and clock line of the second low-speed control bus are in an idle state.

[0029] When the chip select and clock line of the second low-speed control bus are in an idle state, it is considered that the main processor has completely released the bus and executes the emergency display rendering process.

[0030] Optionally, the emergency display rendering process includes:

[0031] The instrument display screen is initialized via the second low-speed control bus, and a display area is set on the instrument display screen;

[0032] Read the data to be displayed and display the data in the display area.

[0033] Optionally, reading the data to be displayed and displaying the data to be displayed in the display area includes:

[0034] After reading the data to be displayed, the MCU reads the corresponding glyph data from the preset memory, inputs the read glyph data into the constructed row buffer, and sends the data in the row buffer to the display area;

[0035] Repeat the above steps to complete the periodic rendering of the display area.

[0036] Optionally, when the SOC is restarted and attempts to recover, it verifies with the MCU using a preset verification protocol;

[0037] Once the preset verification protocol is successfully verified, the SOC gains control.

[0038] Optionally, the SOC malfunction includes one or more of the following: the SOC watchdog timer fails to receive a response signal within a specified time, the power supply fails, the SOC temperature exceeds a preset temperature threshold, the SOC clock signal stops, the power cord of the instrument display has no voltage signal, and the instrument display fails to display normally.

[0039] Thirdly, this application provides an apparatus comprising a memory and a processor, the memory for storing instructions or code, and the processor for executing the instructions or code to cause the apparatus to perform the instrument display failure handling method described in any of the implementations of the first aspect.

[0040] Fourthly, this application provides a computer-readable storage medium storing code, wherein when the code is executed, a device executing the code implements the instrument display screen failure handling method described in any of the implementations of the first aspect.

[0041] This application provides a method for handling instrument display screen failures. When executing the method, the operating status of the main processor (SOC) is first detected by a hardware arbitration unit. The SOC controls the instrument display screen via a first low-speed control bus. When the hardware arbitration unit detects an anomaly in the SOC, it restores the SOC to its initial state and locks the reset signal. The bus selection signal is then toggled, and through a hardware bypass circuit, control of the instrument display screen is switched from the SOC to the instrument safety microcontroller (MCU), which then takes over control of the instrument display screen via a second low-speed control bus.

[0042] In this way, by constructing a hardware bypass circuit that is physically independent of the main processor SOC's data processing link and directly connects to the instrument cluster display's underlying control bus, combined with a hardware forced reset mechanism, the most thorough physical isolation of a faulty SOC is achieved. This ensures that when the main processor SOC malfunctions, a hardware forced reset immediately physically isolates the SOC from the system bus, while simultaneously forcibly switching control of the instrument cluster display's underlying control bus from the SOC to the MCU. The MCU then directly sends instructions to the instrument cluster's driver IC through this newly taken-over bypass, displaying key parameters such as vehicle speed and gear position in the most basic way. This allows for rapid provision of reliable information to the driver via the backup controller in the event of a main processor malfunction, thereby improving the reliability and safety of the instrument cluster system and ensuring driving safety. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in this embodiment or the prior art, the drawings used in the description of the embodiment or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 A flowchart of a method for handling instrument display screen failure provided in this application embodiment;

[0045] Figure 2 This is a schematic diagram of the structure of an instrument display screen failure handling system provided in an embodiment of this application. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0047] Figure 1 This is a flowchart illustrating a method for handling instrument display screen failures, provided in an embodiment of this application. (In conjunction with...) Figure 1 As shown, the instrument display screen failure handling method provided in this application embodiment may include:

[0048] S101, The hardware arbitration unit detects the operating status of the main processor SOC, and the SOC controls the instrument display screen through the first low-speed control bus.

[0049] The hardware arbitration unit is a critical security hardware module, composed entirely of hardware logic and independent of any software. Its primary task is to monitor the operating status of the main processor (SOC) and ensure the SOC's proper functioning by detecting vital signs such as the Challenge-Response WDT signal. The first low-speed control bus, SPI-1, is the communication interface used by the SOC to configure and control the display driver IC; it acts as a bridge between the SOC and the instrument display screen.

[0050] The SOC, or main processor, is the core control unit of the system. It fully controls the vehicle's instrument display screen through a high-speed video interface (MIPI-DSI / LVDS) and a first low-speed control bus (SPI-1), responsible for presenting rich graphical interfaces and handling complex display tasks.

[0051] Under normal operating conditions of the SOC, the hardware arbitration unit will confirm that all signal messages of the SOC are functioning correctly and will allocate SPI bus permissions for the instrument panel to the SOC. At this time, the SOC controls the display driver IC via the SPI-1 bus, while the instrument safety MCU performs tasks such as system monitoring and CAN message processing in the background to ensure stable system operation.

[0052] When a SOC (System-on-a-Chip) failure is detected, the hardware arbitration unit immediately executes three key actions: First, it forcibly isolates the SOC by pulling the RST_N signal low, cutting off its power to prevent the fault from propagating; second, it interrupts and wakes up the MCU by pulling the Failsafe_IRQ signal low, enabling the MCU to take over control; finally, it forcibly switches the bus by toggling the Bus_Sel signal, changing control of the data bus to ensure the system can continue operating. These actions are executed instantaneously in parallel to minimize system downtime and maintain system stability. In this way, the hardware arbitration unit provides a robust fault detection and response mechanism, ensuring the reliability and safety of the instrument failure protection system.

[0053] S102. When the hardware arbitration unit detects an abnormality in the SOC, it restores the SOC to its initial state and locks the reset signal.

[0054] When the hardware arbitration unit detects an anomaly in the SOC, it takes a series of measures to ensure the stability and security of the system. First, the hardware arbitration unit identifies the abnormal conditions of the SOC, which may include one or more of the following: the watchdog timer fails to receive a response signal within a specified time, power failure, the SOC temperature exceeds a preset temperature threshold, the SOC clock signal stops, there is no voltage signal on the power line of the instrument display, and the instrument display fails to display normally.

[0055] Once any of the above anomalies are detected, the hardware arbitration unit will perform the following procedure:

[0056] Setting the SOC_Reset signal to active and locking it puts the SOC into a permanent hardware reset state. In this state, all input / output (I / O) ports of the SOC will be in a high-impedance state, meaning that the SOC will be completely physically isolated from the system bus to prevent its abnormal state from affecting the entire system.

[0057] The hardware arbitration unit generates a forced reset signal called ST_N (hardware reset signal). When this signal goes low, it triggers the SOC to enter a permanent hardware reset state, further ensuring that all I / O ports of the SOC are in a high-impedance state, achieving complete physical isolation from the system bus.

[0058] Through this series of operations, the hardware arbitration unit can respond quickly when an SOC malfunctions, restoring the SOC to its initial state and locking the reset signal to ensure system stability and security.

[0059] S103. Flip the bus selection signal and switch the control of the instrument display screen from the SOC to the instrument safety microcontroller MCU through the hardware bypass circuit, and take over the control of the instrument display screen through the second low-speed control bus.

[0060] After the SOC is forcibly isolated, the hardware arbitration unit toggles the state of the Bus_Select signal, which is a control signal output from the hardware arbitration unit to the bus switcher MUX. When the state of the Bus_Select signal is toggled, the MUX will forcibly switch control of the underlying control bus SPI_Ctrl of the instrument display from the SOC to the MCU.

[0061] During this switching process, the second low-speed control bus SPI-2 plays a crucial role. SPI-2 is a dedicated SPI bus for the safety MCU and a key component for implementing the hardware bypass function in this application. In the event of a SOC failure, the MCU directly writes safety information to the display screen via SPI-2, ensuring the screen can continue displaying necessary information. Simultaneously, the hardware arbitration unit issues a failsafe_IRQ, a high-priority hardware interrupt signal used to immediately wake up or interrupt the MCU. This allows the MCU to quickly respond to SOC failures and execute emergency display procedures to maintain system stability and security.

[0062] Furthermore, the power management chip (PMIC) plays a crucial role in this process. It is responsible for converting the 12V battery voltage to the operating voltage required by the system and ensuring physically independent power rails for the MCU, SOC, and instrument panel. This design helps the MCU and instrument panel continue to function normally in the event of an SOC malfunction.

[0063] Finally, the underlying control bus SPI_Ctrl, after arbitration by the MUX, is ultimately connected to the display driver IC. Control dynamically switches between the SOC and MCU, ensuring that the SOC controls the display when it is operating normally; and that the MCU can take over control and continue controlling the instrument display through hardware bypass circuitry when the SOC malfunctions. This design not only improves system reliability but also enhances its fault response capability.

[0064] In one implementation of this application, after switching control of the instrument display screen from the SOC to the instrument safety microcontroller MCU via a hardware bypass circuit, and taking over control of the instrument display screen via a second low-speed control bus, the method further includes:

[0065] After the MCU detects a change in bus control, it immediately executes a preset emergency display task. At the same time, the MCU checks whether the chip select and clock line of the second low-speed control bus are in an idle state. When the chip select and clock line of the second low-speed control bus are in an idle state, it is considered that the main processor has completely released the bus and executes the emergency display rendering process.

[0066] First, the MCU detects bus control, which determines which device can operate on the bus and access resources. The MCU continuously monitors the status of bus control; once a change in control is detected, it indicates a potential change in bus usage or the dominant device. At this point, the emergency display procedure is immediately executed. This ensures that the instrument cluster can quickly switch to emergency display mode in the event of unstable bus control or abnormal switching, guaranteeing the display of critical information (such as vehicle fault warnings and basic driving status). This prevents display confusion or information loss due to bus control issues, thereby maintaining basic vehicle safety and the driver's right to know the vehicle's status.

[0067] The pre-set emergency display tasks refer to a series of operational steps or procedures that are pre-defined during the system design phase. These steps or procedures are used by the MCU to take over control of the instrument display screen in the event of a SOC failure. The main purpose of these tasks is to ensure that even if the main processor SOC malfunctions, the instrument display screen can still provide the user with critical information, thereby ensuring driving safety and the basic functions of the system.

[0068] Furthermore, the MCU needs to detect whether the chip select and clock lines of the second low-speed control bus are in an idle state. The second low-speed control bus, SPI-2, is a serial communication bus, and the chip select and clock lines are its critical control signal lines. The MCU detects the idle state of these two lines to confirm that the main processor has completely released the bus and is no longer occupying it for data transmission. Only when the bus is idle can the instrument safety MCU safely initiate operations on the instrument panel driver IC, avoiding conflicts with data transmission from the main processor and ensuring the accuracy and stability of data transmission.

[0069] The emergency display rendering process includes: initializing the instrument display screen via the second low-speed control bus and setting a display area in the instrument display screen; reading the data to be displayed and displaying the data to be displayed in the display area.

[0070] The initialization of the instrument display screen includes sending an initialization sequence to the instrument display driver IC via SPI-2 bypass to complete a series of configuration and preparation tasks for the driver IC. This initialization series does not require complex configuration; it only includes software reset, exiting sleep mode, display on, and setting the display mode to the most basic RGB565 format. Software reset restores the driver IC's internal state to its initial default value, clearing any possible errors or abnormal states; exiting sleep mode puts the driver IC into normal working condition, enabling it to respond to subsequent commands; the display on command starts the driver IC's display function; setting the basic display mode to RGB565 format specifies how the driver IC processes and displays pixel data, laying the foundation for subsequent display operations.

[0071] Then, a column / page address setting command is sent to the instrument panel driver IC via SPI-2 bypass, limiting subsequent write operations to a predefined small rectangular window in the center of the screen. This is done to centrally display key information (such as vehicle speed and gear), avoiding information dispersion and visual interference caused by displaying it across the entire screen. Simultaneously, limiting the display area reduces data transmission volume and processing burden, improving display efficiency and MCU performance. The size and position of the predefined small rectangular window are directly set in the firmware according to product requirements, without dynamic calculation.

[0072] In one implementation of this application, the specific process of reading the data to be displayed and displaying the data to be displayed in the display area includes: after reading the data to be displayed, the MCU reads the corresponding glyph data in a preset memory, inputs the read glyph data into a constructed row buffer, and sends the data in the row buffer to the display area; repeating the above steps to complete the periodic rendering of the display area.

[0073] The data to be displayed includes the latest vehicle speed and gear position. The MCU directly reads the latest vehicle speed and gear position from the CAN / IO controller; these values ​​represent important current driving status information of the vehicle. Since various vehicle status information (such as numbers, letters, and symbols) needs to be displayed visually on the instrument panel, the corresponding fonts need to be looked up from a compressed dot-matrix font library stored in Flash memory. The dot-matrix font library stores the pixel dot-matrix data of each character. By searching the font library, the MCU can obtain the pixel representation of the vehicle speed and gear position, providing a data foundation for subsequent display rendering, thus saving costs and simplifying the design.

[0074] The MCU constructs a row buffer in RAM, the size of one row of pixels in the window, using a highly optimized C program. This row buffer serves as a data cache and intermediate processing unit. Inputting pixel data into this buffer allows the MCU to perform unified processing and management of the pixel data, such as pixel format conversion and data sorting. Simultaneously, the row buffer design enables data to be sent sequentially to the instrument panel row by row, conforming to the data transmission characteristics of the SPI bus and improving data transmission efficiency and stability.

[0075] Then, the MCU sends the data from the line buffer to the display area via the SPI-2 bus. Specifically, the processed pixel data is transmitted line by line to the instrument panel driver IC, which updates the pixel display at the corresponding position on the screen based on the received data. The rendering process is repeated periodically at a low fixed frequency, such as 2-5Hz, until the entire window is refreshed. This ensures that the characters corresponding to the vehicle speed and gear position are completely displayed within the pre-set screen window, achieving a visual presentation of the information. This reduces the MCU's performance load while ensuring timely updates to the instrument panel display. Although vehicle speed and gear position information change with vehicle movement, they do not need to be updated at the highest frequency in real time. Using a lower-frequency periodic rendering not only meets the driver's need for information updates but also reduces the MCU's computational and data transmission load, allowing the MCU to handle other important tasks and improving the overall system stability and reliability.

[0076] The above embodiments describe how, when the hardware arbitration unit detects a SOC fault, it switches control of the instrument display screen from the SOC to the instrument safety microcontroller (MCU), and takes over control of the instrument display screen via a second low-speed control bus. Next, the process involved in the SOC restarting in the background and attempting to resume normal operation will be described.

[0077] When a System-on-a-Chip (SoC) attempts to restart and recover from the background, it needs to verify its identity with the Microcontroller (MCU) via a pre-defined verification protocol. This verification process is a crucial step in ensuring the stability of the SoC's software and hardware. The SoC must regain control through a secure handover protocol, namely the pre-defined verification protocol. Specifically, the SoC needs to correctly and repeatedly respond to the verification protocol issued by the MCU to demonstrate that it has recovered and stabilized.

[0078] The UART security protocol plays a crucial role in this process. The UART, the serial communication interface between the MCU and the SOC, is used to execute a secure challenge-response handshake protocol. This protocol helps confirm whether the SOC has truly stabilized. Through this interaction, the MCU can verify the SOC's state and ensure it is ready to regain control.

[0079] Once the SOC successfully passes the preset verification protocol, meaning it can correctly respond to all challenges from the MCU, it is considered ready to regain control. At this stage, the MCU sends the Recovery_Grant signal to the hardware arbitration unit. This signal, issued by the security MCU during the safe recovery phase after confirming that the SOC has stabilized, authorizes the hardware arbitration unit to safely return bus control to the SOC.

[0080] Finally, upon receiving the Recovery_Grant signal, the hardware arbitration unit will execute an operation to switch bus control back from the MCU to the SOC, thereby allowing the SOC to regain control of the instrument display. This series of steps ensures that the SOC can only regain control when it is truly stable and ready during a reboot and recovery attempt, thus guaranteeing the safety and reliability of the entire system.

[0081] The above are some specific implementations of a method for handling instrument display screen failures provided in the embodiments of this application. Based on this, this application also provides a corresponding system. The system provided in the embodiments of this application will be described below from a functional perspective.

[0082] Figure 2 This is a schematic diagram of a fault handling system for an instrument display screen provided in an embodiment of this application. (Combined with...) Figure 2 As shown in the embodiment of this application, the instrument display screen failure handling system includes:

[0083] The main processor, SystemonChip (SOC), fully controls the display screen via a high-speed video interface (MIPI-DSI / LVDS) and a first low-speed control bus (SPI-1).

[0084] MCU, Instrument Cluster Safety MCU (Microcontroller Unit), is an automotive-grade microcontroller compliant with ASIL-B / C standards. Its responsibilities include monitoring the SOC and instrument cluster display; processing CAN messages; and taking over the display screen via hardware bypass (SPI-2) to perform emergency display tasks.

[0085] HWArbitrator Hardware Arbitration Unit: A security hardware module composed entirely of hardware logic. It is used to detect the operating status of the main processor SOC; without relying on any software, it monitors the SOC's vital signs (Challenge-Response WDT signal) and, upon detecting a fault, performs three key actions instantaneously and in parallel: (1) Force isolation of the SOC (pull RST_N low); (2) Interrupt and wake up the MCU (pull Failsafe_IRQ low); (3) Force bus switching (flip Bus_Sel signal).

[0086] PMIC, Power Management IC: Responsible for converting the 12V battery voltage to the operating voltage required by the system. A key design feature is providing physically independent power rails for the MCU, SOC, and instrument panel.

[0087] XTAL (MCU), Independent Crystal Oscillator: Provides a completely independent physical clock source for the MCU, and is a key hardware guarantee for achieving high-level functional safety (ISO26262) and FFI principles.

[0088] VDD_MCU / VDD_SOC / VDD_OLED Independent Power Rails: Power supplies provided by the PMIC for the isolated MCU and SOC cores, as well as power supplies for the screen.

[0089] PG (Power-Good) / PG_DISP: The display is powered on well. The power signal generated by the PMIC is sent to the hardware arbitration unit to monitor the status of the MCU / SOC core power rail and the status of the screen power line.

[0090] Challenge-Response Watchdog (WDT) is a reliable monitoring mechanism.

[0091] ST_N (Hardware Reset Signal): A forced reset signal generated by the hardware arbitration unit. Once it goes low, it will put the SOC into a permanent hardware reset state, with all its I / Os in a high-impedance state, achieving complete physical isolation from the system bus.

[0092] Failsafe_IRQ (Fail-safe Interrupt Request) is a high-priority hardware interrupt issued by the hardware arbitration unit to the MCU when a SOC fault is detected. It is used to immediately wake up or interrupt the MCU and make it execute the emergency display program.

[0093] RGHR: The reset signal for the hardware arbiter, used to reset the hardware.

[0094] Bus_Sel (bus select signal) is a control signal output from the hardware arbitration unit to the MUX, used to forcibly switch control of the display's underlying control bus (SPI_Ctrl) from the SOC to the MCU.

[0095] Recovery_Grant (RG recovery grant signal) is a signal sent by the security MCU to the hardware arbitration unit after confirming that the SOC has stabilized during the safe recovery phase. It authorizes the unit to safely return bus control to the SOC.

[0096] The SPI-1 (First Low-Speed ​​Control Bus) SOC is used to configure and control the SPI bus of the display driver IC.

[0097] The SPI-2 (Second Low-Speed ​​Control Bus), a dedicated SPI bus for the security MCU, constitutes the core "hardware bypass" of this invention. In fail-operation mode, the MCU directly writes security information to the display screen through this path.

[0098] After arbitration by the MUX, the SPI_Ctrl underlying control bus is finally connected to the SPI bus of the display driver IC. Its control is dynamically switched between the SOC and the MCU.

[0099] The UART security protocol is a serial communication interface between the MCU and the SOC. During the security recovery phase, it is used to perform a secure "challenge-response" handshake protocol to confirm whether the SOC has truly returned to stability.

[0100] The MUX bus switcher (Multiplexer) is a standard 2-to-1 bus multiplexer and a key device for implementing forced bus arbitration. When the hardware arbitration unit detects an anomaly in the SOC, it toggles the bus selection signal, switches control of the instrument display from the SOC to the instrument safety microcontroller (MCU) via a hardware bypass circuit, and then takes over control of the instrument display via a second low-speed control bus.

[0101] Internal Flash / RAM: The internal flash memory and RAM integrated within the MCU. Used for storing securely certified firmware and other data, and also serves as a frame buffer for building emergency display screens.

[0102] The CAN / IO controller area network interface and general-purpose input / output are the main ways for the MCU to obtain vehicle status (such as vehicle speed and gear) and interact with other parts of the vehicle.

[0103] 12VBAT (12-volt battery): Provides power to the entire system.

[0104] Internal Flash / RAM: Stores the MCU's program and data.

[0105] DDR: Connects to the SOC and is used for high-speed data storage.

[0106] OLED / TFT-LCD: Display screen that receives video signals from the SOC via MIPI-DSI / LVDS interface for displaying information.

[0107] Upgrade Port: Used for system or firmware upgrades.

[0108] In one implementation of this application, the MCU is further configured to: immediately execute a preset emergency display task after detecting a change in bus control; and simultaneously detect whether the chip select and clock line of the second low-speed control bus are in an idle state.

[0109] When the chip select and clock line of the second low-speed control bus are in an idle state, it is considered that the main processor has completely released the bus and executes the emergency display rendering process.

[0110] In one implementation of this application, the emergency display rendering process includes:

[0111] The instrument display screen is initialized via the second low-speed control bus, and a display area is set on the instrument display screen;

[0112] Read the data to be displayed and display the data in the display area.

[0113] In one implementation of this application, reading the data to be displayed and displaying the data to be displayed in the display area includes:

[0114] After reading the data to be displayed, the MCU reads the corresponding glyph data from the preset memory, inputs the read glyph data into the constructed row buffer, and sends the data in the row buffer to the display area;

[0115] Repeat the above steps to complete the periodic rendering of the display area.

[0116] In one implementation of this application, when the SOC is restarted and attempts to recover, it verifies with the MCU through a preset verification protocol;

[0117] Once the preset verification protocol is successfully verified, the SOC gains control.

[0118] In one implementation of this application, the SOC malfunction includes one or more of the following: the SOC's watchdog timer fails to receive a response signal within a specified time, the power supply fails, the SOC's temperature exceeds a preset temperature threshold, the SOC's clock signal stops, the power line of the instrument display screen has no voltage signal, and the instrument display screen cannot display normally.

[0119] This application also provides corresponding devices and computer storage media for implementing the solutions provided in this application.

[0120] The device includes a memory and a processor. The memory stores instructions or code, and the processor executes the instructions or code to cause the device to perform the method described in any embodiment of this application.

[0121] The computer storage medium stores code, and when the code is run, the device running the code implements the method described in any embodiment of this application.

[0122] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that all or part of the steps in the methods of the above embodiments can be implemented by means of software plus a general-purpose hardware platform. Based on this understanding, the technical solution of this application can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as a read-only memory (ROM) / RAM, a magnetic disk, an optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, a server, or a network communication device such as a router) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0123] It is understood that in the specific embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved need to obtain user permission or consent when the above embodiments of this application are applied to specific products or technologies, and the collection, use and processing of related data need to comply with the relevant laws, regulations and standards of relevant countries and regions.

[0124] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0125] It should also be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0126] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for handling failure of an instrument cluster display, the method comprising: The method comprises: The hardware arbitration unit detects the running state of the main processor SOC, and the SOC controls the instrument display screen through the first low-speed control bus; When the hardware arbitration unit detects that the SOC is abnormal, the SOC is restored to the initial state, and the reset signal is locked; The bus selection signal is flipped, the control of the instrument display screen is switched from the SOC to the instrument safety microcontroller MCU through the hardware bypass circuit, and the control of the instrument display screen is taken over through the second low-speed control bus.

2. The method of claim 1, wherein, After the control of the instrument display screen is switched from the SOC to the instrument safety microcontroller MCU through the hardware bypass circuit, and the control of the instrument display screen is taken over through the second low-speed control bus, the method further comprises: The MCU detects the change of the bus control immediately after the preset emergency display task is executed; meanwhile, the MCU detects whether the chip select and clock lines of the second low-speed control bus are in an idle state; When the chip select and clock lines of the second low-speed control bus are in an idle state, it is considered that the main processor has completely released the bus, and the emergency display rendering process is executed.

3. The method of claim 2, wherein, The execution of the emergency display rendering process comprises: The second low-speed control bus is initialized to the instrument display screen, and a display area is set in the instrument display screen; The to-be-displayed data is read and displayed in the display area.

4. The method of claim 3, wherein, The reading of the to-be-displayed data and the display of the to-be-displayed data in the display area comprises: After the to-be-displayed data is read, the MCU reads corresponding glyph data in a preset memory, inputs the read glyph data into a constructed line buffer, and sends the data in the line buffer to the display area; The above steps are repeated to complete the periodic rendering of the display area.

5. The method of claim 1, wherein, The method further comprises: When the SOC is restarted and attempts to recover, the SOC is verified with the MCU through a preset verification protocol; When the preset verification protocol is verified, the SOC obtains the control.

6. The method of claim 1, wherein, The SOC abnormality comprises one or more of the following: The watchdog timer of the SOC does not receive a response signal within a specified time, the power supply is powered off, the temperature of the SOC exceeds a preset temperature threshold, the clock signal of the SOC stops, the power supply line of the instrument display screen has no voltage signal, and the instrument display screen cannot display normally.

7. An instrument cluster screen failure handling system, characterized by, The system comprises a hardware arbitration unit, a main processor SOC, a safety microcontroller MCU, a first low-speed control bus, a second low-speed control bus, and a bus switcher; The hardware arbitration unit is configured to detect the running state of the main processor SOC; The SOC is configured to control the instrument display screen through the first low-speed control bus; The hardware arbitration unit is further configured to restore the SOC to the initial state and lock the reset signal when detecting that the SOC is abnormal; The bus switch is used for flipping a bus selection signal when the hardware arbitration unit detects that the SOC is abnormal, switching the control right of the instrument display screen from the SOC to an instrument safety micro controller MCU through a hardware bypass circuit, and taking over the control of the instrument display screen through a second low-speed control bus.

8. The system of claim 7, wherein, The MCU is further used for executing a preset emergency display task immediately after detecting that the bus control right is changed; and simultaneously detecting whether chip selection and clock lines of the second low-speed control bus are in an idle state. When the chip selection and clock lines of the second low-speed control bus are in the idle state, it is considered that the main processor has completely released the bus, and an emergency display rendering process is executed.

9. A computing device, comprising: The computing device comprises a memory and a processor; The memory is used for storing a computer program; The processor is used for implementing the method in any one of claims 1 to 6 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the method in any one of claims 1 to 6.

Images