Blank screen resetting and fault feedback system

Abstract

The embodiment of the invention relates to the technical field of vehicles, and discloses a blank screen resetting and fault feedback system. According to the embodiment of the invention, at least intelligent fault processing and precise fault feedback can be realized; in the aspect of intelligent fault processing, the system can automatically carry out grading processing on black screen faults, manual intervention is reduced, and the operation and maintenance cost is reduced; the accurate fault feedback enables the user to know the fault state in time, provides detailed diagnosis data for research and development personnel, accelerates the troubleshooting and repairing speed, and improves the overall availability of the equipment and the user satisfaction; the problems that in the prior art, blank screen fault processing depends on manpower, efficiency is low, and fault feedback is not accurate are solved.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, and in particular to a black screen recovery and fault feedback system. Background Technology

[0002] In current technology, the solutions for when a vehicle screen goes black are limited. The common practice is to manually restart the device, a method that lacks automation and consumes significant manpower. If restarting fails to resolve the issue, troubleshooting often relies on manual experience, involving checking hardware connections and software settings one by one to find the fault, which is inefficient and prone to errors.

[0003] From a fault feedback perspective, when users encounter a black screen, they typically only receive vague prompts, such as "Device malfunction, please contact customer service," without being able to obtain specific information about the cause of the malfunction. For R&D personnel, the fault information they receive is also very limited, making it difficult to quickly pinpoint the root cause of the problem. This leads to prolonged fault repair cycles, impacting user experience and normal device operation. In scenarios with high requirements for device continuity, it can even have serious consequences. Summary of the Invention

[0004] The purpose of this invention is to provide a black screen recovery and fault feedback system, which can at least alleviate the problems of manual handling, low efficiency, and inaccurate fault feedback in the prior art.

[0005] To achieve the above technical objectives, the present invention provides a black screen recovery and fault feedback system, which includes at least a screen module, a QNX application module, a QNX LocalService module, a QNX software diagnostic service module, a QNX Display module, an Android application module, an Android HQCarService module, an Android software diagnostic service module, an MCU module, and a cloud module.

[0006] The screen module is connected to the serializer of the QNX Display module via an internal deserializer; the reporting end of the QNX Display module is connected to the first end of the QNX LocalService module via an event upload link; the second end of the QNX LocalService module is connected to the first end of the QNX Soft Diagnostic Service module via an event forwarding link; the third end of the QNX LocalService module is connected to the first end of the AndroidHQCarService module via a first pop-up broadcast link; the fourth end of the QNX LocalService module is connected to the QNX application module via a second pop-up broadcast link; the second end of the Android HQCarService module is connected to the Android application module via a third pop-up broadcast link; the second end of the QNX Soft Diagnostic Service module is connected to the first end of the Android Soft Diagnostic Service module via an intra-domain notification link; the second end of the Android Soft Diagnostic Service module is connected to the cloud module; the MCU module establishes a connection with at least the QNX module.

[0007] The screen module is used to perform at least one Level 1 reset operation based on its own state and driver state; the QNX Display module is used to monitor the screen module and its driver, upload at least one diagnostic event to the QNX LocalService module through the event upload link, and perform at least one Level 2 reset operation based on the type of the diagnostic event; the MCU module is used to perform at least one Level 3 reset operation based on the type of the diagnostic event.

[0008] Optionally, the QNX Display module is further configured to determine whether a fault exists after a preset number of secondary reset operations. If the fault still exists, the QNX LocalService module is notified that the screen reset has failed. This allows the QNX LocalService module to carry the event-corresponding pop-up ID and broadcast it to the security domain and the Android application via the pop-up broadcast link. This enables the QNX application module and the Android application module to perform a prompt operation based on the pop-up ID.

[0009] The QNX LocalService module is at least used to forward each diagnostic event and its corresponding timestamp to the QNX Soft Diagnostic Service module through the event forwarding link.

[0010] The QNX software diagnostic service module is at least used to write each diagnostic event and its corresponding timestamp to a TAG file, identify the specific software diagnostic event ID, copy all log files to the shared partition between QNX and Android under the corresponding log path, and after the copy is completed, notify the Android software diagnostic service module through the domain notification link so that the Android software diagnostic service module can upload the TAG file and the log file to the cloud module when the network is normal, and delete them after successful upload.

