Flash asynchronous management method and device and electronic equipment

Abstract

The invention discloses a Flash asynchronous management method and device and electronic equipment, and belongs to the technical field of embedded systems. The method comprises the steps of receiving an operation instruction and storing the operation instruction in a main task queue; acquiring an instruction from the main task queue, asynchronously executing Flash operation through a direct memory access controller, and verifying an operation result; if the operation fails, performing automatic retry within a preset number of times; if the retry still fails, a failure instruction is moved into a fault-tolerant queue to be isolated; and monitoring the fault-tolerant queue, and when the fault-tolerant queue meets a preset fusing condition, triggering a system-level fault response. According to the method, efficient asynchronous parallel processing is organically combined with three reliability guarantee mechanisms including automatic retry, failure task isolation and system fusing, the execution efficiency is improved, meanwhile, the reliability of data storage and the robustness of the system are greatly enhanced, and the problem that efficiency and reliability are difficult to consider at the same time in the prior art is effectively solved.

Description

Technical Field

[0001] This invention relates to the field of embedded systems technology, and more specifically, to a method, apparatus, and electronic device for asynchronous read / write management of non-volatile memory (Flash). Background Technology

[0002] Non-volatile memory (Flash), especially off-chip Flash based on serial peripheral interfaces, is widely used in various embedded devices, such as smart door locks and IoT terminals, due to its low cost and moderate capacity, to store key parameters, user information and operation logs.

[0003] When interacting with off-chip Flash memory, microcontrollers (MCUs) face the dual challenges of efficiency and reliability. Traditional blocking read / write methods cause the MCU to wait for extended periods while performing erase or write operations, preventing it from responding to other real-time tasks and severely limiting overall system performance. This problem is particularly pronounced in off-chip Flash applications, as they typically communicate with the MCU via relatively slow serial buses such as SPI. A single erase or write operation can take tens or even hundreds of milliseconds, and such prolonged blocking is unacceptable for systems with high real-time requirements.

[0004] To address this issue, one existing technology proposes an asynchronous operation scheme using Direct Memory Access (DMA). This scheme uses DMA to move data in the background, freeing the MCU core from time-consuming I / O waiting and enabling it to process other tasks in parallel, thus improving efficiency to some extent.

[0005] However, existing asynchronous solutions generally prioritize efficiency over reliability, especially in resource-constrained embedded environments. They merely address the problem of blocking and waiting while neglecting the deeper need for unified management of operational tasks and systematic handling of potential faults. Specifically, current technologies lack a complete reliability assurance system that organically integrates functions such as task scheduling, instantaneous fault recovery, continuous fault isolation, and system-level fault response. This is particularly true for off-chip Flash memory, whose communication link with the MCU is longer and more susceptible to external factors such as electromagnetic interference (EMI) and power supply noise, resulting in a much higher probability of intermittent read / write failures compared to highly integrated on-chip Flash memory. When an upper-layer application initiates multiple asynchronous requests in succession, the application layer needs to track and manage the state of each scattered operation, which increases the complexity of software design and the risk of errors. When the external Flash memory experiences occasional read / write failures due to electromagnetic interference or other factors, the application layer needs to perform complex exception handling and retries. If not handled properly, it can easily lead to the loss of critical data. More seriously, when the hardware experiences persistent failures, the existing solutions lack effective isolation and circuit breaker mechanisms, which may cause failed tasks to repeatedly attempt to run, blocking subsequent normal tasks, or even continuing to run when the storage function is severely damaged, leading to systemic data collapse.

[0006] Therefore, how to provide a technical solution that can not only achieve efficient asynchronous management of Flash operations, but also natively integrate a complete multi-level reliability assurance mechanism with automatic retry, fault isolation and system circuit breaking capabilities to deal with instantaneous or even continuous failures of the underlying hardware, especially in off-chip Flash application scenarios where reliability challenges are more severe, has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0007] The purpose of this invention is to provide a Flash asynchronous management method, device, and electronic device to solve the technical problems of low efficiency and lack of reliability guarantee in MCU operation of external Flash in the prior art.

