A high-orbit spacecraft single-particle sensitive area Boot autonomous repair system and method

Abstract

This application provides an autonomous boot repair system and method for single-event sensitive areas in high-orbit spacecraft, comprising: a processor operation status monitoring unit that outputs a hardware-level operation timeout signal independent of the software state when the main processor malfunctions; a reset pulse signal generation unit that converts the operation timeout signal into a hardware reset request pulse signal; a fault counting and statistics unit that continuously accumulates and counts the continuously generated reset request pulse signals, and outputs a fault trigger signal when a preset threshold is reached; a fault status latching unit that sets the fault trigger signal and outputs a boot switching control signal; and a boot mode autonomous switching unit that forcibly changes the level combination of the main processor boot mode configuration pins according to the boot switching control signal, causing the main processor to switch from internal Flash boot mode to external SPI boot mode. This application can effectively resist single-event upsets, functional interruptions, and single-event burn-out faults caused by protons and heavy ions in the high-orbit space environment.

Description

Technical Field

[0001] This application belongs to the field of aerospace electronic technology, and in particular relates to a boot autonomous repair system and method for single-particle sensitive areas of high-orbit spacecraft. Background Technology

[0002] High-orbit spacecraft operate in geostationary Earth orbit (GEO), located in the core region of Earth's outer radiation belts. The proton flux and linear energy transfer (LET) values ​​experienced by these spacecraft are significantly higher than in low-orbit orbits, resulting in an order-of-magnitude increase in the probability and destructive power of single-event events (SEE). The onboard computer's boot program, stored in the processor's internal Flash memory, is the first piece of code executed after the system powers on and is the core foundation for system startup and application loading. If the boot area is damaged due to SEE, it will directly lead to system startup failure, complete computer failure, and ultimately, mission interruption and loss of on-orbit functionality.

[0003] Current industry technologies for protecting and repairing damage to the Boot zone cannot simultaneously meet the core requirements of high-orbit environments, such as strong radiation, long latency, high autonomy, and low cost, indicating a clear technological bottleneck.

[0004] (1) The internal Flash redundancy backup scheme stores multiple boot copies in the processor's internal Flash memory, and selects the valid image during startup through voting or a copy switching mechanism. However, in the high-orbit, high-radiation environment, single-event effects may simultaneously damage the Flash sectors where multiple backup copies are located, and most aerospace-grade processors' internal Flash memory does not have the hardware automatic error correction capability for multi-bit flips, making it unable to cope with the problem of collective failure of boot copies caused by multiple bit flips. At the same time, the existing scheme only performs static data verification on the boot image, which cannot verify the functional correctness of the image itself, and there is a risk of solidifying potentially defective images into the internal Flash memory.

[0005] (2) External watchdog reset scheme: The system operation status is monitored by an external watchdog circuit, and the system is triggered to reset after a timeout. However, if the Boot area has been irreversibly damaged, the system will never be able to start normally. The watchdog will be trapped in an infinite reset loop, which can only trigger the reset action and cannot fundamentally repair the physical damage to the Boot area.

[0006] (3) FPGA monitoring and repair scheme: An external radiation-hardened FPGA is used to monitor the processor's operating status in real time and store the boot backup image. Repair is achieved by rewriting the processor's internal Flash through the JTAG interface. Although this scheme has high reliability, the cost of a single radiation-hardened FPGA can reach hundreds of thousands of yuan, and the hardware power consumption, size and design complexity are significantly increased, making it unsuitable for miniaturized, low-cost, and mass-produced high-orbit spacecraft platforms.

[0007] (4) Ground command injection repair scheme: commands are remotely issued through the telemetry and control link to complete the Flash image burning repair. However, the one-way delay of the telemetry and control link of high-orbit spacecraft is about 250ms, the communication window is limited, and the link is easily interrupted by space environment such as solar storms. It cannot achieve autonomous and rapid repair after the Boot area is damaged, the fault handling timeliness is extremely poor, and in extreme cases it will lead to the spacecraft being completely out of control.

[0008] (5) Software-dependent counting and switching schemes – It should be noted that there is currently a type of existing technology in the industry that counts the number of boot failures at the software level through the system boot program (such as UBoot or operating system loader) and then switches the boot source. This type of scheme seems logically feasible, but it has fatal technical defects and logical paradoxes: the main body executing its counting and switching functions (the boot program) is stored in the processor's internal Flash or external storage medium. Once a single-event effect causes damage to the Boot area or the boot code itself that carries the counting software, the entire software program will be unable to load and execute, and the fault counting and boot source switching logic will be completely paralyzed. In other words, when the repair mechanism is most needed (the Boot area is damaged, causing the software to be unable to run), this type of software-dependent scheme will fail first. Its essential defect is that it "attempts to use software to repair the problem of the software itself being damaged," and cannot break through the boot deadlock bottleneck.

[0009] In summary, existing technologies cannot simultaneously meet the four core requirements of high-orbit spacecraft boot protection: pure hardware reliability boundaries, fully autonomous operation, extremely low hardware cost, and adaptation to strong radiation environments. There is an urgent need to develop a boot hardening solution that does not rely on expensive radiation-resistant devices, does not rely on the integrity of the software itself, and can autonomously complete the entire process of fault detection, mode switching, service recovery, and background repair in orbit. Summary of the Invention

[0010] In view of this, this application aims to propose an autonomous boot repair system and method for the single-event sensitive area of ​​a high-orbit spacecraft, in order to solve the problems that the system cannot start autonomously after the boot area is damaged by single-event effects in the high-orbit environment, and that "software-dependent repair schemes cannot repair themselves due to their own damage".

[0011] To achieve the above objectives, the technical solution of this application is implemented as follows:

[0012] In a first aspect, this application provides a single-particle sensitive area boot autonomous repair system for a high-orbit spacecraft, wherein the high-orbit spacecraft operates in geosynchronous orbit and includes a boot mode autonomous switching unit, a processor operation status monitoring unit, a reset pulse signal generation unit, a fault counting and statistics unit, a fault status latching unit, and a power supply circuit connected to each other.