[0011] Optionally, the three-level recovery operation is at least a reset and restart of the SOC. If the screen module still fails to recover after the SOC has been reset and restarted a preset number of times, the current sleep wake-up ends.

[0012] Optionally, the first-level reset operation includes at least attempting a self-reboot and resetting the screen peripherals via the screen MCU.

[0013] Optionally, the first-level recovery operation may further include at least reducing the screen brightness and informing the CSC of the actual screen brightness.

[0014] Optionally, the first-level reset operation may further include performing a fault upload operation, which is sent to the CSC via the I2C protocol; when the screen power supply voltage exceeds a preset high voltage threshold or the screen power supply voltage is lower than a preset low voltage threshold, a black screen and peripheral device shutdown operation is performed.

[0015] Optionally, the secondary reset operation includes at least restarting the display subsystem, lowering the wakeup timer for at least a preset period, and then raising it again; and resetting the screen MCU via CSC. If the screen module still fails to recover after the screen MCU has reset a set number of times, the current sleep wake-up ends.

[0016] Optionally, the module itself and its driving state or the diagnostic events include at least: detection of screen unlock, SOC and serial chip disconnection, VP error, bit error rate, screen detection of SOC heartbeat abnormality, SOC detection of screen heartbeat abnormality, screen startup process DP error, SOC startup process DP error, CSC SOC detection of screen handshake timeout, CSC MCU detection of screen handshake timeout, screen reporting bits 0~1: no backlight brightness value received, screen reporting bits 2~3: deserializer chip error detection pin status, screen reporting bits 4~5: TFT error detection, screen reporting bits 6~7: TFT error detection. LINK, the screen reports bit 0~1: battery overvoltage, bit 2~3: battery undervoltage, bit 4~5: TP error, bit 0~1: VideoLock, bit 2~3: backlight error detection, backlight chip error, bit 4~5: OSD function error detection, bit 6~7: backlight temperature detection, bit 2~3: bridge error detection, read serial chip voltage, DP error during operation, and bit 0~1: motor error detection.

[0017] Optionally, the module itself and its drive state, or the diagnostic event, can be determined at least by reading the registers from the screen MCU:

[0018] The screen displays bits 4-5: TFT error detection; bits 6-7: TFT LINK; bits 4-5: TP error; bits 0-1: Video Lock; bits 2-3: Backlight error detection / backlight chip error; bits 4-5: OSD function error detection; bits 6-7: Backlight temperature detection; and bits 2-3: Bridge error detection.

[0019] Optionally, the module itself and its drive state, or the diagnostic event, can be determined at least through heartbeat detection:

[0020] The screen detected an abnormal SOC heartbeat, and the SOC detected an abnormal screen heartbeat.

[0021] The technical solution provided in this embodiment of the invention enables the screen module to perform at least one level of reset operation based on the module itself and the driving state. Furthermore, the QNX Display module monitors the screen module and its driver, uploading at least one diagnostic event to the QNX LocalService module via the event upload link, and performing a secondary reset operation based on the type of diagnostic event. The QNX Display module determines whether the fault still exists after a preset number of secondary reset operations. If it still exists, the QNX LocalService module is notified that the screen reset has failed, so that the QNX LocalService module carries the event-corresponding pop-up ID and broadcasts it to the security domain and Android application via the pop-up broadcast link, thereby enabling the QNX application module and Android application module to perform prompt operations based on the pop-up ID. Simultaneously, the QNX LocalService module forwards each diagnostic event and its corresponding timestamp to the QNX soft diagnostic service module via the event forwarding link. Furthermore, the QNX soft diagnostic service module writes each diagnostic event and its corresponding timestamp to disk as a TAG file, identifies the specific soft diagnostic event ID, copies all log files to the shared partition between QNX and Android under the corresponding log path, and notifies the Android soft diagnostic service module via the domain notification link after the copy is completed, so that the Android soft diagnostic service module uploads the TAG file and log file to the cloud module when the network is normal, and deletes them after successful upload. Finally, if the first-level and second-level revert operations still fail to achieve black screen recovery, the MCU module executes a third-level revert operation based on the type of diagnostic event.