[0008] This invention provides an asynchronous Flash management method applied to an electronic device comprising a microcontroller and off-chip Flash memory. The method includes: receiving at least one operation instruction for off-chip Flash memory initiated by an upper-layer application and storing the at least one operation instruction in a main task queue; retrieving the operation instruction to be executed from the main task queue and asynchronously executing the Flash operation corresponding to the operation instruction to be executed through the microcontroller's direct memory access controller; verifying the result of the asynchronously executed Flash operation to determine whether the Flash operation has failed; automatically re-executing the Flash operation within a preset number of retries when the Flash operation is determined to have failed; if the Flash operation still fails after the preset number of retries, removing the operation instruction to be executed from the main task queue and storing it in a fault-tolerant queue; and monitoring the status of the fault-tolerant queue and triggering a system-level fault response when the status of the fault-tolerant queue meets a preset circuit breaker condition.

[0009] The beneficial effects of this invention lie in the fact that by unifying the Flash operation instructions of upper-layer applications into the main task queue and automating their execution through the underlying asynchronous manager in conjunction with the direct memory access controller, the decoupling between the application layer and the underlying hardware operations is achieved. This allows the MCU to initiate multiple Flash operations without blocking or waiting, significantly improving the system's execution efficiency and concurrent processing capabilities. More importantly, this invention creatively integrates a complete and hierarchical reliability assurance mechanism seamlessly into the asynchronous management process, achieving an optimal balance between efficiency and reliability that is unattainable in existing technologies. This mechanism provides a triple-layered protection: the first layer is "task-level automatic fault tolerance," which automatically digests and recovers from transient hardware errors caused by external interference through built-in verification and automatic retry mechanisms. This process is completely transparent to upper-layer applications, ensuring a high success rate for individual tasks. The second layer is "task flow fault isolation," which isolates persistent tasks that fail after multiple retries through a dedicated fault-tolerant queue, solving the problem that a single point of failure could block the entire task flow and ensuring that even if individual tasks fail, it will not affect the execution of subsequent normal tasks. The third layer is "system-level circuit breaker protection," which triggers a system-level fault response when the fault-tolerant queue meets the circuit breaker conditions, indicating a serious and persistent hardware failure. This provides a final safety line for the system, preventing it from continuing to run even if the storage function fails severely, thus avoiding catastrophic data state collapse. It is important to emphasize that this invention differs fundamentally in its technical approach from some technical solutions in the field that use multi-priority task queues to achieve task preemption. The latter focuses on solving the scheduling and preemption problems when multiple tasks coexist; while this invention focuses on the ultimate reliability of a single task flow during execution. Through a dual-queue structure of 'main task queue + fault-tolerant queue', it cleverly achieves efficient flow of normal tasks and complete isolation of stubborn faulty tasks, supplemented by system-level circuit breaking as the final line of defense. This invention solves the core pain point of the difficulty in balancing efficiency and reliability in asynchronous operations with a simpler and more robust architecture.

[0010] Optionally, the method further includes: setting a state machine to track the busy / idle state of the external Flash; wherein, retrieving the operation instruction to be executed from the main task queue is performed when the state machine indicates that the external Flash is in an idle state.

[0011] It is evident that by introducing a state machine to manage hardware resources in a unified manner, it ensures that only one Flash operation is being executed at any given time, avoiding concurrent access conflicts and guaranteeing the orderliness and atomicity of data operations.

[0012] Optionally, associating a retry counter with the operation instruction to be executed and automatically re-executing the Flash operation includes: decrementing the count value of the retry counter by one when the Flash operation is determined to have failed; and re-executing the Flash operation when the count value of the retry counter is greater than zero.

[0013] As can be seen, by associating an independent retry counter with each task, refined and automated management of retry logic is achieved, enabling the task-level automatic fault tolerance mechanism to be implemented efficiently and transparently.

[0014] Optionally, the default circuit breaker condition is that the fault tolerance queue is full.

[0015] It is evident that by using "fault tolerance queue full" as the circuit breaker condition, a clear, objective, and easy-to-implement triggering standard is provided. It can accurately reflect that the system is facing a continuous hardware failure, thereby enabling system-level protection to be activated in a timely and reliable manner.

[0016] Optionally, system-level fault response includes generating a critical alarm and performing a system restart operation on the electronic device.

[0017] It is evident that restarting the system, as the ultimate recovery method, can restore the hardware and software to a known, clean initial state. This is the most effective protective measure to deal with serious system failures and prevent the spread of erroneous states.