[0013] The autonomous boot mode switching unit includes a main processor and external memory. The main processor is an aerospace-grade processor with multi-boot mode configuration capabilities, integrates non-volatile Flash memory, and has boot mode configuration pins and general purpose input / output (GPIO) pins. The external memory is divided into at least a boot repair program area and a main application program area. The main application program area stores an executable copy of the application program that is completely identical to the internal Flash application program. When the boot repair program transfers control, it directly loads and runs the executable copy.

[0014] The processor operating status monitoring unit includes a radiation-resistant crystal oscillator and an oscillation counter, which are used to output a hardware-level operating timeout signal independent of the software state when the main processor is abnormal;

[0015] The reset pulse signal generation unit is used to convert the running timeout signal into a hardware reset request pulse signal;

[0016] The fault counting and statistics unit continuously accumulates the count of the continuously generated reset request pulse signals, and outputs a fault trigger signal when the count value reaches a preset threshold.

[0017] The fault status latching unit is set according to the fault trigger signal and outputs a start switching control signal;

[0018] The startup mode autonomous switching unit forcibly changes the level combination of the main processor startup mode configuration pin according to the startup switching control signal, so that the main processor switches from internal Flash startup mode to external SPI startup mode.

[0019] The power supply circuit provides a stable operating voltage for all components in the system.

[0020] Secondly, based on the same inventive concept, this application also provides a method for autonomous repair of the single-particle sensitive region of a high-orbit spacecraft via boot, implemented based on the system described in the first aspect, including:

[0021] In response to receiving the boot switching control signal, the main processor reads boot data from the external SPI Flash according to the SPI protocol, the main processor enters SPI boot mode, and the on-chip ROM Bootloader loads the boot repair program from the external SPI Flash;

[0022] After the boot repair program starts, it prioritizes loading the executable copy of the application in the external SPI Flash main application area so that the main business function can resume operation within a preset time and re-outputs the run confirmation clear pulse to ensure that the hardware monitoring unit does not time out.

[0023] During interruptions in the main application's continuous operation, a repair program is guided to perform fault diagnosis and repair operations as a background task; the repair includes:

[0024] A graded repair strategy is implemented based on the degree of damage, and shadow boot pre-verification is performed on the new boot image to be written. Dynamic functional verification is used instead of static data verification, and the writing process is managed by operation logs to ensure rollback in case of anomalies.

[0025] After the repair is completed, the fault count and fault status latch unit are cleared, the boot mode configuration pin configuration of the main processor is restored, and a software reset is triggered. The main processor then boots normally from the internal Flash.

[0026] Compared with existing technologies, the single-particle sensitive area boot autonomous repair system and method for high-orbit spacecraft described in this application has the following advantages:

[0027] This application achieves automatic detection of startup failures and autonomous forced switching of startup modes by constructing a pure hardware fault isolation domain independent of the processor software state; relying on the processor's natively solidified, tamper-proof, and single-event upset-resistant ROM bootloader, it loads the boot repair program from the external radiation-resistant SPI Flash and prioritizes the restoration of main business operations; the boot repair program, in the form of an interrupt-driven background task, adopts a hierarchical repair strategy, shadow boot pre-verification, and segmented repair writing mechanism to autonomously complete the diagnosis and repair of the internal boot sector, without ground intervention or reliance on expensive radiation-resistant FPGAs, while significantly reducing hardware costs. Attached Figure Description

[0028] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0029] Figure 1 This is a schematic diagram of the structure of a single-particle sensitive area boot autonomous repair system for a high-orbit spacecraft as described in an embodiment of this application;

[0030] Figure 2 This is a diagram showing the external SPI Flash memory space partitioning as described in the embodiments of this application;

[0031] Figure 3This is a flowchart illustrating the overall workflow of a single-particle sensitive area boot autonomous repair system for a high-orbit spacecraft, as described in an embodiment of this application.

[0032] Figure 4 This is a flowchart illustrating the hierarchical repair decision-making process of the boot repair procedure as described in the embodiments of this application;

[0033] Figure 5 This is a flowchart of the shadow startup pre-verification process described in an embodiment of this application;

[0034] Figure 6 This is a flowchart illustrating the segmented repair writing process described in the embodiments of this application;

[0035] Figure 7 This is a diagram showing the partitioning of the internal Flash storage space of the main processor as described in the embodiments of this application;

[0036] Figure 8 This is a flowchart illustrating the boot repair procedure anomaly protection process described in an embodiment of this application;

[0037] Figure 9 This is a flowchart illustrating the application startup process in the internal Flash memory of the main processor as described in an embodiment of this application. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0039] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0040] Key Terminology Definitions: To clarify the scope of protection, the term "Boot program" in this application specifically refers to the first-level startup code stored in the main processor's internal Flash memory at the starting address, used to boot and load the application. Damage to this code will prevent the system from booting from the internal Flash. The term "boot repair program" specifically refers to an independent tool program stored in the external SPI Flash boot repair program area, used to diagnose and repair the internal Flash Boot area. It differs from the Boot program in physical storage medium, functional responsibilities, and code content, and the two are not interchangeable. "Foreground service recovery" refers to the boot repair program prioritizing the transfer of control to the external Flash application copy after startup, enabling the main service to resume operation within seconds. "Background transparent repair" refers to the diagnostic and repair operations being performed in a time-sharing manner during the main service operation, driven by hardware timer interrupts, and completely transparent to the main service.

[0041] The embodiments of this application are described in detail below with reference to the accompanying drawings.

[0042] Example 1

[0043] Please see Figure 1 As shown, this embodiment provides a single-particle sensitive area boot autonomous repair system for a high-orbit spacecraft. The high-orbit spacecraft operates in geosynchronous orbit and includes a boot mode autonomous switching unit, a processor operation status monitoring unit, a reset pulse signal generation unit, a fault counting and statistics unit, a fault status latching unit, and a power supply circuit connected to each other.