[0022] Therefore, the embodiments of the present invention can at least achieve intelligent fault handling and precise fault feedback. Regarding intelligent fault handling, the system can automatically classify and process black screen faults, reducing manual intervention and lowering maintenance costs. Precise fault feedback allows users to understand the fault status in a timely manner, while providing R&D personnel with detailed diagnostic data, accelerating problem investigation and repair, and improving the overall availability of the equipment and user satisfaction. This helps alleviate the problems of manual handling, low efficiency, and inaccurate fault feedback in existing technologies for black screen fault handling. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of a black screen recovery and fault feedback system provided in an embodiment of the present invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail 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 in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “said,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms, and “multiple” generally includes at least two unless the context clearly indicates otherwise.

[0026] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0027] It should be understood that although the terms first, second, third, etc., may be used in the embodiments of this application, these descriptions should not be limited to these terms. These terms are only used to distinguish the descriptions. For example, first may also be referred to as second without departing from the scope of the embodiments of this application, and similarly, second may also be referred to as first.

[0028] Depending on the context, the words “if” or “suppose” as used here can be interpreted as “when” or “in response to determination” or “in response to detection.” Similarly, depending on the context, the phrases “if determination” or “if detection (of the stated condition or event)” can be interpreted as “when determination” or “in response to determination” or “when detection (of the stated condition or event)” or “in response to detection (of the stated condition or event).”

[0029] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that an article or device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such an article or device. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the article or device that includes said element.

[0030] It should be noted that any symbols and / or numbers present in the specification that are not marked in the accompanying drawings are not reference numerals.

[0031] Figure 1 This is a schematic diagram of a black screen recovery and fault feedback system provided in an embodiment of the present invention. This embodiment is applicable to at least any vehicle's screen fault diagnosis and feedback scenario. The black screen recovery and fault feedback system can be implemented using software and / or hardware. Figure 1 As shown, the black screen recovery and fault feedback system includes at least a screen module, a QNX application module, a QNX LocalService module, a QNX software diagnostic service module, a QNX Display module, an Android application module, an Android HQCarService module, an Android software diagnostic service module, an MCU module, and a cloud module.

[0032] The screen module connects to the serializer of the QNX Display module via its internal deserializer; the reporting end of the QNX Display module connects to the first end of the QNX LocalService module via an event upload link; the second end of the QNX LocalService module connects to the first end of the QNX Soft Diagnostic Service module via an event forwarding link; the third end of the QNX LocalService module connects to the first end of the Android HQCarService module via a first pop-up broadcast link; the fourth end of the QNX LocalService module connects to the QNX application module via a second pop-up broadcast link; the second end of the Android HQCarService module connects to the Android application module via a third pop-up broadcast link; the second end of the QNX Soft Diagnostic Service module connects to the first end of the Android Soft Diagnostic Service module via an intra-domain notification link; the second end of the Android Soft Diagnostic Service module connects to the cloud module; and the MCU module establishes a connection with at least the QNX module.

[0033] The screen module is at least used to perform a first-level reset operation based on its own and driver states; the QNX Display module is at least used to monitor the screen module and its driver, upload at least one diagnostic event to the QNXLocalService module via the event upload link, and perform a second-level reset operation based on the type of the diagnostic event; the MCU module is at least used to perform a third-level reset operation based on the type of the diagnostic event.

[0034] Among them, the screen module is Figure 1 The "screen" module shown is the QNX application module. Figure 1 The "Applications" submodule under the "QNX" module shown is the QNX LocalService module. Figure 1The "LocalService" submodule under the "QNX" module shown is the QNX soft diagnostic service module. Figure 1 The "Soft Diagnostic Services" submodule under the "QNX" module shown is the QNX Display module. Figure 1 The "Display" submodule under the "QNX" module shown is the Android application module. Figure 1 The "Applications" submodule under the "Android" module shown is the Android HQCarService module. Figure 1 The "HQCarService" submodule under the "Android" module shown is the Android software diagnostic service module. Figure 1 The "Soft Diagnostic Service" submodule under the "Android" module shown is the MCU module. Figure 1 The "MCU" module shown is the cloud module. Figure 1 The "cloud" module shown.