[0018] Optionally, after storing the operation instruction to be executed in the fault-tolerant queue, the method further includes: sending a notification to the upper-layer application or external device indicating that the operation instruction has failed to execute.

[0019] As can be seen, by sending failure notifications to upper-layer applications or external devices, system maintenance personnel can be informed of potential hardware anomalies in a timely manner, facilitating diagnosis and maintenance.

[0020] Other features and advantages of the invention will become clear from the following detailed description of exemplary embodiments of the invention with reference to the accompanying drawings. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments of the invention and, together with their description, serve to explain the principles of the invention.

[0022] Figure 1 This is a schematic diagram of an asynchronous Flash management system architecture provided in an embodiment of the present invention.

[0023] Figure 2 This is a block diagram of the internal structure of a Flash asynchronous manager provided in an embodiment of the present invention.

[0024] Figure 3 This is a flowchart of an asynchronous Flash management method provided in an embodiment of the present invention.

[0025] Figure 4 yes Figure 3 A detailed flowchart of the asynchronous execution and error handling steps.

[0026] Explanation of reference numerals in the attached diagram: 1. Electronic device; 2. Microcontroller; 3. External Flash; 4. Upper-layer application; 5. Flash asynchronous manager; 51. Main task queue; 52. State machine; 53. DMA controller interface; 54. Fault tolerance module; 541. Retry counter; 542. Fault tolerance queue; 543. Circuit breaker monitoring unit. Detailed Implementation

[0027] Various exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of the invention.

[0028] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the invention or its application or use.

[0029] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, they should be considered part of the specification.

[0030] In all the examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

[0031] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0032] This invention provides a highly efficient and reliable asynchronous Flash management solution. Its core idea lies in constructing a management middleware layer that integrates task scheduling, asynchronous execution, automatic retries, fault isolation, and system circuit breaking. This middleware layer shields upper-layer applications from the complexity and uncertainty of underlying hardware operations, allowing upper-layer applications to simply "submit" tasks without waiting. Simultaneously, a hierarchical reliability guarantee mechanism ensures a high success rate for data operations and the robustness of the entire system in the face of hardware failures.

[0033] Please see Figure 1This invention can be integrated into an electronic device 1, such as a smart door lock or an IoT terminal. The electronic device 1 includes at least a microcontroller 2 and an external Flash memory 3. The microcontroller 2 internally runs an upper-layer application 4 and the Flash asynchronous manager 5 proposed in this invention. The upper-layer application 4 is responsible for handling the device's business logic. When it needs to interact with the external Flash memory 3, it generates operation instructions and sends them to the Flash asynchronous manager 5, without needing to concern itself with the specific timing and state of the underlying hardware. The Flash asynchronous manager 5, as the core management layer, is fully responsible for scheduling and executing all operation requests to the external Flash memory 3.

[0034] Please refer to the following: Figure 2 The internal structure of the Flash asynchronous manager 5 may include: a main task queue 51, a state machine 52, a DMA controller interface 53, and a fault-tolerant processing module 54. The main task queue 51 receives and buffers operation instructions from the upper-layer application 4 in a first-in, first-out (FIFO) manner. Each operation instruction is a predefined data structure (struct) containing all the information required to execute the task, such as: instruction type enumeration (e.g., WRITE or ERASE), target Flash physical address, length of the data to be read or written, and a pointer to the source address of the data to be written in the microcontroller's memory. The state machine 52 manages and tracks the current operating state of the off-chip Flash 3, including at least two states: "idle" and "busy." This is crucial in a multi-tasking environment, effectively avoiding data conflicts or state errors that may result from concurrent hardware access by ensuring that only one Flash operation is being executed at any given time. The DMA controller interface 53 is a software interface for interaction between the Flash asynchronous manager 5 and the direct memory access hardware controller inside the microcontroller 2. It is used to configure the source address, destination address, transfer length, and other related registers of the DMA channel according to the parameters of the current instruction, and to start or stop data transmission. The fault tolerance module 54 is the core of the reliability assurance of this invention. It integrates a triple protection mechanism, and its specific components may include: a retry counter 541, a fault tolerance queue 542, and a circuit breaker monitoring unit 543.