[0044] The autonomous startup mode switching unit includes a main processor and external memory. The main processor is an aerospace-grade processor with multiple startup mode configuration functions. It integrates non-volatile Flash memory to store the Boot program and application program. The processor with multiple startup mode configuration functions generally has a startup mode configuration pin BCFG[3:0]. By configuring different level combinations, it can select multiple startup modes such as internal Flash startup, SPI startup, and SCI startup. For example, BCFG[3:0] is 1111 to indicate startup from internal Flash, 1100 to indicate startup from external SPI, 1101 to indicate startup from SCI, and 1110 to indicate startup from SD card. The processor also provides two general purpose input / output (GPIO) pins. One of them is used to output the run confirmation clear pulse RUN_CLR_PULSE, and the other is used to output the fault count clear or repair completion clear signal BAD_CLR_PULSE.

[0045] In this embodiment, the core functional pin definitions and connection relationships of the main processor U2 are as follows:

[0046] GPIO_PH2 pin: Run confirmation clear output pin, used to periodically output RUN_CLR_PULSE pulse signal, connected to the CLR clear terminal of oscillation counter U1;

[0047] GPIO_PH3 pin: Fault count clearing and repair completion clearing output pin, used to periodically output BAD_CLR_PULSE pulse signal, connected to the clearing terminal of the fault count statistics unit and the fault status latch unit C1;

[0048] nRST pin: Active low reset input pin, connected to a 3.3V power supply via a pull-up resistor, and connected to the output of the reset pull-down circuit of NMOS transistor Q5 controlled by the RESET_REQ_PULSE signal;

[0049] BCFG0 and BCFG1 pins: Startup mode configuration pins, which control the two NMOS transistors Q6 and Q7 to pull the branch level low or pull it up via the RECOVERY_EN signal;

[0050] BCFG2 and BCFG3 pins: are fixed to a 3.3V power supply via pull-up resistors;

[0051] SPI Interface: Includes CS, SCK, MOSI, and MISO pins, which are connected to the corresponding pins of the SPI Flash. Specifically, the CS pin of the SPI Flash is connected to the SPI0_CS pin of the main processor U2, the CLK pin is connected to the SPI0_SCK pin, the SI pin is connected to the SPI0_MOSI pin, and the SO pin is connected to the SPI0_MISO pin; the WP and HOLD pins are connected to a 3.3V power supply to enable hardware write protection and hold functions; the power supply pin of the Flash is connected to a 3.3V power supply and configured with a 0.1μF decoupling capacitor to filter out power supply noise and ensure the stability of SPI communication.

[0052] The external memory uses aerospace-grade radiation-resistant SPI NOR Flash, which is connected to the main processor's SPI boot interface via the SPI bus. Figure 2 As shown, its internal storage space is divided into a boot repair program area, a main application area, and a data storage area.

[0053] Specifically, the main application area stores a complete executable copy of the application that is identical to the App area in the internal Flash. When the boot repair program transfers control, it directly loads and runs this executable copy.

[0054] The data storage area contains a Boot redundant image library, an operation log area, a Boot area status snapshot area, and a repair event record area.

[0055] The Boot Redundancy Image Library stores two types of Boot image data: The first type is a complete Boot image, consisting of three copies. Each copy is a complete image of the Boot program firmware, with an independent ECC checksum and CRC32 checksum, and includes a version number and minimum hardware compatibility code. The three complete images are stored in three non-contiguous physical address areas. The second type is sector-level independent images, with three independent images stored for each sector of the Boot area. Each sector image has an independent CRC checksum and supports direct reading by sector index. The three copies of each sector are also stored in non-contiguous physical address areas.

[0056] The operation log area adopts a dual-zone redundant backup design, including a main log area and a mirror log area, and each log entry contains a single checksum.

[0057] The Boot sector status snapshot area is used to store the sector checksums and timestamp snapshots generated by the boot repair program when the system is in the internal Flash normal boot mode, during which the boot sector is periodically checked for read-only verification.

[0058] The processor operation status monitoring unit is used to monitor whether the main processor continues to run to the preset critical program path. It mainly includes a radiation-resistant crystal oscillator and a radiation-resistant oscillation counter. The crystal oscillator generates a periodic clock signal to provide an independent timing reference for the oscillation counter. When the main processor is running normally, it periodically outputs the RUN_CLR_PULSE pulse signal through the GPIO pin to clear the oscillation counter. When the main processor is abnormal and cannot output the RUN_CLR_PULSE pulse signal, the oscillation counter continues to count and outputs the operation timeout signal RUN_TIMEOUT to the reset pulse signal generation unit after reaching the preset time T=3 seconds.

[0059] Specifically, crystal oscillator Y1 outputs a standard clock signal (1MHz in this embodiment), which is directly fed into the CLK1 input terminal of oscillation counter U1. The CLR terminal of U1 is connected to the RUN_CLR_PULSE signal output terminal of the main processor U2, and simultaneously receives the clear signal of the reset request pulse RESET_REQ_PULSE. When RUN_CLR_PULSE arrives periodically, U1 is periodically cleared to zero and does not output the RUN_TIMEOUT signal. When the main processor abnormally stops outputting the RUN_CLR_PULSE signal, oscillator U1 continues to count, and outputs the RUN_TIMEOUT timeout signal after reaching the preset threshold T=3 seconds.

[0060] The RUN_TIMEOUT signal is input to the Schmitt trigger shaper U3, which, after shaping, triggers the monostable pulse generator U4. The monostable pulse generator U4 outputs a fixed-width reset request pulse RESET_REQ_PULSE. This pulse is applied to the nRST pin of the main processor U2 via the NMOS transistor Q5 pull-down circuit to achieve system reset; another path is sent to the CLK terminal of the fault counting and statistics unit to accumulate the number of consecutive abnormal resets; and the third path is sent back to the CLR terminal of the oscillator counter U1, so that the oscillator counter U1 resumes its initial timing state after a timeout reset.