[0035] In one specific implementation, the QNX Display module is optionally further used to determine whether the fault exists after a preset number of secondary reset operations. If the fault still exists, the QNX LocalService module is notified that the screen reset has failed, so that the QNX LocalService module carries the pop-up ID corresponding to the event and broadcasts it to the security domain and the Android application through the pop-up broadcast link, thereby enabling the QNX application module and the Android application module to perform the prompt operation according to the pop-up ID.

[0036] The QNX LocalService module is at least used to forward each diagnostic event and its corresponding timestamp to the QNX Soft Diagnostics Service module via the event forwarding chain. Figure 1 (as shown in "Screen_unlock + time").

[0037] The QNX soft diagnostic service module is at least used to write each diagnostic event and its corresponding timestamp to a TAG file, and to identify the specific soft diagnostic event ID so as to record it in the corresponding log path (i.e., Figure 1 All log files under the "log path ×××" shown are copied to a shared partition between QNX and Android, and after the copy is completed, the domain notification link (i.e.) is used to notify other users. Figure 1 The "Domain Notification" shown in the image notifies the Android Soft Diagnostic Service Module so that the Android Soft Diagnostic Service Module can upload the TAG file and log file to the cloud module when the network is normal, and then clear them after successful upload.

[0038] In another specific implementation, optionally, the three-level reset operation is at least a reset and restart of the SOC. If the screen module still fails to recover after the SOC reset and restart count reaches a preset number, the current sleep wake-up ends.

[0039] In another specific implementation, optionally, the first-level reset operation includes at least attempting a self-reboot and resetting the screen peripherals via the screen MCU.

[0040] In yet another specific implementation, the first-level reset operation may optionally include at least reducing the screen brightness and informing the CSC of the actual screen brightness.

[0041] In another specific implementation, optionally, the first-level reset operation also includes performing a fault upload operation, which is sent to the CSC via the I2C protocol; when the screen power supply voltage exceeds a preset high voltage threshold or the screen power supply voltage is lower than a preset low voltage threshold, a black screen and peripheral device shutdown operation is performed.

[0042] In another specific implementation, optionally, the secondary reset operation includes at least restarting the display subsystem, lowering the wakeup for at least a preset period of time and then raising it again; and resetting the screen MCU through CSC. If the screen module still does not recover after the screen MCU resets a set number of times, the current sleep wake-up ends.

[0043] In another specific implementation, optionally, the module itself and its driving state or diagnostic events include at least: detection of unlocking with the screen, disconnection between the SOC and the serial chip, VP error, bit error rate, screen detection of SOC heartbeat abnormality, SOC detection of screen heartbeat abnormality, DP error during screen startup, DP error during SOC startup, CSC SOC detection of screen handshake timeout, CSC MCU detection of screen handshake timeout, screen reporting bit 0~1: no backlight brightness value received, screen reporting bit 2~3: deserializer chip error detection pin status, screen reporting bit 4~5: TFT error detection, screen reporting bit 6~7: TFTLINK, screen reporting bit 0~1: battery overvoltage, screen reporting bit 2~3: battery undervoltage, screen reporting bit 4~5: TP error, screen reporting bit 0~1: Video Lock, the screen will report bits 2~3: backlight error detection, backlight chip error, bits 4~5: OSD function error detection, bits 6~7: backlight temperature detection, bits 2~3: bridge error detection, read serial chip voltage, DP error during operation, and bits 0~1: motor error detection.

[0044] In another specific implementation, optionally, the following modules themselves and their drive states or diagnostic events can be determined at least by reading registers from the screen MCU:

[0045] The screen displays bits 4-5: TFT error detection; bits 6-7: TFT LINK; bits 4-5: TP error; bits 0-1: Video Lock; bits 2-3: Backlight error detection / backlight chip error; bits 4-5: OSD function error detection; bits 6-7: Backlight temperature detection; and bits 2-3: Bridge error detection.

[0046] In yet another specific implementation, optionally, the following modules themselves and their drive states or diagnostic events can be determined at least through heartbeat detection:

[0047] The screen detected an abnormal SOC heartbeat, and the SOC detected an abnormal screen heartbeat.

[0048] For example, corresponding detection measures can be set for various screen-related abnormal events (i.e., the aforementioned diagnostic events). Specifically, for the "Detected Unlock with Screen" event, it can be detected by continuously reading the screen's lock status register using a thread; for the "SOC and Chip Disconnection" event, it can be detected by continuously initiating I2C with the chip using a thread and judging whether the I2C communication fails; for the "VP Error" event, it can be detected by reading the SOC's internal state using a thread; for the "Bit Error Rate" event, it can be detected by continuously reading the screen's bit error rate related registers using a thread; for the "Screen Startup Process DP Error" and "SOC Startup Process DP Error" events, it can be detected by the screen DP initialization failure; for the "CSCSOC Screen Handshake Timeout" event, it can be detected by the SOC detecting CRQ timeout; for the "CSC MCU Screen Handshake Timeout" event, it can be detected by the MCU detecting CRQ timeout; for the "Screen Reports Bits 0~1: No Backlight Brightness Value Received" event, it can be detected by reading the screen's internal status variables; for the "Screen Reports Bits 0~1: Battery Overvoltage" and "Screen Reports Bits 2~3: Battery Undervoltage" events, it can be detected by reading the screen's power supply voltage using the screen MCU.

[0049] Furthermore, most abnormal events require logging and software diagnostics. The system generates corresponding software diagnostic keywords based on different abnormal events, such as "Screen_Unlock" and "Screen_Disconnect". These keywords help to quickly locate and identify specific abnormal situations in a large amount of logs, facilitating subsequent fault analysis. These critical events and logs are uploaded to the cloud through the cockpit controller's software diagnostic service, facilitating statistical dashboards and log downloads on the cloud.

[0050] More specifically, for the following events: "Detection of unlocking at the screen, disconnection between SOC and serial chip, VP error, bit error rate, screen detects SOC heartbeat abnormality, SOC detects screen heartbeat abnormality, DP error during screen startup, DP error during SOC startup, CSC SOC detects screen handshake timeout, CSC MCU detects screen handshake timeout, screen reports bit 0~1: no backlight brightness value received, screen reports bit 2~3: deserializer chip error detection pin status, screen reports bit 4~5: TFT error detection, screen reports bit 6~7: TFT LINK, screen reports bit 0~1: battery overvoltage, screen reports bit 2~3: battery undervoltage, screen reports bit 4~5: TP error, screen reports bit 0~1: Video error." Regarding the following: Lock, screen reports bits 2-3: backlight error detection, backlight chip error; screen reports bits 4-5: OSD function error detection; screen reports bits 6-7: backlight temperature detection; screen reports bits 2-3: bridge error detection, reading serial chip voltage, DP error during operation; and screen reports bits 0-1: motor error detection. The corresponding soft diagnostic keywords are: Screen_Unlock, Screen_Disconnect, Screen_VPError, Screen_BER, NA, Screen_HeartbeatFail, NA, Screen_SOCStartupDPError, Screen_S... OChandshaketimeout, Screen_MCUhandshaketimeout, ScreenReport_Nobrightnessvalue, ScreenReport_faultpinerror, ScreenReport_TFTError, ScreenReport_TFTlink, ScreenReport_Overbat, ScreenReport_Underbat, ScreenReport_TPerror, ScreenReport_Videolock, ScreenReport_Backlightchip error, ScreenReport_OSDError, ScreenReport_Temperror, ScreenReport_BridgeError, NA, ScreenReport_OperationDPError, NA".

[0051] Furthermore, regarding reversion measures:

[0052] 1. Level 1 Reset (Screen Reset Measure Level 1): Under certain abnormal events, the screen will continuously attempt to restart (currently the screen is black and does not flicker), while the screen MCU resets the screen's peripherals. This method is used in events such as "Detected Unlock with screen" and "Screen detected SOC heartbeat abnormality". One loop lasts 7 seconds, and five loops last 35 seconds.

[0053] 2. Second-level reset (CSC reset measure level 2): ​​This usually involves attempting to restart the display subsystem (including DP, serializer, and deserializer reset), pulling the wakeup low for more than 3 seconds and then pulling it high again. CSC attempts to reset the screen's MCU (specifically the deserializer). This reset measure is executed in various abnormal situations such as "SOC and serial chip disconnection" or "SOC detects abnormal screen heartbeat," and is attempted three times consecutively. If the problem persists, the sleep / wake-up process ends.

[0054] 3. Level 3 Reset (CSC Reset Measures Level 3): The MCU is reset and restarted to restart the SOC system. This can be attempted up to 3 times consecutively. If the system still fails to recover, the hibernation wake-up process ends.

[0055] Furthermore, regarding fault notification and display measures:

[0056] Pop-ups and keywords: When an anomaly is detected, a corresponding pop-up keyword will be generated, such as "PopScreen_Unlock" or "PopScreen_Disconnect", which will display special text visible to the user on the screen and play specific sounds, allowing the user to understand the fault situation in a timely manner.

[0057] More specifically, for the following events: "Detection of unlocking at the screen, disconnection between SOC and serial chip, VP error, bit error rate, screen detects SOC heartbeat abnormality, SOC detects screen heartbeat abnormality, DP error during screen startup, DP error during SOC startup, CSC SOC detects screen handshake timeout, CSC MCU detects screen handshake timeout, screen reports bit 0~1: no backlight brightness value received, screen reports bit 2~3: deserializer chip error detection pin status, screen reports bit 4~5: TFT error detection, screen reports bit 6~7: TFT LINK, screen reports bit 0~1: battery overvoltage, screen reports bit 2~3: battery undervoltage, screen reports bit 4~5: TP error, screen reports bit 0~1: Video error." Regarding the message "Lock, screen reports bits 2-3: backlight error detection, backlight chip error; screen reports bits 4-5: OSD function error detection; screen reports bits 6-7: backlight temperature detection; screen reports bits 2-3: bridge error detection, reading serial chip voltage, DP error during operation; and screen reports bits 0-1: motor error detection," the pop-up keywords can correspond to "PopScreen_Unlock, PopScreen_Disconnect, PopScreen_VPError, PopScreen_BER, NA, PopScreen_HeartbeatFail, NA, PopScreen_SOCStartupDPError, PopScreen_SOChan," etc. dshaketimeout, PopScreen_MCUhandshaketimeout, PopScreenReport_Nobrightnessvalue, PopScreenReport_faultpinerror, PopScreenReport_TFTError, PopScreen Report_TFTlink, PopScreenReport_Overbat, PopScreenReport_Underbat, PopScreenReport_TPerror, PopScreenReport_Videolock, PopScreenReport_Backlightchip error, PopScreenReport_OSDError, PopScreenReport_Temperror, PopScreenReport_BridgeError, NA, PopScreenReport_OperationDPError, NA".

[0058] Furthermore, cross-display: For certain abnormal events (such as detection of screen unlock, SOC and serial chip disconnection, VP error, bit error rate, screen detecting SOC heartbeat abnormality, SOC detecting screen heartbeat abnormality, screen startup process DP error, SOC startup process DP error, CSC SOC detecting screen handshake timeout, CSC MCU detecting screen handshake timeout, screen reporting bits 0~1: no backlight brightness value received, screen reporting bits 2~3: deserializer chip error detection pin status, screen reporting bits 4~5: TFT error detection, screen reporting bits 6~7: TFT error detection), screen reporting bits 4~5: TFT error detection. LINK, screen reports bit 0~1: battery overvoltage, screen reports bit 2~3: battery undervoltage, screen reports bit 4~5: TP error, screen reports bit 0~1: Video_Lock, screen reports: bit 2~3: backlight error detection, screen reports bit 4~5: OSD function error detection, screen reports bit 6~7: backlight temperature detection), CSC will cross-display when attempting to recover fails, to show the fault information in a more intuitive way.