[0035] The following is combined Figure 3 and Figure 4 The flowchart below provides a detailed explanation of the specific implementation process of the Flash asynchronous management method proposed in this invention.

[0036] Step S301: The Flash asynchronous manager 5 receives the operation instruction initiated by the upper-layer application 4 and stores the instruction as a task unit in the main task queue 51. This step achieves timing decoupling between the application layer and the hardware operation layer, allowing the application layer to return immediately after submitting a task without blocking or waiting.

[0037] Step S302: In its main loop (or a periodic task triggered by a timer), the Flash asynchronous manager 5 polls and checks the state machine 52 to determine whether the current state of the off-chip Flash 3 is "idle".

[0038] Step S303: If it is determined that the external Flash3 is in the "idle" state and the main task queue 51 is not empty, then take an operation instruction to be executed from the head of the main task queue 51 and immediately update the state of the state machine 52 to "busy" to prevent other tasks from preempting hardware resources during this period.

[0039] Step S304: Flash asynchronous manager 5 begins asynchronously executing the retrieved operation instructions, integrating error handling during this process. For detailed instructions, please refer to [link / reference needed]. Figure 4Step S401: Initialize the retry counter 541 corresponding to the currently pending operation instruction. For example, a counter variable associated with the instruction can be set to a preset number of retries, such as 3 times. Step S402: Configure and start direct memory access through the DMA controller interface 53 to begin executing the Flash operation (write or erase). Step S403: After the direct memory access transfer is completed, a completion interrupt will be generated, or the main loop will poll the DMA status flag. In the interrupt service routine or the main loop, the Flash asynchronous manager 5 verifies the execution result of this Flash operation. For example, for a write operation, the written area can be read back and compared byte by byte with the source data in memory for verification; for an erase operation, the erased area can be read to confirm whether it is all 0xFF. In addition, the Flash chip's own status register can be read to check for the presence of error flags. Step S404: Determine whether the Flash operation is successful based on the verification result. If successful, the process jumps to step S410. If it fails, proceed to step S405. Step S405: If the operation fails, decrement the count of the retry counter 541 corresponding to the operation instruction by 1. Step S406: Check if the value of the retry counter 541 is greater than zero. If it is greater than zero, it indicates that the retry opportunities have not been exhausted, and the process will return to step S402, automatically re-executing the Flash operation to overcome momentary interference. Step S407: If the value of the retry counter 541 is equal to zero, it means that the operation still failed after reaching the preset number of retries, indicating a possible persistent hardware problem. Step S408: Store this failed operation instruction as a fault record in a dedicated fault-tolerant queue 542. This isolation step ensures the system's "liveliness," preventing a single persistent fault from blocking the entire task flow, thus guaranteeing the execution of subsequent normal tasks. Step S409: The fault-tolerant processing module 54 can send an exception notification to the upper-layer application 4 or to an external host computer via a communication interface (such as UART). The notification content may include information such as the type of failed instruction and the target address, facilitating subsequent debugging and diagnosis. The process then proceeds to step S410. Step S410: The current operation instruction's process (whether successful or ultimately failed and isolated) has been completed. The Flash asynchronous manager 5 resets the state of state machine 52 to "idle". If the instruction was successfully completed, it is officially removed from the main task queue to free up queue space. Afterward, the entire management process returns to step S302, ready to process the next instruction.

[0040] Step S305: In parallel with the main process described above, the circuit breaker monitoring unit 543 in the fault tolerance processing module 54 continuously monitors the status of the fault tolerance queue 542 at a low frequency.

[0041] Step S306: The fuse monitoring unit 543 determines whether the state of the fault-tolerant queue 542 meets the preset fuse-breaking condition. In a preferred embodiment, the fuse-breaking condition is whether the fault-tolerant queue 542 is full. The event of the fault-tolerant queue being full is a strong signal that the rate of system failure in the short term far exceeds its self-recovery capability, which most likely means that there is a serious and persistent hardware failure in the off-chip Flash or its interface circuit.

[0042] Step S307: If the circuit breaker condition is met, the circuit breaker monitoring unit 543 triggers a system-level fault response. In one specific implementation, this response includes: first, logging critical alarm information through the logging system; and then performing a system restart (watchdog reset or soft reboot). This is an ultimate "fail-safe" measure designed to prevent further data corruption or system crashes caused by continued operation in the event of a severe storage failure by restoring the entire hardware and software system to a defined initial state.