[0061] The reset pulse signal generation unit converts the runtime timeout signal RUN_TIMEOU into a reset request pulse with a defined width and clear edges. This unit mainly consists of a Schmitt trigger and a monostable multivibrator. The RUN_TIMEOUT signal output from the processor running status monitoring unit is shaped by the Schmitt trigger and then input to the monostable multivibrator. The monostable multivibrator outputs a reset request pulse signal RESET_REQ_PULSE with a fixed pulse width. This pulse controls the open-drain, open-collector, or NMOS pull-down circuit to pull the reset pin nRST of the main processor U2 low. On the other hand, it serves as the counting clock for the fault counting and statistics unit and is simultaneously sent back to the clear terminal CLR of the oscillation counter U1 in the processor running status monitoring unit, so that the processor running status monitoring unit restarts the timing after a reset request is completed.

[0062] The fault counting and statistics unit is used to continuously accumulate and count the reset request signal RESET_REQ_PULSE, and to determine whether the main processor has experienced multiple abnormal resets that fail to complete normal startup. This unit mainly consists of a radiation-hardened trigger or binary counter, a count clearing circuit, and a threshold decoding circuit. The count input receives the RESET_REQ_PULSE signal, and the clearing input receives the fault count clearing or repair completion clearing signal BAD_CLR_PULSE output by the main processor. When the accumulated value of the continuous reset request pulse signal RESET_REQ_PULSE reaches a preset threshold, the threshold decoding circuit outputs the fault trigger signal Fault_Trigger_Signal.

[0063] Specifically, such as Figure 1 As shown, the fault counting and statistics unit accumulates the RESET_REQ_PULSE count, and the counting threshold N is preferably 3. The fault counting and statistics unit can be composed of radiation-resistant triggers such as FF1 to FF4, counters, and gate circuits; when the accumulated number reaches N=3, the threshold decoding circuit outputs a fault trigger signal, the fault state latch unit C1 is set, and RECOVERY_EN is output.

[0064] RECOVERY_EN controls two NMOS or equivalent open-drain branches to low via current-limiting resistors. The two low-pull branches are connected to the BCFG0 and BCFG1 pins of the main processor U2, respectively. The BCFG0 and BCFG1 pins are simultaneously connected to a 3.3V power supply via pull-up resistors, while the BCFG2 and BCFG3 pins are directly pulled up to a 3.3V power supply via resistors. When RECOVERY_EN is valid, BCFG0 and BCFG1 are forced low, and BCFG[3:0] forms a 1100 level combination, and the main processor U2 switches to SPI boot mode. When RECOVERY_EN is invalid, BCFG0 and BCFG1 are pulled high, forming a 1111 level combination with BCFG2 and BCFG3, and the main processor U2 boots from the internal Flash by default.

[0065] The fault state latch unit is used to generate a control signal for autonomous switching of the startup mode state using its fault trigger signal Fault_Trigger_Signal after the fault counting and statistics unit reaches a preset threshold. The set terminal of this unit receives the fault trigger signal Fault_Trigger_Signal, and the reset terminal receives the repair completion clear signal or the power-on clear signal BAD_CLR_PULSE output by the main processor; after being set, it outputs the RECOVERY_EN signal, which remains valid during the processor reset, ensuring that BCFG[3:0] has been stably switched to the external SPI startup mode before the reset release; after the repair is completed, the main processor outputs the clear signal BAD_CLR_PULSE to reset the unit, and RECOVERY_EN is invalid.

[0066] The power supply circuit provides a stable operating voltage for all components in the system, and also integrates power filtering, reverse connection protection, and overcurrent protection functions. It should be noted that the power supply circuit uses a conventional power module, which is not shown in the attached diagram.

[0067] Before the reset pulse is released, the BCFG[3:0] pin level of the main processor U2 has stabilized at 1100. After the reset is released, the main processor samples the 1100 combination and automatically enters the SPI boot branch of the on-chip ROM Bootloader, reading the boot data from the starting address of the external SPI Flash. A boot repair program conforming to the ROM Bootloader boot header format is pre-programmed into the external SPI Flash. After the ROM Bootloader verifies the boot header, it loads the boot repair program into the specified address of the main processor's internal RAM, and then jumps to the program entry address for execution.

[0068] After the boot repair program runs, it completes the minimum system initialization, loads and jumps to the external Flash main application area to restore business functions. Before the boot repair program transfers control, it configures a hardware timer to periodically interrupt and point to the background repair task entry point in the boot repair program area. After the background repair task is triggered by the interrupt, it performs diagnosis and hierarchical repair in the internal Flash Boot area. After the repair is completed, it outputs a BAD_CLR_PULSE clear signal through the GPIO_PH3 pin to clear the fault count statistics unit and the fault status latch unit, invalidating RECOVERY_EN, turning off the low-pull branches of NMOS transistors Q6 and Q7, restoring BCFG0 and BCFG1 to the high-level state, and restoring BCFG[3:0] to the 1111 main processor boot mode from internal Flash. Finally, the boot repair program triggers a software reset, the main processor U2 is powered on again and starts up normally from the repaired Boot area.

[0069] This application relies entirely on the processor's native hardware mechanism and does not require modification of the processor's underlying design. After detecting multiple consecutive startup failures, it forces the BCFG[3:0] to switch to 1100 through a pure hardware circuit autonomous switching mechanism, so that the processor can automatically start the repair program from the external SPI Flash. During the operation of the external SPI Flash main application, it performs diagnostic and repair operations through a background interrupt-driven mechanism, thereby achieving fully autonomous repair of the processor's internal Boot area.

[0070] like Figure 1 As shown, the core hardware of the high-orbit spacecraft Boot autonomous repair system described in this embodiment includes: a main processor U2 (taking JR32RV301 as an example), a radiation-resistant active crystal oscillator Y1 (taking VX-705 as an example), an oscillation counter U1 (taking M54HC4060 as an example), a Schmitt trigger U3 (taking M54HC14 as an example), a monostable pulse generator U4 (taking M54HC123 as an example), a fault counting and statistics unit (composed of flip-flops or equivalent counters such as FF1 to FF4, with a threshold N=3), a threshold decoding gate circuit (composed of And1 to And3), a fault state latch unit C1, nRST and BCFG[3:0] open-drain or NMOS low-pull-down branches, a radiation-resistant SPI Flash U5 (taking AT25SF041-SSHD-T as an example), and supporting passive devices such as aerospace-grade thin-film resistors and high-reliability MLCC ceramic capacitors. It should be noted that the above device models are merely examples, and this application is not limited to the specific models listed. Any device that meets aerospace-grade radiation resistance requirements and has equivalent functions can be used as a substitute.