[0059] Furthermore, the timing of notification to the upper layer: The system can determine the timing of notification to the upper layer based on different abnormal situations, which can be divided into immediate notification, no notification required, and notification at an opportune time. For example, for abnormal events that seriously affect the operation of the system, such as "detection of unlocking with the screen", an immediate notification will be given; while for some abnormal events that do not currently affect the main functions of the system or can be recovered on their own, such as "bit error rate", no notification is required.

[0060] The technical solution provided in this embodiment enables the screen module to perform at least one level of reset operation based on the module itself and the driver state. Furthermore, the QNX Display module monitors the screen module and its driver, uploading at least one diagnostic event to the QNX LocalService module via the event upload link, and performing a secondary reset operation based on the type of diagnostic event. The QNX Display module determines whether the fault still exists after a preset number of secondary reset operations. If it still exists, the QNX LocalService module is notified that the screen reset has failed, so that the QNX LocalService module carries the event-corresponding pop-up ID and broadcasts it to the security domain and Android application via the pop-up broadcast link, thereby enabling the QNX application module and Android application module to perform prompt operations based on the pop-up ID. Simultaneously, the QNX LocalService module forwards each diagnostic event and its corresponding timestamp to the QNX soft diagnostic service module via the event forwarding link. Furthermore, the QNX soft diagnostic service module writes each diagnostic event and its corresponding timestamp to disk as a TAG file, identifies the specific soft diagnostic event ID, copies all log files to the shared partition between QNX and Android under the corresponding log path, and notifies the Android soft diagnostic service module via the domain notification link after the copy is completed, so that the Android soft diagnostic service module uploads the TAG file and log file to the cloud module when the network is normal, and deletes them after successful upload. Finally, if the first-level and second-level revert operations still fail to achieve black screen recovery, the MCU module executes a third-level revert operation based on the type of diagnostic event.