[0043] The apparatus in this embodiment of the invention is configured to implement the foregoing method embodiments, and its functional implementation process is described in the foregoing method embodiments. The Flash asynchronous manager can be implemented as a software module in a microcontroller or as a separate hardware IP core.

[0044] An embodiment of the present invention also provides a Flash asynchronous management device, the structure of which is as follows: Figure 2 As shown. This Flash asynchronous management device can implement the steps described in any of the foregoing method embodiments. Specifically, the device may include: Instruction receiving module: used to receive at least one operation instruction for the external Flash 3 initiated by the upper layer application 4, and store the at least one operation instruction in the main task queue 51.

[0045] Asynchronous execution module: This module retrieves operation instructions to be executed from the main task queue 51 and asynchronously executes the Flash operation corresponding to the operation instruction through the direct memory access (DMA) controller of the microcontroller 2. This module can be specifically implemented through the DMA controller interface 53.

[0046] Fault tolerance module 54: Used to verify the result of asynchronous Flash operation to determine whether the Flash operation has failed; when the Flash operation is determined to have failed, the asynchronous execution module is controlled to automatically re-execute the Flash operation within a preset number of retries (for example, managed by retry counter 541); if it still fails after re-execution, the operation instruction to be executed is removed from the main task queue and stored in the fault tolerance queue 542.

[0047] Circuit breaker monitoring module: This module monitors the status of the fault-tolerant queue 542 and triggers a system-level fault response when the status of the fault-tolerant queue meets the preset circuit breaker conditions (e.g., the fault-tolerant queue 542 is full). This module can be specifically implemented by the circuit breaker monitoring unit 543 in the fault-tolerant processing module 54.

[0048] In an optional embodiment, the device may further include a state machine 52 for tracking the busy / idle state of the off-chip Flash 3 to ensure that the asynchronous execution module only acquires and executes new instructions when the Flash is idle, thus avoiding access conflicts.

[0049] In another optional embodiment, after storing the failed instruction in the fault tolerance queue 542, the fault tolerance processing module 54 is also configured to send a notification to the upper-layer application or external device indicating that the operation instruction has failed, so as to facilitate system diagnosis and maintenance.

[0050] It should be noted that the above modules can be logical functional units implemented through software programming and running on the microcontroller 2; or they can be hardware circuits embedded in the chip, such as an independent hardware IP core.

[0051] An embodiment of the present invention also provides an electronic device 1, the system architecture of which is as follows: Figure 1 As shown. The electronic device 1 includes: Off-chip Flash3: A non-volatile memory used to store data.

[0052] Microcontroller 2: Serves as the main control unit of the device.

[0053] And the Flash asynchronous management device as described in the aforementioned device embodiments.

[0054] In this electronic device 1, the microcontroller 2 internally runs an upper-layer application 4 and a Flash asynchronous management device. The upper-layer application 4 is responsible for business logic. When it needs to read or write external Flash 3, it generates operation instructions and sends them to the Flash asynchronous management device. The Flash asynchronous management device is responsible for efficiently and reliably completing all underlying Flash operations and feeding back the execution results (or notifications in case of eventual failure) to the upper-layer application 4. This electronic device 1 can be any embedded device that requires highly reliable data storage, such as a smart door lock, an Internet of Things (IoT) terminal, an industrial controller, or an automotive electronic unit (ECU).

[0055] In summary, this invention, through an innovative asynchronous management mechanism that integrates three levels of reliability assurance—task-level automatic retry, task flow fault isolation, and system-level circuit breaker protection—significantly improves the reliability of Flash data storage and the overall robustness of the system without sacrificing system efficiency. It provides a high-performance and highly robust Flash management solution for resource-constrained embedded devices, particularly in scenarios with stringent requirements for data storage reliability, such as smart locks, industrial controllers, automotive electronic units (ECUs), and smart meters, demonstrating significant practical value.

[0056] While specific embodiments of the invention have been described in detail by way of examples, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of the invention. Those skilled in the art should understand that modifications can be made to the above embodiments without departing from the scope and spirit of the invention. The scope of the invention is defined by the appended claims.

Claims