[0071] Example 2

[0072] This embodiment also provides a method for autonomous repair of single-event sensitive areas in high-orbit spacecraft via Boot, which specifically includes the following steps:

[0073] In response to receiving the boot switching control signal, the main processor reads boot data from the external SPI Flash according to the SPI protocol, the main processor enters SPI boot mode, and the on-chip ROM Bootloader loads the boot repair program from the external SPI Flash;

[0074] After the boot repair program starts, it prioritizes loading the executable copy of the application in the external SPI Flash main application area so that the main business function can resume operation within a preset time and re-outputs the run confirmation clear pulse to ensure that the hardware monitoring unit does not time out.

[0075] During interruptions in the main application's continuous operation, a repair program is guided to perform fault diagnosis and repair operations as a background task; the repair includes:

[0076] A graded repair strategy is implemented based on the degree of damage, and shadow boot pre-verification is performed on the new boot image to be written. Dynamic functional verification is used instead of static data verification, and the writing process is managed by operation logs to ensure rollback in case of anomalies.

[0077] After the repair is completed, the fault count and fault status latch unit are cleared, the boot mode configuration pin configuration of the main processor is restored, and a software reset is triggered. The main processor then boots normally from the internal Flash.

[0078] Specifically, the complete workflow of the system described in this embodiment is as follows: Figure 3 As shown, it is divided into four stages: normal mode, fault mode, repair mode, and recovery mode. The entire process is completely autonomous and requires no ground intervention. Details are as follows:

[0079] Normal mode:

[0080] The main processor boots from the internal Flash by default. The Boot program loads and runs the application. The application sets a high-priority run confirmation clearing task and periodically outputs a run confirmation clearing pulse RUN_CLR_PULSE through the GPIO pin, so that the oscillation counter is periodically cleared and no run timeout signal RUN_TIMEOUT is generated. At the same time, during system initialization, the fault counting and statistics unit and the fault status latch unit are cleared through another GPIO to ensure that the fault counting starts from 0. At this time, BCFG[3:0] is configured as 1111 by default (internal Flash boot mode), and the system runs normally on the rail.

[0081] When the system is in the normal boot mode of the internal Flash, the application running in the internal Flash periodically checks the boot repair program image in the external SPI Flash, and automatically completes the repair if an anomaly is found.

[0082] Failure mode:

[0083] The boot area is damaged due to a single-event event, preventing the system from starting normally and applications from running. The output of the RUN_CLR_PULSE run confirmation clear pulse signal has stopped.

[0084] The oscillation counter U1 continues to count until the preset timeout time T=3 seconds, and outputs the RUN_TIMEOUT signal. The RUN_TIMEOUT signal is used by the reset pulse generation unit to generate the RESET_REQ_PULSE signal, which resets the main processor U2.

[0085] The fault counting unit accumulates the RESET_REQ_PULSE signal and increments the count by 1. The decoding circuit determines in real time whether the cumulative number of RESET_REQ_PULSE has reached the preset threshold N=3. If it has not reached the threshold, the above reset process is repeated. If the threshold is reached, the fault trigger signal Fault_Trigger_Signal is output to the fault state latch unit. The fault state latch unit is set and outputs the RECOVERY_EN signal. This signal controls the operation of the startup mode autonomous switching unit circuit, which configures BCFG[3:0] to 1100 so that the main processor enters the SPI startup mode.

[0086] The system resets again, the main processor U2 samples the BCFG[3:0] pin level, enters SPI startup mode, and switches to repair mode.

[0087] Specifically, in this embodiment, the mode includes two stages, as follows:

[0088] Fault detection phase: If the boot area of ​​the internal Flash is damaged due to single-event effect, the main processor cannot complete the normal startup, the application cannot run, and therefore cannot generate the periodic RUN_CLR_PULSE signal.

[0089] The oscillation counter continues counting until the preset timeout period T=3 seconds, at which point it outputs a RUN_TIMEOUT signal. This signal, after being shaped, triggers a monostable pulse generator to generate a RESET_REQ_PULSE pulse signal. This pulse signal resets the main processor and, on the other hand, acts as the clock for the fault counting and statistics unit, incrementing the count value by 1 and simultaneously clearing the oscillation counter. After the main processor is reset, it attempts to boot from the internal Flash again, but fails due to damage to the Boot area, repeating the above timeout, reset, and counting process.

[0090] Threshold triggering stage: When the continuous reset count value of the fault counting unit reaches the preset threshold (N=3 times), its threshold decoding circuit outputs the fault trigger signal Fault_Trigger_Signal to the fault state latch unit. The fault state latch unit is set and outputs the RECOVERY_EN signal. The RECOVERY_EN signal controls the two open-drain or NMOS low-pull branches to be turned on, forcibly pulling the BCFG0 and BCFG1 pins low. At this time, the BCFG[3:0] level combination becomes 1100 (SPI boot mode). Before the subsequent reset release, BCFG[3:0] remains stable. When the next reset pulse arrives, the main processor samples the BCFG[3:0] pin level, enters the SPI boot branch of the ROM Bootloader, and loads the boot repair program from the external SPI Flash to run.

[0091] Repair Mode:

[0092] After the fault count reaches the threshold N=3, the fault state latch unit C1 outputs the RECOVERY_EN signal, BCFG[3:0] is locked to 1100, the main processor U2 enters the SPI boot mode, and the main processor U2 automatically moves the boot repair program in the external SPI Flash to the on-chip RAM and runs it through the on-chip ROM Bootloader;