[0061] Therefore, this embodiment can at least achieve intelligent fault handling and precise fault feedback. Regarding intelligent fault handling, the system can automatically classify and process black screen faults, reducing manual intervention and lowering maintenance costs. Precise fault feedback allows users to understand the fault status in a timely manner, while providing R&D personnel with detailed diagnostic data, accelerating problem investigation and repair, and improving the overall availability of the equipment and user satisfaction. This helps alleviate the problems of manual handling, low efficiency, and inaccurate fault feedback in existing technologies for black screen fault handling.

[0062] More specifically, the embodiments of the present invention can achieve at least the following beneficial effects:

[0063] 1. Improve fault repair efficiency

[0064] Through a tiered reset approach, starting with the screen's own restart and peripheral reset, and progressing to the CSC's reset of the display subsystem and screen MCU, the system gradually attempts to resolve screen anomalies. Level 1 reset can resolve some simple screen faults, while level 2 reset addresses more complex issues. This layered approach attempts to repair faults at different stages. Based on practical experience, it is predicted that common screen anomalies can be quickly restored to normal, avoiding direct reliance on manual intervention and saving troubleshooting time and labor costs.

[0065] 2. Precise fault location and analysis

[0066] Detailed logging and software diagnostic keywords provide developers with clear clues to faults. When a fault occurs, software diagnostic keywords can quickly filter relevant information from a large amount of logs, accurately determining the fault type and possible cause. For example, the keyword "Screen_VPError" can directly locate logs related to VP errors, helping developers quickly formulate repair strategies and improve the accuracy of fault diagnosis and repair.