1. A Flash asynchronous management method, characterized in that, Applied to electronic devices comprising a microcontroller and off-chip Flash memory, the method includes: Receive at least one operation instruction for off-chip Flash initiated by upper-layer application, and store the at least one operation instruction in the main task queue; The system retrieves the operation instructions to be executed from the main task queue and asynchronously executes the Flash operation corresponding to the operation instruction through the microcontroller's direct memory access controller. The results of asynchronous Flash operations are verified to determine whether the Flash operation has failed. If the Flash operation is determined to have failed, it will be automatically retried within a preset number of retries. If the Flash operation still fails after the preset number of retries, the operation instruction to be executed is removed from the main task queue and stored in the fault tolerance queue. Additionally, monitor the status of the fault-tolerant queue and trigger a system-level fault response when the status of the fault-tolerant queue meets the preset circuit breaker conditions.

2. The method according to claim 1, characterized in that, The method also includes: A state machine is set up to track the busy / idle status of the external Flash memory; The process of retrieving the operation instructions to be executed from the main task queue is performed when the state machine indicates that the off-chip Flash is in an idle state.

3. The method according to claim 1, characterized in that, Associating a retry counter with the pending operation instruction to automatically re-execute the Flash operation includes: When the Flash operation is determined to have failed, the retry counter is decremented by one. Additionally, if the retry counter value is greater than zero, the Flash operation will be re-executed.

4. The method according to claim 1, characterized in that, The default circuit breaker condition is that the fault tolerance queue is full.

5. The method according to claim 1, characterized in that, System-level fault response includes generating a critical alarm and performing a system restart operation on electronic devices.

6. The method according to claim 1, characterized in that, After storing the operation instructions to be executed in the fault-tolerant queue, the following is also included: Send a notification to the upper-layer application or external device indicating that the operation command failed to execute.

7. The method according to claim 1, characterized in that, The verification of the results of asynchronous Flash operations includes: for write operations, reading back the written area and comparing it with the source data; or for erase operations, reading back the erased area to confirm its data status.

8. A Flash asynchronous management device, characterized in that, The device, intended for use in electronic devices comprising a microcontroller and off-chip Flash memory, includes: The instruction receiving module is used to receive at least one operation instruction for the off-chip Flash initiated by the upper layer application and store the at least one operation instruction in the main task queue. The asynchronous execution module is used to retrieve the operation instructions to be executed from the main task queue and asynchronously execute the Flash operation corresponding to the operation instructions through the microcontroller's direct memory access controller. The fault tolerance module is configured as follows: The results of asynchronous Flash operations are verified to determine whether the Flash operation has failed. When the Flash operation is determined to have failed, the asynchronous execution module will automatically re-execute the Flash operation within a preset number of retries. If the Flash operation still fails after the preset number of retries, the operation instruction to be executed is removed from the main task queue and stored in the fault tolerance queue. as well as, The circuit breaker monitoring module is used to monitor the status of the fault-tolerant queue and trigger a system-level fault response when the status of the fault-tolerant queue meets the preset circuit breaker conditions.

9. The apparatus according to claim 8, characterized in that, The device also includes a state machine for tracking the busy / idle state of the off-chip Flash; wherein, the asynchronous execution module is configured to retrieve operation instructions to be executed from the main task queue when the state machine indicates that the off-chip Flash is in an idle state.

10. The apparatus according to claim 8, characterized in that, The fault tolerance module is also configured to associate a retry counter with the operation instruction to be executed, and to decrement the count value of the retry counter by one when the Flash operation is determined to have failed, so as to control the asynchronous execution module to re-execute the Flash operation when the count value of the retry counter is greater than zero.

11. The apparatus according to claim 8, characterized in that, The default circuit breaker condition is that the fault tolerance queue is full.

12. The apparatus according to claim 8, characterized in that, System-level fault response includes generating a critical alarm and performing a system restart operation on electronic devices.

13. The apparatus according to claim 8, characterized in that, The fault tolerance module is also configured to send a notification to the upper-layer application or external device indicating that the operation instruction has failed to be executed after storing the operation instruction to be executed in the fault tolerance queue.

14. An electronic device, characterized in that, include: A microcontroller, off-chip Flash memory, and a Flash asynchronous management device as described in any one of claims 8 to 13.

Images