[0093] After the boot repair program completes the minimum system initialization, it loads and jumps to the external SPI Flash main application area to restore the business functions. In repair mode, the application runs from the external SPI Flash, and the integrity check of the boot repair program is paused. It will resume after the system is restored to the normal boot mode of the internal Flash.

[0094] Before the boot repair program transfers control, a hardware timer interrupt is configured. After the background repair task is periodically woken up, it attempts to access the internal Flash controller to obtain fault information, performs hierarchical diagnosis and repair, and completes the internal Boot area repair through shadow boot pre-verification and segmented repair writing.

[0095] After the repair is completed, the BCFG[3:0] pin level is read and voted three times to confirm that it is restored to 1111. The fault count unit and fault status latch unit are cleared, RECOVERY_EN is invalidated, the startup mode configuration is restored, and a software reset is triggered.

[0096] Specifically, in this embodiment, the main processor's ROM bootloader reads boot data from the external SPI Flash according to the SPI protocol. After verification, it loads the boot repair program into the main processor's internal RAM and jumps to execute it. After completing the minimum system initialization, the boot repair program loads and jumps to the external SPI Flash main application area, enabling the main business functions to resume operation. The main application periodically outputs the RUN_CLR_PULSE signal to avoid timeout of the processor's running status monitoring unit. During this stage, the main application is loaded and runs from the external SPI Flash main application area, which is different from the path of loading the application from the internal Flash in normal mode. The executable copies of the application stored in the two locations are completely identical. Before the boot repair program transfers control, it configures a hardware timer to periodically interrupt and point to the background repair task entry in the boot repair program area. When the interrupt is triggered, the CPU jumps to the boot repair program area to perform diagnostic and repair operations. After completion, it returns to the main application area to continue running. After the background repair task is awakened, it executes a hierarchical repair decision process, such as... Figure 4 As shown. The specific steps are as follows:

[0097] S301. Fault Diagnosis and Classification: After the boot repair program background task is awakened, it first attempts to access the internal Flash controller via the processor's internal bus. If the internal Flash controller is responsive, it reads its status register to obtain the result status of the last programming / erasing operation, and performs a sector-by-sector integrity scan of the Boot area, calculating the check value of each sector and comparing it with the pre-stored correct value. Simultaneously, it compares the data with the most recent snapshot data in the Boot area's status snapshot area—if the snapshot shows that a sector has a single-event flip record in historical inspections, then if this check fails, it will not attempt first-level repair and will directly process it according to second-level or higher. If the internal Flash controller is unresponsive, all sectors of the Boot area are conservatively marked as damaged and directly processed according to level three full-scale overwrite repair. To eliminate the single-event vulnerability in the diagnostic process, the above reading and judgment are executed three times consecutively, with a majority vote.

[0098] Based on the diagnostic results, the damage is classified into four levels: Level 1 is a single-bit correctable error; Level 2 is a multi-bit flip with the damaged sector accounting for no more than 50%; Level 3 is a damaged sector accounting for more than 50%; and Level 4 is a physically permanent sector failure.

[0099] S302, Tiered Repair: Corresponding strategies are executed for each of the four levels. Level 1 involves writing back single bytes or pages after ECC error correction, without sector erasure. Level 2 extracts the correct data blocks corresponding to the failed sectors from the sector-level independent images in the redundant image library according to sector indexes, and performs partial replacement. Level 3 selects a complete Boot image that has passed verification from the redundant image library, and after passing shadow verification, performs a full overwrite using a segmented repair write method. Level 4 remaps the logical addresses of the failed sectors to spare sectors; when spare sectors are exhausted, a permanent external boot scheme is activated.

[0100] S303, Shadow Boot Pre-verification: For new boot images involved in Level 3 full-coverage repair and Level 4 spare sector mapping, shadow boot pre-verification must be performed before writing to the internal Flash. During each boot initialization, the boot repair program first forcibly enables hardware timer interrupts to override any interrupt disabling states that may have been left over from a previous abnormal termination of shadow verification, ensuring that the interrupt source for the background repair task is always available. The shadow boot pre-verification process is as follows: Figure 5 As shown.

[0101] The verification process includes: allocating a continuous region in SRAM of the same size as the Boot region as a shadow Boot region; loading the candidate image and saving the CPU context; configuring the vector table base address to point to the shadow region; setting the periodic output of the RUN_CLR_PULSE signal; jumping to execute the complete board-level initialization sequence; and confirming the functional correctness of the Boot image through a combination of three-modulus redundancy status word voting and timeout determination.

[0102] During shadow verification, the main loop of the boot repair program periodically outputs the RUN_CLR_PULSE signal to prevent the oscillation counter from continuously counting to the preset timeout period before outputting the RUN_TIMEOUT signal. If shadow verification triggers the RUN_TIMEOUT signal due to timeout, and the hardware circuitry remains in SPI boot mode after system restart, the boot repair program will restart and attempt repair again. If verification fails, the next complete boot image from the redundant image library will be selected sequentially for reloading and verification. If all images fail, the repair will be abandoned and fault information will be downloaded.

[0103] S304, Segmented Repair Write: The segmented repair write process is as follows... Figure 6 As shown. All Flash write operations are managed using an operation log, and the operation log area employs dual-zone redundant backup.

[0104] The writing steps include: recording the start of the write operation in the log area, including the operation type, the list of sectors to be written, the image source version number, and the current time;

[0105] Erasure and programming are performed sector by sector, followed by a readback and comparison. If the comparison matches, the sector is marked as complete; otherwise, the erasure is retried, with a maximum of three retries. If all three attempts fail and it is a Level 2 partial replacement scenario, the process transitions to Level 4 spare sector mapping. The spare sector mapping operation is a continuation of the current write sequence. Mapping information is recorded in the operation log, and final confirmation is completed. If spare sector mapping also fails, the current write sequence is rolled back, the allocated spare sectors are released, and the entire Boot is migrated to another available area of ​​the internal Flash or a permanent external boot is activated. In Level 3 full overwrite scenarios, the current write sequence is aborted, the information of incomplete sectors is written to the log, and the process transitions to Level 4, with the same handling method as above.