[0067] 3. Improve user experience

[0068] A timely fault notification mechanism, such as pop-up keywords and cross-display functionality, allows users to understand screen anomalies immediately. As subsequent faults are continuously added, fault information can be conveyed to users in a more user-friendly way, reducing user anxiety. Simultaneously, the system can automatically handle faults, reducing the hassle of manual operation and improving user experience and satisfaction.

[0069] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A black screen recovery and fault feedback system, characterized in that, It includes at least a screen module, a QNX application module, a QNXLocalService module, a QNX software diagnostic service module, a QNX Display module, an Android application module, an AndroidHQCarService module, an Android software diagnostic service module, an MCU module, and a cloud module; The screen module is connected to the serializer of the QNX Display module via an internal deserializer; the reporting end of the QNX Display module is connected to the first end of the QNX LocalService module via an event upload link; the second end of the QNX LocalService module is connected to the first end of the QNX Soft Diagnostic Service module via an event forwarding link; the third end of the QNX LocalService module is connected to the first end of the AndroidHQCarService module via a first pop-up broadcast link; the fourth end of the QNX LocalService module is connected to the QNX application module via a second pop-up broadcast link; the second end of the Android HQCarService module is connected to the Android application module via a third pop-up broadcast link; the second end of the QNX Soft Diagnostic Service module is connected to the first end of the Android Soft Diagnostic Service module via an intra-domain notification link; the second end of the Android Soft Diagnostic Service module is connected to the cloud module; the MCU module establishes a connection with at least the QNX module. The screen module is at least used to perform a first-level reset operation based on its own and driver states; the QNXDisplay module is at least used to monitor the screen module and its driver, upload at least one diagnostic event to the QNX LocalService module through the event upload link, and perform a second-level reset operation based on the type of the diagnostic event; the MCU module is at least used to perform a third-level reset operation based on the type of the diagnostic event.