[0106] After all sectors pass verification, a two-step process of pre-confirmation and final confirmation is executed. First, a pre-confirmation record is written to the log area. Then, the new version number and overall CRC are written to the Boot area version information area. After the version information is successfully written, a confirmation mark for operation completion is written. If a reset occurs during the writing process, the system restarts and scans the operation log: for writes that have been pre-confirmed but not yet finally confirmed, the actual status is determined based on the comparison result of the version information area; writes that have not been confirmed are resumed from the breakpoint; if there is no trusted execution bitmap, a full rollback and rewrite are performed. If both the main log area and the mirror log area fail verification and are unrecoverable, log recovery is abandoned, and the complete writing process is re-executed for all sectors involved in the current write, with redundant images covering the corresponding areas of the internal Flash, ensuring that the Boot area is restored to a definite state.

[0107] After transitioning to the fourth level, the spare sector mapping operation is a continuation of the current write sequence. The mapping information is recorded in the operation log and the final confirmation is completed together. If the spare sector mapping also fails, the current write sequence is rolled back, the allocated spare sectors are released, and the entire Boot is migrated to other available areas of the internal Flash or a permanent external boot is activated.

[0108] When designing the boot program, it was agreed that it would check the consistency of version tags in each sector upon startup. This version tag consistency check mechanism is an inherent function of the boot program and has been included since the first on-rail version. All boot backup images stored in the redundant image library have this mechanism. If the tags are inconsistent, it indicates that the write operation is incomplete, and the boot program automatically jumps to the boot repair program in the external Flash memory, rather than executing in a partially corrupted state.

[0109] S305, Repair Completion: After the repair is completed, clear all pending interrupt flags. The repair program outputs a clear signal through the GIO pin to clear the fault count statistics unit and the fault status latch unit, invalidating RECOVERY_EN. BCFG0 and BCFG1 are pulled up to the high level. The BCFG[3:0] pin level status is read three times consecutively and voted to confirm that it has been restored to 1111 (internal Flash boot mode). Finally, a software reset is executed to complete the repair process.

[0110] Recovery Mode:

[0111] After system reset, BCFG[3:0] returns to 1111, the main processor U2 enters the internal Flash boot mode, and starts normally from the repaired Boot area. The Boot program loads the application, the application resumes normal operation, and the periodic operation confirmation clearing signal RUN_CLR_PULSE is restarted. The system is fully restored to normal mode, resumes the periodic integrity check of the boot repair program, and completes the entire process of self-repair of Boot damage.

[0112] Example 3

[0113] This embodiment also includes protection against boot repair program anomalies, specifically including the following:

[0114] like Figure 7 As shown, the internal Flash storage space of the main processor U2 is divided into three core fixed address areas: the Boot image file startup area, the App image file backup area, and the boot repair program image backup area. The App image file backup area stores multiple identical application images, and the boot repair program image backup area stores multiple identical boot repair program standard images.

[0115] When the system is in internal Flash normal boot mode, the main processor U2 application running on the internal Flash periodically performs integrity checks on the boot repair program in the external SPI Flash. When the system is in external Flash boot mode, the above checks are paused and resumed after the system returns to internal Flash normal boot mode. The application's check cycle for the boot repair program and the boot repair program's status check cycle for the Boot area are staggered, with the latter having higher priority than the former. The two are mutually exclusive accessed through the Flash controller.

[0116] The specific processing procedure is as follows: Figure 8As shown, the application periodically reads multiple image data from the boot repair program image backup area of ​​the internal Flash, generates a standard repair program image using a bit-by-bit voting method, and simultaneously reads the boot repair program image in the external SPI Flash for byte-by-byte comparison; if the comparison is inconsistent, the boot repair program image storage area in the external SPI Flash is erased, the standard image generated by the vote is written and CRC32 verification is completed, forming a complete protection closed loop.

[0117] Example 4

[0118] This embodiment also incorporates redundant design for application startup, as detailed below:

[0119] The main processor U2's internal Flash memory stores multiple identical application images in its backup area. The application startup process is as follows: Figure 9 As shown: After the system is powered on and reset, the main processor U2 moves the boot image to the internal SRAM and runs it through the on-chip ROM bootloader; the boot program running in the SRAM reads multiple application images from the App image file backup area, eliminates erroneous data caused by single-event upsets through bit-by-bit voting, generates a standard application image, moves it to the internal SRAM and jumps to execute it;

[0120] The application periodically outputs the RUN_CLR_PULSE signal immediately after startup. When the system is in the internal Flash normal boot mode, the application periodically performs integrity checks and repairs on the boot repair program in the external SPI Flash; when the system is in the external Flash boot mode, the above checks are paused.

[0121] 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 therein. Such 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, and they should all be covered within the scope of the claims and specification of the present invention.

[0122] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.

Claims

1. A single-particle sensitive area boot autonomous repair system for a high-orbit spacecraft, wherein the high-orbit spacecraft operates in geosynchronous orbit, characterized in that: It includes a startup mode autonomous switching unit, a processor running status monitoring unit, a reset pulse signal generation unit, a fault counting and statistics unit, a fault status latching unit, and a power supply circuit that are connected to each other. The autonomous boot mode switching unit includes a main processor and external memory. The main processor is an aerospace-grade processor with multi-boot mode configuration capabilities, integrates non-volatile Flash memory, and has boot mode configuration pins and general purpose input / output (GPIO) pins. The external memory is divided into at least a boot repair program area and a main application program area. The main application program area stores an executable copy of the application program that is completely identical to the internal Flash application program. When the boot repair program transfers control, it directly loads and runs the executable copy. The processor operating status monitoring unit includes a radiation-resistant crystal oscillator and an oscillation counter, which are used to output a hardware-level operating timeout signal independent of the software state when the main processor is abnormal; The reset pulse signal generation unit is used to convert the running timeout signal into a hardware reset request pulse signal; The fault counting and statistics unit continuously accumulates the count of the continuously generated reset request pulse signals, and outputs a fault trigger signal when the count value reaches a preset threshold. The fault status latching unit is set according to the fault trigger signal and outputs a start switching control signal; The startup mode autonomous switching unit forcibly changes the level combination of the main processor startup mode configuration pin according to the startup switching control signal, so that the main processor switches from internal Flash startup mode to external SPI startup mode. The power supply circuit provides a stable operating voltage for all components in the system.

2. The single-event sensitive area boot autonomous repair system for high-orbit spacecraft according to claim 1, characterized in that: The reset pulse signal generation unit consists of a Schmitt trigger and a monostable multivibrator. The RUN_TIMEOUT signal output by the processor running status monitoring unit is shaped by the Schmitt trigger and then input to the monostable multivibrator. The monostable multivibrator outputs a reset request pulse signal with a fixed pulse width.

3. The single-event sensitive area boot autonomous repair system for high-orbit spacecraft according to claim 1, characterized in that: The fault counting and statistics unit consists of an anti-radiation trigger or counter, a count clearing circuit and a threshold decoding circuit. The count input terminal receives a reset request pulse signal, and the clearing terminal receives a fault count clearing or repair completion clearing signal output by the main processor. When the cumulative value of the continuous reset request pulse signal reaches the preset threshold, the threshold decoding circuit outputs a fault trigger signal.

4. The single-event sensitive area boot autonomous repair system for high-orbit spacecraft according to claim 1, characterized in that: The external memory is connected to the SPI boot interface of the main processor via the SPI bus. Its internal storage space is also divided into a data storage area, which contains a Boot redundancy image library, an operation log area, a Boot area status snapshot area, and a repair event record area. The Boot Redundancy Image Library stores two types of Boot image data: the first type is a complete Boot image, which has multiple copies and is stored in different non-contiguous physical address regions; the second type is a sector-level independent image, with multiple copies stored in each sector, and each with an independent CRC checksum. The operation log area adopts dual-zone redundancy backup of primary and mirror areas, and each log entry contains a single check code. The Boot area status snapshot area is used to store sector check values ​​and timestamps generated by the boot repair program when periodically inspecting the Boot area during the period when the system is in the internal Flash normal boot mode.

5. A method for autonomous repair of a single-event sensitive region in a high-orbit spacecraft, implemented based on the system described in any one of claims 1 to 4, characterized in that, include: In response to receiving the boot switching control signal, the main processor reads boot data from the external SPI Flash according to the SPI protocol, the main processor enters SPI boot mode, and the on-chip ROM Bootloader loads the boot repair program from the external SPI Flash; After the boot repair program starts, it prioritizes loading the executable copy of the application in the external SPI Flash main application area so that the main business function can resume operation within a preset time and re-outputs the run confirmation clear pulse to ensure that the hardware monitoring unit does not time out. During interruptions in the main application's continuous operation, a repair program is guided to perform fault diagnosis and repair operations as a background task; the repair includes: A graded repair strategy is implemented based on the degree of damage, and shadow boot pre-verification is performed on the new boot image to be written. Dynamic functional verification is used instead of static data verification, and the writing process is managed by operation logs to ensure rollback in case of anomalies. After the repair is completed, the fault count and fault status latch unit are cleared, the boot mode configuration pin configuration of the main processor is restored, and a software reset is triggered. The main processor then boots normally from the internal Flash.

6. The method for autonomous repair of a single-event sensitive region in a high-orbit spacecraft according to claim 5, characterized in that, The fault diagnosis includes: Access the internal Flash controller to obtain the status, and combine it with the historical data of the Boot area status snapshot area to classify the damage into four levels: single bit correctable, multiple bit flipped and the damaged sector does not exceed 50%, the damaged sector exceeds 50%, and the sector is physically permanently failed.

7. The method for autonomous repair of a single-event sensitive region in a high-orbit spacecraft according to claim 6, characterized in that, The graded repair strategy includes: The first level involves writing back a single byte or page after ECC error correction, without requiring sector erasure. The second level involves extracting the correct data blocks corresponding to the failed sectors from the sector-level independent images of the redundant image library according to the sector index, and performing local replacement. The third level involves selecting a complete Boot image from the redundant image library that has passed verification, and then fully overwriting it using a segmented repair writing method after passing shadow verification. The fourth level involves remapping the logical addresses of failed sectors to spare sectors, and activating a permanent external boot scheme when spare sectors are exhausted.

8. The method for autonomous repair of a single-event sensitive region in a high-orbit spacecraft according to claim 5, characterized in that: For the new boot image involved in the Level 3 full coverage repair and Level 4 spare sector mapping, pre-verification is performed via shadow boot before writing to the internal Flash. During each startup initialization, the boot repair program first forcibly enables the hardware timer interrupt to overwrite the interrupt disabling state left by the previous shadow verification's abnormal termination, ensuring that the interrupt source for the background repair task is always available; the verification process includes: A shadow boot area is constructed in SRAM, a candidate image is loaded and a complete board-level initialization sequence is executed, and the correctness of the function is confirmed by both status word voting and timeout.

9. The method for autonomous repair of a single-event sensitive region in a high-orbit spacecraft according to claim 5, characterized in that: When the system is in the normal boot mode of the internal Flash, the application running in the internal Flash periodically reads the boot repair program backup image stored internally and compares it with the boot repair program image in the external SPI Flash. If they are inconsistent, the system will automatically complete the repair. When the system is in external Flash boot mode, the detection is paused and will resume after returning to the normal internal Flash boot mode.

10. The method for autonomous repair of a single-event sensitive region in a high-orbit spacecraft according to claim 5, characterized in that: It also includes long-term operation management: maintaining an erase / write count counter for each boot sector, migrating to a spare sector to achieve wear leveling when it approaches its durability; periodically checking sectors marked as permanently damaged, and adding them back to the pool of available sectors if they recover; and activating a permanent external boot mode when the spare sectors are exhausted, with the boot program loading the application from the external Flash main application area.

Images