2. The black screen recovery and fault feedback system according to claim 1, characterized in that, The QNX Display module is also used to determine whether the fault exists after a preset number of secondary reset operations. If the fault still exists, the QNX LocalService module is notified that the screen reset has failed. This allows the QNX LocalService module to carry the event-corresponding pop-up ID and broadcast it to the security domain and the Android application via the pop-up broadcast link. This enables the QNX application module and the Android application module to perform the prompt operation based on the pop-up ID. The QNX LocalService module is at least used to forward each diagnostic event and its corresponding timestamp to the QNX Soft Diagnostic Service module through the event forwarding link. The QNX software diagnostic service module is at least used to write each diagnostic event and its corresponding timestamp to a TAG file, identify the specific software diagnostic event ID, copy all log files to the shared partition between QNX and Android under the corresponding log path, and after the copy is completed, notify the Android software diagnostic service module through the domain notification link so that the Android software diagnostic service module can upload the TAG file and the log file to the cloud module when the network is normal, and delete them after successful upload.

3. The black screen recovery and fault feedback system according to claim 1, characterized in that, The three-level recovery operation is at least a reset and restart of the SOC. If the screen module still fails to recover after the SOC has been reset and restarted a preset number of times, the current sleep wake-up ends.

4. The black screen recovery and fault feedback system according to claim 1, characterized in that, The first-level reset operation includes at least attempting a self-reboot and resetting the screen peripherals via the screen MCU.

5. The black screen recovery and fault feedback system according to claim 4, characterized in that, The first-level recovery operation also includes at least reducing the screen brightness and informing the CSC of the actual screen brightness.

6. The black screen recovery and fault feedback system according to claim 5, characterized in that, The first-level recovery operation also includes at least performing a fault upload operation, which is sent to the CSC via the I2C protocol; when the screen power supply voltage exceeds a preset high voltage threshold or the screen power supply voltage is lower than a preset low voltage threshold, a black screen and peripheral device shutdown operation is performed.

7. The black screen recovery and fault feedback system according to claim 1, characterized in that, The secondary reset operation includes at least restarting the display subsystem, lowering the wakeup timer for at least a preset period and then raising it again; and resetting the screen MCU via CSC. If the screen module still fails to recover after the screen MCU has reset a set number of times, the current sleep wake-up ends.

8. The black screen recovery and fault feedback system according to claim 1, characterized in that, The module itself and its driving state or the diagnostic events include at least: detection of screen unlock, SOC and serial chip disconnection, VP error, bit error rate, screen detection of SOC heartbeat abnormality, SOC detection of screen heartbeat abnormality, screen startup process DP error, SOC startup process DP error, CSC SOC detection of screen handshake timeout, CSC MCU detection of screen handshake timeout, screen reporting bit 0~1: no backlight brightness value received, screen reporting bit 2~3: deserializer chip error detection pin status, screen reporting bit 4~5: TFT error detection, screen reporting bit 6~7: TFT LINK, screen reporting bit 0~1: battery overvoltage, screen reporting bit 2~3: battery undervoltage, screen reporting bit 4~5: TP error, screen reporting bit 0~1: Video Lock, the screen will report bits 2~3: backlight error detection, backlight chip error, bits 4~5: OSD function error detection, bits 6~7: backlight temperature detection, bits 2~3: bridge error detection, read serial chip voltage, DP error during operation, and bits 0~1: motor error detection.

9. The black screen recovery and fault feedback system according to claim 8, characterized in that, The following module's own state and driver status, or the diagnostic events, can be determined at least by reading the registers from the MCU screen: The screen displays bits 4-5: TFT error detection; bits 6-7: TFT LINK; bits 4-5: TP error; bits 0-1: Video Lock; bits 2-3: Backlight error detection / backlight chip error; bits 4-5: OSD function error detection; bits 6-7: Backlight temperature detection; and bits 2-3: Bridge error detection.

10. The black screen recovery and fault feedback system according to claim 8, characterized in that, The following module states and driver states, or diagnostic events, are determined at least through heartbeat detection: The screen detected an abnormal SOC heartbeat, and the SOC detected an abnormal screen heartbeat.

Images