Flash control method and apparatus

CN122963465APending Publication Date: 2026-10-23AUTOCHIPS
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611265145.3
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-08-19
Publication Date
2026-10-23

AI Technical Summary

Technical Problem

[0005]本申请实施例提供Flash控制方法以及装置,用以解决Flash操作的存储可靠性较低的技术问题

Benefits of technology

[0079]本申请实施例提供的Flash控制方法以及装置,通过将LVD中断响应与Flash操作命令执行在时序上解耦,LVD中断回调函数仅在中断上下文中对低电压事件标志变量进行置位,不执行任何Flash相关控制操作,消除了中断上下文重入Flash操作的风险。在发起Flash操作命令之前,通过清除LVD中断挂起状态并读取中断控制器中LVD中断的当前活跃状态,获取中断控制器的硬件状态进行二次确认,而非依赖软件标志变量进行判断,从而有效避免了已处理完毕的历史LVD事件对当前Flash操作命令的干扰,显著提升了LVD事件响应的确定性和Flash操作命令的存储可靠性。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122963465A_ABST
    Figure CN122963465A_ABST
Patent Text Reader

Abstract

The embodiment of the present application provides a Flash control method and device. The method comprises the following steps: before initiating a Flash operation command, detecting the state of a low voltage event flag variable, if the low voltage event flag variable is set, clearing the LVD interrupt pending state, and reading the current active state of the LVD interrupt in the interrupt controller. If the current active state of the LVD interrupt indicates that there is no LVD event at present, the Flash operation command is executed; if the current active state of the LVD interrupt indicates that there is an LVD event at present, the execution of the Flash operation command is terminated. Wherein, the low voltage event flag variable is a volatile variable, and is set by an LVD interrupt callback function when the LVD interrupt is generated; the LVD interrupt callback function runs in an interrupt context, and no Flash related control operation is executed in the LVD interrupt callback function, so that the storage reliability of the Flash operation is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of memory chip technology, and in particular to a Flash control method and apparatus. Background Technology

[0002] In high-reliability applications such as automotive electronics and industrial control, the data integrity and operational reliability of Flash memory are directly related to the functional safety and operational stability of the system.

[0003] Currently, Flash programming (writing) operations require the chip's power supply voltage to be maintained within its rated operating range. If a voltage drop (Low Voltage Detection, LVD) occurs during the programming operation, the charging and discharging process of the Flash memory cell will be forced to interrupt, resulting in the memory cell being in an uncertain "half-written" state. Therefore, a common approach in existing technology is to disable system interrupts before the Flash write operation and re-enable interrupts after the write operation is completed, thereby avoiding interruption by interrupt service routines during the write operation.

[0004] However, existing technologies suffer from low determinism in responding to low-voltage events, leading to lower storage reliability in Flash operations. Summary of the Invention

[0005] This application provides a Flash control method and apparatus to solve the technical problem of low storage reliability in Flash operations.

[0006] In a first aspect, embodiments of this application provide a Flash control method, including:

[0007] Before initiating a Flash operation command, the state of a low-voltage event flag variable is checked; wherein, the low-voltage event flag variable is a volatile variable, which is set by the LVD interrupt callback function when an LVD interrupt occurs; the LVD interrupt callback function runs in an interrupt context, and no Flash-related control operations are performed within the LVD interrupt callback function;

[0008] If the low voltage event flag variable is set, the LVD interrupt pending state is cleared.

[0009] Read the current active status of LVD interrupts in the interrupt controller;

[0010] If the current active state of the LVD interrupt indicates that there is currently no LVD event, then the Flash operation command is executed;

[0011] If the current active state of the LVD interrupt indicates that an LVD event is currently present, then the execution of the Flash operation command will be terminated.

[0012] In one possible implementation, the method further includes:

[0013] After the LVD interrupt is generated, the LVD interrupt is disabled through the power management module;

[0014] If the current active state of the LVD interrupt indicates that there is currently no LVD event, then the LVD interrupt is re-enabled through the power management module.

[0015] In one possible implementation, the current active state of the LVD interrupt in the read interrupt controller includes:

[0016] Execute at least two no-operation instructions;

[0017] Read the bit corresponding to the LVD interrupt in the interrupt activity status register of the interrupt controller to obtain the current activity status of the LVD interrupt.

[0018] In one possible implementation, the method further includes:

[0019] When the Flash operation command needs to be triggered, if the compilation toolchain does not support the keyword of directly linking the function to the static RAM buffer for execution, then it checks whether the function pointer is a null pointer; wherein, the function pointer matches the signature of the target function, and the target function is the function that needs to be stored in the static RAM buffer for executing the Flash operation command;

[0020] If the function pointer is a null pointer, then obtain the actual starting address of the machine code of the target function;

[0021] Using the actual starting address of the machine code of the target function as the source address and the first address of the static RAM buffer as the target address, the machine code byte sequence of the target function is copied into the static RAM buffer;

[0022] Construct the function pointer corresponding to the target function;

[0023] The target function in the static RAM buffer is called through the function pointer to execute the Flash operation command by fetching instructions from RAM.

[0024] In one possible implementation, obtaining the actual starting address of the machine code of the target function includes:

[0025] Perform a bitwise AND operation on the compile-time address of the target function, clear the least significant bit of the compile-time address of the target function, and obtain the actual starting address of the machine code of the target function;

[0026] Accordingly, constructing the function pointer corresponding to the target function includes:

[0027] Perform a bitwise OR operation on the starting address of the static RAM buffer, and set the least significant bit of the starting address of the static RAM buffer to generate the processed address;

[0028] The processed address is type-converted and then assigned to the function pointer.

[0029] In one possible implementation, under critical section protection, it is detected whether the function pointer is a null pointer, and when the function pointer is a null pointer, under critical section protection, the following steps are executed sequentially: obtaining the actual starting address of the machine code of the target function, copying the machine code byte sequence of the target function into the static RAM buffer, and constructing the function pointer corresponding to the target function.

[0030] Accordingly, after constructing the function pointer corresponding to the target function, the method further includes:

[0031] Exit the critical region.

[0032] In one possible implementation, the method further includes:

[0033] If a timeout is detected during the execution of the Flash operation command, the current command byte value in the Flash command register is read.

[0034] Based on the current command byte value, determine whether the Flash operation command is an erase command;

[0035] If the Flash operation command is an erase command, then the page erase abort operation is performed;

[0036] If the Flash operation command is not an erase command, the page erase abort operation will not be performed.

[0037] In one possible implementation, the page erase abort operation includes:

[0038] Write a set value to the page erase abort control bit in the Flash configuration register to execute the page erase abort request;

[0039] Poll the command completion status flag in the Flash status register until the command completion status flag indicates that the processing flow of the Flash operation command has ended;

[0040] Write a zero value to the page erase abort control bit in the Flash configuration register to clear the page erase abort request.

[0041] Secondly, embodiments of this application provide a Flash control device, comprising:

[0042] The detection module is used to detect the state of the low voltage event flag variable before initiating the Flash operation command; wherein, the low voltage event flag variable is a volatile variable, which is set by the LVD interrupt callback function when an LVD interrupt occurs; the LVD interrupt callback function runs in the interrupt context, and no Flash-related control operations are performed within the LVD interrupt callback function;

[0043] The clearing module is used to clear the LVD interrupt pending state if the low voltage event flag variable is set.

[0044] The read module is used to read the current active status of LVD interrupts in the interrupt controller;

[0045] The execution module is used to execute the Flash operation command if the current active state of the LVD interrupt indicates that there is currently no LVD event;

[0046] The execution module is further configured to terminate the execution of the Flash operation command if the current active state of the LVD interrupt indicates that an LVD event currently exists.

[0047] In one possible implementation, the Flash control device further includes a control module for:

[0048] After the LVD interrupt is generated, the LVD interrupt is disabled through the power management module;

[0049] If the current active state of the LVD interrupt indicates that there is currently no LVD event, then the LVD interrupt is re-enabled through the power management module.

[0050] In one possible implementation, the reading module is specifically used for:

[0051] Execute at least two no-operation instructions;

[0052] Read the bit corresponding to the LVD interrupt in the interrupt activity status register of the interrupt controller to obtain the current activity status of the LVD interrupt.

[0053] In one possible implementation, the Flash control device further includes:

[0054] The detection module is further configured to detect whether the function pointer is null if the compilation toolchain does not support the keyword of directly linking the function to the static RAM buffer for execution when the Flash operation command needs to be triggered; wherein the function pointer matches the signature of the target function, and the target function is the function that needs to be stored in the static RAM buffer for executing the Flash operation command;

[0055] The acquisition module is used to acquire the actual starting address of the machine code of the target function if the function pointer is a null pointer;

[0056] The copying module is used to copy the machine code byte sequence of the target function into the static RAM buffer, using the actual starting address of the machine code of the target function as the source address and the starting address of the static RAM buffer as the destination address.

[0057] The construction module is used to construct the function pointer corresponding to the target function;

[0058] The target function in the static RAM buffer is called through the function pointer to execute the Flash operation command by fetching instructions from RAM.

[0059] In one possible implementation, the acquisition module is specifically used for:

[0060] Perform a bitwise AND operation on the compile-time address of the target function, clear the least significant bit of the compile-time address of the target function, and obtain the actual starting address of the machine code of the target function;

[0061] Accordingly, the building module is specifically used for:

[0062] Perform a bitwise OR operation on the starting address of the static RAM buffer, and set the least significant bit of the starting address of the static RAM buffer to generate the processed address;

[0063] The processed address is type-converted and then assigned to the function pointer.

[0064] In one possible implementation, under critical section protection, it is detected whether the function pointer is a null pointer, and when the function pointer is a null pointer, under critical section protection, the following steps are executed sequentially: obtaining the actual starting address of the machine code of the target function, copying the machine code byte sequence of the target function into the static RAM buffer, and constructing the function pointer corresponding to the target function.

[0065] Accordingly, after constructing the function pointer corresponding to the target function, the control module is also used to exit the critical section.

[0066] In one possible implementation, the reading module is further configured to, during the execution of the Flash operation command, if a timeout is detected in the Flash operation command execution, read the current command byte value in the Flash command register;

[0067] The processing module is further configured to determine whether the Flash operation command is an erase command based on the current command byte value;

[0068] The execution module is further configured to perform a page erase abort operation if the Flash operation command is an erase command;

[0069] The execution module is further configured to not perform the page erase abort operation if the Flash operation command is not an erase command.

[0070] In one possible implementation, the execution module is specifically used for:

[0071] Write a set value to the page erase abort control bit in the Flash configuration register to execute the page erase abort request;

[0072] Poll the command completion status flag in the Flash status register until the command completion status flag indicates that the processing flow of the Flash operation command has ended;

[0073] Write a zero value to the page erase abort control bit in the Flash configuration register to clear the page erase abort request.

[0074] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0075] The memory stores computer-executed instructions;

[0076] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0077] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0078] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0079] The Flash control method and apparatus provided in this application decouple the LVD interrupt response from the execution of Flash operation commands in terms of timing. The LVD interrupt callback function only sets the low-voltage event flag variable in the interrupt context and does not perform any Flash-related control operations, thus eliminating the risk of re-entering the Flash operation from the interrupt context. Before initiating a Flash operation command, the hardware status of the interrupt controller is obtained by clearing the LVD interrupt pending state and reading the current active state of the LVD interrupt in the interrupt controller for secondary confirmation, rather than relying on software flag variables for judgment. This effectively avoids interference from processed historical LVD events on the current Flash operation command, significantly improving the determinism of LVD event response and the storage reliability of Flash operation commands. Attached Figure Description

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

[0081] Figure 1 Flowchart of the Flash control method provided in this application Figure 1 ;

[0082] Figure 2 Flowchart of the Flash control method provided in this application Figure 2 ;

[0083] Figure 3 Flowchart of the Flash control method provided in this application Figure 3 ;

[0084] Figure 4 Flowchart of the Flash control method provided in this application Figure 4 ;

[0085] Figure 5 Flowchart of the Flash control method provided in this application Figure 5 ;

[0086] Figure 6 Flowchart of the Flash control method provided in this application Figure 6 ;

[0087] Figure 7 Flowchart of the Flash control method provided in this application Figure 7 ;

[0088] Figure 8 Flowchart of the Flash control method provided in this application Figure 8 ;

[0089] Figure 9 Flowchart of the Flash control method provided in this application Figure 9 ;

[0090] Figure 10 This is a schematic diagram of the structure of the Flash control device provided in this application;

[0091] Figure 11 A schematic diagram of the structure of the electronic device provided in this application.

[0092] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0093] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0094] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0095] First, the application scenarios involved in this application will be explained:

[0096] On-chip Flash memory is the core medium in embedded microcontroller units (MCUs) used to store program code and persistent data. In high-reliability applications such as automotive electronics and industrial control, the data integrity and operational reliability of Flash memory are directly related to the functional safety and operational stability of the system.

[0097] Flash programming (writing) operations require the chip's power supply voltage to be maintained within its rated operating range. If LVD (Low-Level Discharge) occurs during programming, the charging and discharging process of the Flash memory cell will be forced to stop, resulting in the memory cell being in an uncertain "half-written" state. In this state, a mismatch will occur between the actual data written and the corresponding Error Correction Code (ECC). When subsequently reading the address of the Flash memory cell, the ECC engine will detect an uncorrectable error, which may result in either returning incorrect data or triggering a hardware malfunction or even causing a system crash. Once a half-written state is formed, it cannot be easily repaired by software; an erasure operation must be performed on the entire memory area to restore it to a usable state. The time and cost of erasure operations are far greater than those of ordinary programming operations.

[0098] To address the aforementioned issues, a common approach in existing technologies is to disable system interrupts before a Flash write operation is performed and then re-enable interrupts after the write operation is completed, thereby preventing interruptions during the write operation.

[0099] However, this method has the following technical problems:

[0100] 1. It can only prevent context switching caused by interrupt service routines, and cannot cope with sudden power voltage drops at the hardware level during write operations. LVD events are triggered by hardware, and their response is not controlled by interrupt mask registers; once a voltage drop occurs within a write operation window where interrupts are disabled, the system can neither be notified of the LVD event in time nor take any protective measures for the ongoing programming operation.

[0101] 2. Under the ISO 26262 functional safety standard framework, which is widely followed in the automotive electronics field, safety-related storage operations must have a clear Fault Response Time (FRT) guarantee. Existing interrupt disabling mechanisms lack a deterministic design for the complete timing chain from the occurrence of an LVD event to its detection and response by the system. This makes it difficult to provide quantifiable and verifiable timing evidence and fails to meet the deterministic fault response requirements of the Automotive Safety Integrity Level (ASIL).

[0102] In summary, existing technologies suffer from low determinism in responding to low-voltage events, leading to low storage reliability in Flash operations.

[0103] Based on the aforementioned technical problems, the technical concept of this application is as follows: During the research of Flash control, the inventors discovered that the existing interrupt disabling mechanism suffers from a problem of strongly coupling event perception with operation execution, leading to uncontrollable LVD response timing. To address this, the inventors considered separating the recording of LVD events from the safety decisions of Flash operations in terms of timing. The LVD interrupt callback function is only responsible for setting the low-voltage event flag variable, without performing any Flash-related control operations. The actual LVD state check and Flash operation decision are postponed until before the Flash operation command is initiated. At the safety checkpoint before command initiation, if the low-voltage event flag variable is set, the real-time state of the LVD event is obtained by clearing the LVD interrupt pending state and reading the current active state of the LVD interrupt in the interrupt controller—a hardware-level state confirmation sequence. Based on this, the inventors decide whether to continue or terminate the Flash operation command. In this way, interrupt response and command execution are decoupled. By using the interrupt controller hardware state for secondary confirmation, the determinism of LVD event response is improved, thereby enhancing the storage reliability of Flash operations.

[0104] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0105] Figure 1 Flowchart of the Flash control method provided in this application Figure 1 ,like Figure 1 As shown, the method includes:

[0106] S11. Before initiating a Flash operation command, check the status of the low voltage event flag variable.

[0107] The execution subject of this application embodiment is an electronic device, which can be a terminal device, such as a laptop, desktop computer, or tablet computer, or a server. In practical applications, whether the electronic device is a terminal device or a server can be determined according to the actual situation, and no specific limitation is imposed on it.

[0108] For example, Flash operation commands can be programming commands, erasing commands, or reading commands, and can also be other types of Flash operation commands; there are no specific limitations on this. Specifically, a programming command is a command to write data to a Flash storage unit; an erasing command is a command to clear the data from a Flash storage unit; and a reading command is a command to read data from a Flash storage unit.

[0109] The low-voltage event flag variable is a software flag used to record whether a low-voltage event has occurred. This low-voltage event flag variable is volatile; a volatile variable is one whose value may be modified asynchronously outside the normal program execution flow (e.g., by an interrupt service routine or hardware module). For volatile variables, the compiler does not optimize access; each read directly retrieves the latest value from memory to ensure data real-time performance and accuracy.

[0110] Furthermore, the low voltage event flag variable is set by the LVD interrupt callback function when an LVD interrupt occurs.

[0111] Specifically, an LVD interrupt is a hardware interrupt signal sent to the processor by the chip's internal power management module when it detects that the power supply voltage is lower than a preset threshold. For example, when the chip's supply voltage drops from the normal 3.3 volts to below 2.7 volts, the power management module will trigger an LVD interrupt to notify the processor that there is a power abnormality.

[0112] An LVD interrupt callback function is a function that is triggered by an LVD interrupt. This LVD interrupt callback function runs in an interrupt context and does not perform Flash-related control operations within it.

[0113] Specifically, interrupt context refers to the runtime environment of the processor during the execution of the interrupt service routine after responding to an interrupt. In interrupt context, the currently executing normal program flow is suspended, and the processor switches to executing instructions in the interrupt service routine. Flash-related control operations refer to operations that configure or issue commands to the Flash controller, such as writing commands to the Flash command register, writing control bits to the Flash configuration register, and querying flag bits in the Flash status register.

[0114] In practical applications, when invoking the Flash operation command initiation function, the value of the low-voltage event flag variable is read at the entry point of the function, and it is determined whether it is equal to the preset set value. For example, if the preset value of the low-voltage event flag variable is 1, then before initiating the Flash operation command, it is determined whether the variable is equal to 1; if it is equal to 1, it means that an LVD event has occurred, and the subsequent LVD status review process needs to be entered; if it is not equal to 1, it means that no LVD event has occurred, and the Flash operation command can be executed directly.

[0115] S12. If the low voltage event flag variable is set, then clear the LVD interrupt pending state.

[0116] When an LVD interrupt occurs, the interrupt controller sets the corresponding pending bit, indicating that the interrupt is waiting for a processor response. In other words, the LVD interrupt pending state refers to the hardware state in the interrupt controller that indicates an LVD interrupt request has been triggered but not yet responded to by the processor. Clearing the LVD interrupt pending state aims to eliminate interference from historical interrupt requests in subsequent processing, ensuring that the current active state of the LVD interrupt read later reflects the actual voltage situation at the current moment, rather than a historical event that has already been processed.

[0117] S13. Read the current active status of LVD interrupts in the interrupt controller.

[0118] The current active status of an LVD interrupt refers to the hardware status in the interrupt controller used to indicate whether an LVD interrupt is currently being processed by the processor.

[0119] It's important to understand that the suspended state of an LVD interrupt indicates that the interrupt has been triggered but not yet responded to, while the current active state indicates that the interrupt has been responded to and is in progress. When the LVD interrupt callback function is executing, the current active state of the LVD interrupt is set; after the LVD interrupt callback function has finished executing, the current active state of the LVD interrupt is not set. Therefore, by reading the current active state of the LVD interrupt, it is possible to determine whether an LVD event still exists at the current moment. This method does not rely on the low-voltage event flag variable but directly obtains the hardware state of the interrupt controller, resulting in higher real-time performance and reliability.

[0120] After clearing the suspended state, if the LVD interrupt request signal is still valid (i.e., the voltage is still below the threshold), the interrupt will be retried and enter the active state; if the voltage has recovered, the interrupt request will disappear and will not re-enter the active state.

[0121] In one possible implementation, at least two no-operation instructions can be executed, followed by reading the bit corresponding to the LVD interrupt in the interrupt activity status register of the interrupt controller to obtain the current active status of the LVD interrupt.

[0122] Among them, no-operation instructions are instructions that do not produce any actual calculation results and only occupy the processor's execution cycle. By inserting at least two no-operation instructions, it can be ensured that the instructions in the processor pipeline are completed, and that the subsequent operation of reading the interrupt active status register obtains a stable state value after full synchronization.

[0123] Specifically, if the value of the bit corresponding to the LVD interrupt in the interrupt activity status register of the interrupt controller is 1, it means that the current active status of the LVD interrupt indicates that an LVD event exists; if the value of the bit is 0, it means that the current active status of the LVD interrupt indicates that no LVD event exists.

[0124] In this approach, by executing at least two no-operation instructions before reading the bit corresponding to the LVD interrupt from the interrupt controller's interrupt active status register, the no-operation instructions ensure that write operations in the processor pipeline are fully committed to the register file. This prevents out-of-order pipeline operations from reading stale status values ​​before clearing, thus avoiding incorrect LVD status determinations. This implementation effectively guarantees that the current active status of the LVD interrupt obtained from the interrupt active status register is a stable value after sufficient synchronization, further improving the accuracy of LVD status review results and the reliability of security checks before Flash operation commands are initiated.

[0125] S14. If the current active state of the LVD interrupt indicates that there is no LVD event at present, then execute the Flash operation command.

[0126] If the current active state of the LVD interrupt indicates that there are currently no LVD events, it means that the power supply voltage has returned to the normal range, and the Flash controller can safely execute programming or erasing commands. At this time, the processor sends commands to the Flash controller and waits for the commands to complete, following the normal Flash operation command execution flow.

[0127] S15. If the current active state of the LVD interrupt indicates that an LVD event is currently present, then the execution of the Flash operation command will be terminated.

[0128] If the current active status of the LVD interrupt indicates that an LVD event is currently present, then the LVD interrupt is still active. In other words, if the current power supply voltage is still below the preset threshold, continuing to execute the Flash operation command would risk data corruption. In this case, the processor will not execute the Flash operation command but will terminate the execution flow of the current Flash operation command and may return an exception status code to the upper-level application that called the Flash operation command, notifying the upper-level application that the operation failed due to an abnormal voltage.

[0129] The Flash control method provided in this application detects the state of a low-voltage event flag variable before initiating a Flash operation command. If the low-voltage event flag variable is set, the LVD interrupt pending state is cleared, and the current active state of the LVD interrupt in the interrupt controller is read. If the current active state of the LVD interrupt indicates that no LVD event exists, the Flash operation command is executed; otherwise, the execution of the Flash operation command is terminated. The low-voltage event flag variable is a volatile variable, set by the LVD interrupt callback function when an LVD interrupt occurs. The LVD interrupt callback function runs in the interrupt context and does not perform any Flash-related control operations. In this technical solution, by decoupling the LVD interrupt response from the Flash operation command execution in timing, the LVD interrupt callback function only sets the low-voltage event flag variable in the interrupt context and does not perform any Flash-related control operations, eliminating the risk of re-entering the Flash operation from the interrupt context. Before initiating a Flash operation command, the hardware status of the interrupt controller is obtained by clearing the LVD interrupt pending state and reading the current active state of the LVD interrupt in the interrupt controller for secondary confirmation, instead of relying on software flag variables for judgment. This effectively avoids interference from processed historical LVD events on the current Flash operation command, significantly improving the determinism of LVD event response and the storage reliability of Flash operation commands.

[0130] Optionally, after an LVD interrupt occurs, the LVD interrupt can be disabled via the power management module. If the current active state of the LVD interrupt indicates that there is currently no LVD event, the LVD interrupt can be re-enabled via the power management module.

[0131] The power management module refers to the internal hardware module of the chip responsible for power monitoring and management. This power management module has the function of enabling and disabling LVD interrupts. After an LVD interrupt occurs, the power management module automatically or by being triggered by the LVD interrupt callback function to disable the LVD interrupt. The purpose is to prevent the LVD interrupt from being repeatedly triggered during the LVD status review of the current Flash operation command, thereby avoiding the low voltage event flag variable being repeatedly set, which would prevent the Flash operation command from being initiated normally.

[0132] If the current active state of the LVD interrupt indicates that there is currently no LVD event, it means that the power supply voltage has returned to the normal range. In this case, the LVD interrupt is re-enabled through the power management module to restore the ability to monitor subsequent potential low-voltage events. If the current active state of the LVD interrupt indicates that there is currently an LVD event, the LVD interrupt is not re-enabled. The LVD interrupt remains disabled after the current Flash operation command is terminated until it is re-enabled after the next voltage recovery.

[0133] After an LVD interrupt occurs, the power management module disables the LVD interrupt to prevent it from being repeatedly triggered during the LVD status review of the current Flash operation command. This avoids the problem of the low-voltage event flag variable being repeatedly set, causing the Flash operation command to fail to initiate normally. Only after the current active state of the LVD interrupt indicates that there is no LVD event, i.e., the voltage has returned to the normal range, is the power management module re-enabled to restore the system's ability to monitor subsequent low-voltage events. This ensures the safe execution of Flash operation commands while also meeting the system's continuous monitoring requirements for low-voltage events.

[0134] Optionally, after an LVD interrupt occurs, a simulated LVD status notification enable bit can be written to the Flash controller to notify the Flash controller of a low-voltage event. Writing the simulated LVD status notification enable bit to the Flash controller means setting the corresponding control bit in the Flash controller's configuration register to its set value. Correspondingly, after confirming that the voltage has recovered and the LVD interrupt is re-enabled, a clear value is written to the Flash controller to notify the Flash controller that the low-voltage event has been resolved, and the low-voltage event flag variable is cleared.

[0135] Optionally, during the Flash driver initialization phase, an LVD interrupt callback function is registered with the chip's internal power management module, and the simulated LVD status notification enable bit is set in the Flash controller configuration register. Simultaneously, the low-voltage event flag variable is initialized to zero. Initializing the low-voltage event flag variable to zero means setting its value to indicate that no LVD event has occurred. Furthermore, after terminating the execution of Flash operation commands, the low-voltage event flag variable can be cleared to zero so that subsequent low-voltage events can be re-detected after voltage recovery.

[0136] In existing technologies, when an ARM Cortex-M architecture microcontroller executes programming or erasing commands, the Flash bus enters a busy state. If the processor continues to fetch instructions from Flash at this time, meaning the target function itself is located in Flash, it will cause the bus to hang, potentially leading to hardware failures. Engineering practice typically requires executing the target function in high-speed Random Access Memory (RAM). However, traditional methods require statically configuring the RAM region in the linker script, increasing linker configuration complexity and lacking the ability to execute in RAM when using general-purpose compilation toolchains such as GCC. The `__ramfunc` keyword in the above embodiment is used to directly link the function to the static RAM buffer for execution.

[0137] In order to solve the problems existing in the above-mentioned prior art Figure 2 Flowchart of the Flash control method provided in this application Figure 2 ,like Figure 2 As shown, the method includes:

[0138] S21. When a Flash operation command needs to be triggered, if the compiler toolchain does not support the keyword that directly links the function to the static random access memory (RAM) buffer for execution, then check whether the function pointer is a null pointer.

[0139] In this context, a compiler toolchain refers to a collection of software tools that compile and link source code into executable files, such as the GNU Compiler Collection (GCC) toolchain. Different compiler toolchains have varying degrees of support for the syntax of functions executing in random access memory. Some toolchains provide specific keywords to directly place functions in the static RAM buffer during the compilation and linking stage, while others (such as the GCC toolchain) do not provide such keywords.

[0140] A static RAM buffer is a contiguous storage area in random access memory reserved during the compilation and linking phases. In practice, this static RAM buffer is aligned to 4 bytes, and its address is determined during the linking phase and remains unchanged during system operation. This 4-byte alignment is used to meet the alignment requirements of instruction fetching and memory access under the ARM architecture, ensuring that the processor will not encounter exceptions due to address misalignment when fetching instructions from the RAM buffer.

[0141] The function pointer matches the signature of the target function, which is the function that needs to be stored in the static RAM buffer to execute Flash operation commands.

[0142] A function pointer is a pointer variable that points to a function. This function pointer must match the signature of the target function; that is, the parameter types and return type of the function pointed to by the function pointer must be exactly the same as the target function. It's understandable that the function pointer is initially a null pointer, indicating that the target function has not yet been copied into the static RAM buffer.

[0143] The target function is a function that needs to be stored in the static RAM buffer to execute Flash operation commands. The original location of the target function in Flash is located in the Flash storage area. However, since the Flash bus enters a busy state during the execution of Flash operation commands, if the processor continues to fetch instructions from Flash, it will cause a bus deadlock. Therefore, it is necessary to copy the machine code byte sequence of the target function into the static RAM buffer so that the processor can fetch instructions from random access memory when triggering Flash operation commands.

[0144] In practical applications, at the entry point of the Flash operation command initiation function, it can be checked whether the value of the function pointer is equal to the preset null pointer value (usually 0 or a null pointer constant). If it is equal to the null pointer value, the deployment process of the target function is entered. If it is not equal to the null pointer value, it means that the target function has been deployed to the static RAM buffer and can be called directly through the function pointer.

[0145] Optionally, if the compiler toolchain supports the keyword to directly link functions to the static RAM buffer for execution, the target function in the static RAM buffer is directly called to execute the Flash operation command.

[0146] S22. If the function pointer is a null pointer, then obtain the actual starting address of the machine code of the target function.

[0147] The actual starting address of the machine code of the target function refers to the physical address of the first byte of the machine code byte sequence stored in the Flash memory area. In processors using the ARM architecture, since the target function is compiled using the Thumb instruction set, the least significant bit of the compile-time address of the target function is used to identify the instruction set mode (a least significant bit of 1 indicates the Thumb instruction set). Therefore, this compile-time address is not the actual physical address of the machine code byte sequence of the target function.

[0148] In one possible approach, a bitwise AND operation can be performed on the compile-time address of the target function to clear the least significant bit of the compile-time address of the target function, thereby obtaining the actual starting address of the machine code of the target function.

[0149] For example, if the compile-time address of the target function is 0x08000101, then performing a bitwise AND operation on it with the operand 0xFFFFFFFE will yield 0x08000100, which is the actual starting address of the machine code of the target function.

[0150] If the function pointer is not null, the target function in the static RAM buffer is called through the function pointer to execute the Flash operation command by fetching instructions from RAM.

[0151] S23. Using the actual starting address of the machine code of the target function as the source address and the first address of the static RAM buffer as the target address, copy the machine code byte sequence of the target function into the static RAM buffer.

[0152] The machine code byte sequence refers to the sequence of binary instructions generated after the target function is compiled and can be directly executed by the processor. This machine code byte sequence is stored in the Flash memory area, and a series of consecutive bytes starting from the actual starting address of the target function's machine code constitute the complete machine code of the target function.

[0153] In practical applications, a memory copy function can be called, using the actual starting address of the machine code of the target function as the source starting address and the starting address of the static RAM buffer as the target address, to copy the byte sequence of the machine code of the target function byte by byte into the static RAM buffer.

[0154] The size of the static RAM buffer is reserved during the compilation phase based on a conservative upper bound estimate of the target function body, ensuring that it can completely accommodate the entire machine code byte sequence of the target function. During copying, the actual machine code length of the target function is used as the reference, and it is completely copied into the static RAM buffer.

[0155] S24. Construct the function pointer corresponding to the target function.

[0156] In one possible implementation, given that the actual starting address of the machine code of the target function is obtained by performing a bitwise AND operation on the compile-time address of the target function, a bitwise OR operation can also be performed on the starting address of the static RAM buffer. The least significant bit of the starting address of the static RAM buffer is set to generate the processed address, and then the processed address is type-converted and assigned to the function pointer.

[0157] Specifically, a bitwise OR operation is performed on the starting address of the static RAM buffer, setting the least significant bit of the starting address of the static RAM buffer to 1, generating the processed address, and then the processed address is type-converted and assigned to the function pointer.

[0158] For example, if the starting address of the static RAM buffer is 0x20000000, then a bitwise OR operation is performed on it with the operand 0x00000001 to obtain 0x20000001. This value is then converted to the function pointer type corresponding to the target function signature and assigned to the function pointer.

[0159] By performing a bitwise AND operation on the compile-time address of the target function to clear the least significant bit, the true starting address of the machine code of the target function in Flash is obtained. This ensures that the source address of the memory copy operation is the actual physical byte address, avoiding unaligned access exceptions. After copying, a bitwise OR operation is performed on the starting address of the static RAM buffer to set the least significant bit and reset the instruction set mode flag. This allows the processor to correctly enter the corresponding instruction set mode when jumping through a function pointer, thus achieving safe invocation of the target function in RAM without relying on special keywords in the compiler toolchain.

[0160] S25. Call the target function in the static RAM buffer through the function pointer to execute the Flash operation command by fetching instructions from RAM.

[0161] Instruction fetching from RAM refers to the processor reading and executing instructions from random access memory, rather than reading instructions from the Flash memory area. When the Flash bus enters a busy state during Flash operation command execution, the processor's instruction fetching from RAM will not trigger Flash bus access, thus avoiding bus deadlock.

[0162] In practical applications, the target function can be executed via a function pointer through a function call within the function that initiates the Flash operation command. Since the machine code byte sequence of the target function has been copied into the static RAM buffer, and the function pointer points to the starting address of the static RAM buffer, the call will jump to the static RAM buffer to execute the target function, thereby achieving the execution of Flash operation commands by fetching instructions from RAM.

[0163] In the above embodiments, when the compiler toolchain does not support the keyword to directly link functions to the static RAM buffer for execution, the deployment of the target function is determined by checking if the function pointer is null. Only when the function pointer is null is the machine code byte sequence of the target function copied from Flash to the static RAM buffer and the function pointer constructed, thus implementing a lazy loading strategy and avoiding unconditional RAM resource occupation during startup. After deployment, the target function in the static RAM buffer is called through the function pointer, and the processor fetches instructions from RAM to execute Flash operation commands. This avoids bus deadlock when the Flash bus enters a busy state, solving the problem of the lack of a static RAM deployment mechanism in general compiler toolchains.

[0164] Under critical section protection, the function pointer is checked for nullability. If the function pointer is null, the following steps are executed sequentially under critical section protection: obtaining the actual starting address of the target function's machine code, copying the target function's machine code byte sequence into the static RAM buffer, and constructing the corresponding function pointer. Accordingly, after constructing the corresponding function pointer, it is necessary to exit the critical section.

[0165] In other words, under critical section protection, it checks whether the function pointer is a null pointer, and when the function pointer is a null pointer, it executes S22-S24 in sequence under critical section protection.

[0166] A critical section is a code segment in a program that accesses shared resources. Only one execution flow is allowed to enter this segment at any given time to ensure the safety of concurrent access to shared resources. In other words, other concurrent execution flows are not allowed to enter the same critical section to access shared resources during execution.

[0167] Under critical section protection, the detection of null pointers, the copying of the machine code byte sequence of the target function, and the construction of the function pointer are performed atomically. This prevents two tasks from simultaneously performing null pointer checks in a multi-tasking environment, which could lead to the target function being copied repeatedly to the static RAM buffer, or an exception being thrown when a task uses a function pointer that has not yet been initialized. After exiting the critical section, the deployed target function can be safely reused by multiple tasks, thus ensuring data consistency and thread safety of RAM deployment operations in a multi-tasking environment while implementing lazy loading deployment.

[0168] In existing technologies, erase operation commands take significantly longer than programming operation commands, and may time out under external interference or hardware malfunctions. If the process is abandoned immediately after a timeout, the Flash controller's internal state machine remains active, and subsequent Flash operation commands will return errors because the command completion status flag is not set. Furthermore, the timeout handling methods for erase and programming operation commands differ fundamentally: the former can be safely aborted through page erase, while the latter's forced abort leaves a half-written state, leading to inconsistencies between error verification and correction codes. Existing technologies lack differentiated handling for timeouts in these two types of commands.

[0169] To solve this technical problem, Figure 3 Flowchart of the Flash control method provided in this application Figure 3 ,like Figure 3 As shown, the method includes:

[0170] S31. If a Flash operation command timeout is detected during the execution of the Flash operation command, the current command byte value in the Flash command register is read.

[0171] During the execution of Flash operation commands, after the processor sends the command to the Flash controller, the Flash controller begins to execute the corresponding operation and uses the command completion status flag in the Flash status register to indicate whether the command has been completed.

[0172] Flash operation command execution timeout refers to the situation where the duration after the Flash operation command is sent exceeds the preset timeout threshold, and the command completion status flag is still not set.

[0173] For example, the timeout threshold can be set according to the type of Flash operation command and the maximum operation time specified in the datasheet. For instance, for a page erase operation command, the execution time is from a few milliseconds to tens of milliseconds, and the timeout threshold can be set to a certain multiple of this maximum time to tolerate normal timing fluctuations.

[0174] It is understood that the timeout threshold can be preset according to the actual situation, and the embodiments of this application do not impose specific restrictions on it.

[0175] The Flash command register is an internal register of the Flash controller used to receive and store the currently executing command code. The current command byte value refers to the byte data stored in the Flash command register that represents the type of command that the Flash controller is currently executing.

[0176] It is understandable that different command types correspond to different command byte values. For example, the command byte value corresponding to the page erase command can be 0x01, the command byte value corresponding to the option page erase command can be 0x03, and the command byte value corresponding to the programming operation command can be 0x10 or 0x11, etc.

[0177] In practical applications, a timeout counter is set in the command wait loop. During each loop iteration, the command completion status flag in the Flash status register is checked. If the command completion status flag is not set, the timeout counter is decremented by 1. When the timeout counter reaches zero, it indicates that the Flash operation command has timed out. At this time, the Flash command register is read to obtain the current command byte value.

[0178] In one possible implementation, the timeout counting function can be enabled or disabled based on the input parameters. When the preset timeout waiting time parameter is 0, the timeout enable flag is false, the waiting loop only polls the command completion status flag, and does not execute the timeout counting, that is, it waits indefinitely until the command is completed; when the timeout waiting time parameter is greater than 0, the timeout enable flag is true, the timeout counter is decremented by 1 in each loop iteration, and when it is decremented to zero, it is determined to be a timeout.

[0179] S32. Based on the current command byte value, determine whether the Flash operation command is an erase command.

[0180] The erase command is used to clear data from the Flash memory. In the Flash controller's command encoding system, different types of erase commands correspond to different command byte values. For example, the command byte value for a page erase command is 0x01, and the command byte value for an option page erase command is 0x03. At the hardware level, erase commands can be safely aborted through a page erase abort operation. This means that after abort, the Flash memory can be restored to a usable erased state. Therefore, it is necessary to identify the erase command after a timeout in order to perform the appropriate safe abort processing.

[0181] In practical applications, the current command byte value read from the Flash command register can be compared with a preset range of erase command byte values. The preset range is greater than or equal to the command byte value of a page erase command and less than or equal to the command byte value of an option page erase command. If the current command byte value falls within this range, the Flash operation command is determined to be an erase command; if the current command byte value does not fall within this range, the Flash operation command is determined to be a non-erasure command.

[0182] It should be noted that the above range of erase command byte values ​​is for illustrative purposes only. In actual applications, the specific encoded values ​​and ranges of erase commands depend on the hardware design of the Flash controller and are not subject to specific restrictions.

[0183] S33. If the Flash operation command is an erase command, then execute the page erase abort operation.

[0184] The page erase abort operation refers to the operation of stopping the currently executing erase command through a hardware mechanism, so that the internal state machine of the Flash controller can be restored to an idle state.

[0185] It should be noted that although the page erase abort operation is named "page erase," its hardware abort mechanism also applies to other command types within the erase command scope, such as the optional page erase command. Because the erase command supports safe abort at the hardware level, after the page erase abort operation is executed, the Flash storage unit remains in a recoverable erased state, and subsequent erase commands can be initiated without causing issues such as a half-written state or inconsistencies between error checksums and correction codes.

[0186] In one possible implementation, a set value can be written to the page erase abort control bit in the Flash configuration register to issue a page erase abort request. Then, the command completion status flag in the Flash status register is polled until the command completion status flag indicates that the Flash operation command processing flow has ended. Finally, a clear value is written to the page erase abort control bit in the Flash configuration register to clear the page erase abort request.

[0187] The page erase abort control bit is a control bit in the Flash configuration register used to trigger and clear page erase abort requests. Setting this bit sends a page erase abort request to the Flash controller, requesting the controller to stop the currently executing erase command; clearing this bit clears the page erase abort request, restoring the Flash configuration register to its normal state, preparing for the execution of subsequent Flash operation commands.

[0188] The command completion status flag is a status bit in the Flash status register used to indicate whether the Flash controller is currently executing a command. When the command completion status flag is set, it indicates that the Flash controller's internal state machine is idle and no command is currently executing, meaning the Flash operation command processing flow has ended. When the command completion status flag is not set, it indicates that the Flash controller's internal state machine is busy and commands are still being executed. Polling the command completion status flag means repeatedly reading its value until it becomes set, confirming that the page erase abort operation has been completed.

[0189] In practical applications, the execution flow of the above three-stage operation is as follows: First, the processor writes a 1 to the page erase abort control bit in the Flash configuration register, sending a page erase abort request to the Flash controller. Upon receiving the request, the Flash controller begins to abort the currently executing erase command and gradually restores its internal state machine to an idle state. Then, the processor enters a wait loop, continuously reading the command completion status flag in the Flash status register. When the command completion status flag becomes 1, it indicates that the Flash controller's internal state machine has completed the abort and returned to an idle state. Finally, the processor writes a 0 to the page erase abort control bit in the Flash configuration register, clearing the page erase abort request and restoring the Flash configuration register to its normal state, so that new Flash operation commands can be initiated normally subsequently.

[0190] A page erase abort request is sent by writing a set value to the page erase abort control bit in the Flash configuration register. Then, the command completion status flag in the Flash status register is polled until the Flash operation command processing flow is confirmed to be complete. Finally, a clear value is written to the page erase abort control bit to clear the page erase abort request, completing the three-stage abort handshake protocol. This process ensures that the Flash controller's internal state machine has been completely reset to the idle state after receiving the abort request, and the Flash configuration register returns to its normal state, providing a reliable hardware state guarantee for the normal initiation of subsequent Flash operation commands.

[0191] S34. If the Flash operation command is not an erase command, the page erase abort operation will not be performed.

[0192] Non-erasing commands refer to Flash operation commands whose current command byte value does not fall within the range of erase command byte values. For example, a non-erasing command can be a programming operation command, and its command byte value can be 0x10 or 0x11, etc.

[0193] For programming commands, the hardware does not support safe abort via page erase, because programming is a process of charging and discharging Flash memory cells to write data. If the programming is forcibly aborted, the memory cells will be in an uncertain half-written state, causing a mismatch between the actual written data and the error check and correction code, resulting in uncorrectable errors during subsequent reading.

[0194] Therefore, for non-erase commands, the page erase abort operation is not performed. Instead, the timeout handling process directly returns to the timeout state, and the upper-layer application or system reset mechanism performs subsequent recovery processing.

[0195] In the above embodiments, when a Flash operation command execution timeout is detected, the type of the currently executing command is dynamically identified by reading the current command byte value in the Flash command register, rather than by the operation type parameter being passed in from the calling layer. This decouples the timeout abort logic from the calling context. Based on the fundamental difference that erase commands can be safely aborted at the hardware level through page erase abort operations, while forced aborts using non-erasure commands can lead to data corruption, page erase abort operations are only performed on erase commands, and not on non-erasure commands. This fundamentally prevents data corruption problems caused by forced aborts of non-erasure commands.

[0196] Optionally, in some embodiments, after exiting the wait loop, the error flag bit in the Flash status register can be checked, and the corresponding status can be returned based on the check result.

[0197] In practical applications, after exiting the wait loop, all error flags in the Flash status register are checked: if any error flag is set, an error status is returned, indicating that a hardware error occurred during the execution of the Flash operation command; if all error flags are not set, and the exit from the wait loop was due to a timeout caused by the timeout counter returning to zero, a timeout status is returned, indicating that the Flash operation command was not completed within the preset time; if all error flags are not set, and the command completion status flag is set, a success status is returned, indicating that the Flash operation command has been executed normally.

[0198] To more clearly explain the solutions shown in the foregoing embodiments, several specific embodiments are described below.

[0199] In the foregoing embodiments, Figure 1 The embodiments shown correspond to the LVD protection stage. Figure 2 The illustrated embodiment corresponds to the RAM deployment stage. Figure 3 The illustrated embodiment corresponds to the timeout abort phase, and all three factors work together on the core path of initiating and executing Flash operation commands. Specifically, Figure 2 The illustrated embodiment ensures that the target function is executed safely in RAM, which is a prerequisite for initiating any Flash operation command; Figure 1 The illustrated embodiment is in Figure 2 The embodiment shown completes the LVD status check before execution, which is a gatekeeping mechanism for voltage safety; Figure 3 The illustrated embodiment is in Figure 2 The exception timeout handling mechanism, implemented after the Flash operation command has been issued and is in the waiting-to-complete stage, serves as a fallback mechanism for ensuring the safety of the result. These three elements are sequentially linked, collectively forming a comprehensive security guarantee for the entire Flash operation from initiation to completion.

[0200] Figure 4 Flowchart of the Flash control method provided in this application Figure 4 ,like Figure 4 As shown, the method includes:

[0201] S401, Invokes the Flash operation command in the direction of Flash_Hal_StartCmd.

[0202] Among them, Flash_Hal_StartCmd is the Flash operation command initiation function shown in the previous embodiment.

[0203] S402, Flash_Hal_StartCmd enters the LVD protection phase.

[0204] That is, the status of the low voltage event flag variable is detected. If the low voltage event flag variable is set, the current active status of the LVD interrupt in the interrupt controller is further read to confirm whether the voltage has recovered.

[0205] S403. If the current active status of the LVD interrupt indicates that an LVD event exists, meaning that the current voltage is abnormal and has not recovered, then return STATUS_ABORT to the caller and terminate this Flash operation command.

[0206] STATUS_ABORT is the exception status code shown in the previous embodiment.

[0207] S404. If the low voltage event flag variable is not set, or if the low voltage event flag variable is set but the current active state of the LVD interrupt indicates that there is no LVD event, that is, the current voltage is normal, then Flash_Hal_StartCmd enters the RAM deployment stage, and calls the target function in the static RAM buffer through the function pointer to trigger the Flash operation command by fetching instructions from RAM.

[0208] S405, the Flash operation command is officially issued, and the processor fetches instructions from the static RAM buffer to execute the target function.

[0209] S406 and Flash_Hal_StartCmd enter the timeout abort phase, enter the command completion waiting loop, continuously poll the command completion status flag, and monitor the timeout counter.

[0210] S407. If the timeout counter reaches zero, it indicates that a timeout has occurred. In this case, STATUS_TIMEOUT is returned to Flash_Hal_StartCmd.

[0211] STATUS_TIMEOUT refers to the timeout status.

[0212] S408. If the command completion status flag is set before the timeout, it means that no timeout has occurred, and STATUS_SUCCESS is returned to Flash_Hal_StartCmd.

[0213] STATUS_SUCCESS indicates a successful status.

[0214] S409, Flash_Hal_StartCmd returns the final status of the operation to the caller.

[0215] Furthermore, the specific implementation process of the LVD protection phase will be explained in detail.

[0216] It should be noted that during the Flash driver initialization process in the LVD protection phase, the LVD interrupt callback function is registered with the power management module, the simulated LVD status notification enable bit is set in the Flash controller configuration register, and the volatile flag variable McuLvdFlag is initialized to zero.

[0217] In this context, MculvdFlag is the low-voltage event flag variable in the aforementioned embodiment, and volatile indicates that the low-voltage event flag variable is a volatile variable.

[0218] Furthermore, during system operation, when an LVD interrupt occurs, it is also necessary to execute the following: Figure 5 The interrupt callback process is shown.

[0219] Figure 5 Flowchart of the Flash control method provided in this application Figure 5 ,like Figure 5 As shown, the interrupt callback process includes:

[0220] S51, LVD interrupt triggered, enters LVD interrupt callback function.

[0221] S52. Write EmulvdStatus=1 to the Flash controller to notify the Flash controller that a low voltage event has occurred.

[0222] Here, EmulvdStatus is the simulated LVD status notification enable bit in the aforementioned embodiment.

[0223] S53. Set MculvdFlag to 1.

[0224] S54. The power management module disables the LVD interrupt to prevent repeated triggering.

[0225] S55, LVD interrupt callback function returns.

[0226] All of the above operations are performed in the interrupt context, without executing Flash-related control operations, thus avoiding interrupt re-entry.

[0227] Figure 6 Flowchart of the Flash control method provided in this application Figure 6 ,like Figure 6 As shown, the LVD protection phase includes:

[0228] S601, Call Flash_Hal_StartCmd.

[0229] S602. Determine if MculvdFlag is equal to 1.

[0230] If yes, then execute S603; otherwise, execute S609.

[0231] S603, Call the MculvdClearAndGetStatus function to atomically read the LVD status.

[0232] S604. Determine if the LVD state is 0.

[0233] If not, execute S605; if yes, execute S606.

[0234] S605, Return to STATUS_ABORT, terminating this Flash operation command.

[0235] S606 Enable LVD interrupt.

[0236] S607. Write EmulvdStatus=0 to the Flash controller.

[0237] S608, Set MculvdFlag to 0.

[0238] S609, Normal execution flow of Flash operation command.

[0239] S610, Return the execution result.

[0240] Specifically, the aforementioned S603 can be achieved through... Figure 7 The specific implementation is shown below.

[0241] Figure 7 Flowchart of the Flash control method provided in this application Figure 7 ,like Figure 7 As shown, S603 includes:

[0242] S71. Enter the MculvdClearAndGetStatus function.

[0243] S72. Write 1 to the control bit corresponding to the LVD interrupt in the NVIC interrupt clearing register to clear the LVD interrupt's pending state.

[0244] The NVIC interrupt clearing pending register is the same as the interrupt clearing pending register in the aforementioned embodiment, with an address of 0xE000E284; NVIC is the interrupt controller in the aforementioned embodiment.

[0245] S73. Execute at least two no-operation instructions to ensure that the write operation is fully committed to the register file in the processor pipeline to prevent subsequent readings of outdated states.

[0246] Understandably, if no no-operation instructions are inserted, pipeline out-of-order readings may result in reading values ​​that were not cleared, leading to incorrect LVD status determinations.

[0247] S74. Read the control bit corresponding to the LVD interrupt in the NVIC interrupt active status register, obtain the current active status of the LVD interrupt and return.

[0248] The NVIC interrupt active status register is the same as the interrupt active status register in the aforementioned embodiment, with an address of 0xE000E204.

[0249] S75, Return the read value.

[0250] If the return value is 0, it means the voltage has been restored; if the return value is not 0, it means the voltage is still low.

[0251] The following section provides a detailed explanation of the LVD protection phase using the AC7842X platform.

[0252] The power management module of the AC7842X platform is responsible for LVD detection, and LVD interrupts are routed to the processor via NVIC.

[0253] During the initialization phase, the Flash driver registers the LVD interrupt callback function with the power management module, sets the enable bit of the analog LVD status notification in the Flash controller configuration register, and initializes MculvdFlag to zero.

[0254] During operation, when an LVD event occurs, the LVD interrupt callback function sets EmulvdStatus to 1 to notify the Flash controller that a low voltage event has occurred; sets MculvdFlag to 1; and then the power management module disables the LVD interrupt. The entire interrupt callback process does not perform Flash-related control operations, and there is no risk of reentrancy.

[0255] Before each Flash operation command is initiated, Flash_Hal_StartCmd checks McuLvdFlag. If McuLvdFlag is 1, it directly manipulates the NVIC register to determine if the voltage has been restored: it writes 1 to the LVD interrupt control bit corresponding to address 0xE000E284 to clear the LVD interrupt's pending state, executes two no-operation instructions to wait for the processor pipeline to commit, and then reads the LVD interrupt control bit corresponding to address 0xE000E204 to obtain the current active status of the LVD interrupt. If the current active status of the LVD interrupt indicates that an LVD event exists, it immediately returns to STATUS_ABORT; if the current active status of the LVD interrupt indicates that no LVD event exists, it re-enables the LVD interrupt and continues executing the Flash operation command.

[0256] In summary, during the LVD protection phase, LVD interrupt response and Flash operation command execution are completely decoupled—the LVD interrupt callback function is only responsible for recording the event status, while the Flash operation command path is responsible for checking and making decisions before the command is initiated. The two communicate through the volatile flag variable MculvdFlag, eliminating the reentrancy risk of directly executing Flash-related control operations in the interrupt context.

[0257] Furthermore, the specific implementation process of the RAM deployment phase will be explained in detail.

[0258] Understandably, two static variables are declared in the global scope of the driver module: one is a 4-byte aligned static RAM buffer, the size of which is a conservative estimate of the upper bound of the target function body, initialized to all zeros; the other is a function pointer that matches the signature of the target function, initialized to a null pointer.

[0259] Figure 8 Flowchart of the Flash control method provided in this application Figure 8 ,like Figure 8 As shown, this RAM deployment phase includes:

[0260] S81, When a Flash operation command needs to be triggered.

[0261] S82, Entering the critical section of the operating system.

[0262] S83. Determine if the function pointer is NULL_PTR.

[0263] Here, NULL_PTR is the null pointer in the above embodiment.

[0264] If yes, it means this is the first time the target function has been called, so execute S84; if no, it means the target function has already been deployed, so execute S87.

[0265] S84. Perform a bitwise AND operation on the compile-time address of the target function, with the operand being 0xFFFFFFFE. Clear the least significant bit of the result to obtain the actual starting address of the machine code of the target function in Flash.

[0266] This operation is based on the ARM architecture binary interface specification: Under the Thumb instruction set, the least significant bit of the function pointer is not part of the address, but is used to identify the instruction set mode. 1 indicates the Thumb instruction set. Therefore, clearing the least significant bit yields the actual byte address of the target function in Flash.

[0267] S85. Using the actual starting address of the machine code of the target function as the source address and the starting address of the static RAM buffer as the target address, call the memory copy function to copy the machine code byte sequence of the target function into the static RAM buffer.

[0268] S86. Perform a bitwise OR operation on the starting address of the static RAM buffer, with operand 0x00000001. Set the least significant bit of the result to 1, and assign it to the function pointer after type conversion.

[0269] This means reloading the Thumb instruction set mode flag according to the ARM architecture binary interface specification.

[0270] S87, Exit the critical region.

[0271] S88. Call the target function in the static RAM buffer through the function pointer to trigger the Flash operation command startup sequence.

[0272] At this time, the processor fetches instructions from the static RAM buffer. The busy state of the Flash bus does not affect the instruction pipeline, thus avoiding bus deadlock.

[0273] S89, Flash operation command triggered and completed.

[0274] Understandably, when the compiler is a toolchain that supports the keyword __ramfunc, the target function has already been placed directly in the RAM segment by the linker during the compilation and linking stage. Therefore, the above steps S83 to S87 are skipped, and the target function is called directly.

[0275] Here, `__ramfunc` is the keyword used in the above embodiment to directly link the function to the static RAM buffer for execution. Both paths are managed uniformly within the same codebase through compile-time macro conditions, making them transparent to the caller.

[0276] The following section provides a detailed explanation of the RAM deployment phase, using the AC7840X / AC7842X platform as an example.

[0277] Static storage allocation: Declare a static RAM buffer of 128 32-bit words (512 bytes) aligned to 4 bytes in the global scope of the driver module, along with a function pointer initialized to NULL_PTR. The 512 bytes is a conservative upper bound estimate of the target function's machine code byte sequence size; the actual compilation output typically does not exceed 60 bytes. This margin ensures that copy operations do not exceed this limit.

[0278] The necessity of least significant bit processing: The bitwise AND step of 0xFFFFFFFE is based on the ARM Cortex-M AAPCS specification—the least significant bit of all Thumb instruction set function pointers is forced to 1, indicating Thumb instruction set mode, and this bit does not participate in addressing; directly using this value as the source address of a memory copy function will lead to an unaligned access exception. The bitwise OR step of 0x00000001 ensures that the function pointers on the static RAM buffer side conform to the AAPCS specification, and that the processor can correctly enter Thumb instruction set mode instead of ARM mode during jumps.

[0279] The purpose of a critical section is to prevent two tasks from simultaneously passing a null pointer check in a multitasking environment, thus preventing the problem of the check time being used, ensuring the atomicity of the copy operation, and preventing one task from using a half-initialized function pointer while the copy is not yet completed.

[0280] When the __ramfunc keyword exists, the target function with the __ramfunc attribute is called directly through compile-time conditional branches. The linker has already placed its machine code byte sequence in the RAM segment during the build phase, so there is no need to copy it at runtime.

[0281] In summary, during the RAM deployment phase, the specification of using the least significant bit of the function pointer as an instruction set mode flag in the ARM architecture binary interface specification is precisely utilized. By clearing the least significant bit to obtain the actual starting address of the machine code, copying the machine code byte sequence, and resetting the least significant bit to construct a callable function pointer, equivalent execution capability in RAM is achieved under mainstream compilation toolchains such as GCC that do not support __ramfunc. At the same time, through lazy loading strategies and critical section protection, the unconditional occupation of RAM resources during the startup phase and the problem of repeated copying in a multi-tasking environment are avoided.

[0282] Furthermore, the specific implementation process of the timeout termination phase will be explained in detail.

[0283] Figure 9 Flowchart of the Flash control method provided in this application Figure 9 ,like Figure 9 As shown, the timeout termination phase includes:

[0284] S901, Enter command completion waiting loop.

[0285] S902. Determine whether the CCIF bit in the Flash status register is equal to 1.

[0286] The CCIF bit is the command completion status flag bit mentioned above.

[0287] If not, it means the Flash operation command is still being executed, so proceed to S903; if yes, it means the Flash operation command has been completed normally, so proceed to S910.

[0288] S903. Decrement the timeout counter TmpWait_Timeout by 1. TmpWait_Timeout is the timeout counter in the above embodiment.

[0289] S904. Determine if TmpWait_Timeout has returned to zero.

[0290] If yes, it means a timeout has occurred, and S905 will be executed; otherwise, return to S902 and continue waiting.

[0291] S905. Read the current command byte value from the Flash command register. In a specific implementation, the Flash command register can be the CMD register.

[0292] S906. Determine whether the current command byte value is greater than or equal to the page erase command value 0x01 and less than or equal to the option page erase command value 0x03.

[0293] If yes, it means the current Flash operation command is an erase command, and S907 is executed; if no, it means the current Flash operation command is not an erase command, and S911 is executed.

[0294] S907: Write 1 to the page erase stop control bit in the Flash configuration register.

[0295] In this implementation, the Flash configuration register can be the CNFG register, and the page erase abort control bit can be the PERABORT control bit.

[0296] S908. Determine if the command completion status flag is equal to 1.

[0297] If yes, it means that the internal state machine of the Flash controller has completed the termination and reset to the idle state, and then execute S909; if no, return to execute S908 and continue to wait.

[0298] S909: Write 0 to the page erase abort control bit in the Flash configuration register to clear the page erase abort request.

[0299] S910, Exit command completion waiting loop.

[0300] S911. Check all error flags in the Flash status register to determine if any error flag is set.

[0301] If yes, then execute S912; otherwise, execute S913.

[0302] S912, returns STATUS_ERROR.

[0303] S913. Determine if TmpWait_Timeout has returned to zero.

[0304] If yes, then execute S914; otherwise, execute S915.

[0305] S914, returns STATUS_TIMEOUT.

[0306] S915, returns STATUS_SUCCESS.

[0307] The following section, using the AC7840E platform as an example, explains the timeout termination phase by taking the execution of the Flash trigger function in RAM as an example.

[0308] Taking page erase command timeout as an example, the timing sequence is as follows: The upper layer calls DFlash_Hal_PageErase, sets the erase command byte value to 0x01, and passes a non-zero timeout counter value to Flash_Hal_StartCmd. It enters the command completion wait loop, decrementing the timeout counter with each iteration. If the timeout counter reaches zero, it reads the current command byte value from the Flash command register, confirms its value is 0x01, falling within the erase command range of 0x01 to 0x03, and executes the page erase abort operation: it writes 1 to the page erase abort control bit, sends a page erase abort request, waits for the command completion status flag to be set, then writes 0 to the page erase abort control bit to clear the page erase abort request, confirming that the Flash controller's internal state machine has been reset to the idle state. After exiting the command completion wait loop, it checks the error flag in the Flash status register. If no error flag is set, it returns STATUS_TIMEOUT. The caller can then decide whether to retry the erase operation.

[0309] If the programming operation command times out, i.e. the current command byte value is 0x10 or 0x11, and the current command byte value read from the Flash command register is not in the range of 0x01 to 0x03, then the page erase abort operation is skipped, the command completion waiting loop is exited directly and STATUS_TIMEOUT is returned, and the upper-layer application decides on subsequent processing based on business logic.

[0310] In summary, during the timeout abort phase, the current command type is dynamically identified by reading back the Flash command register during timeout processing, rather than by passing the operation type parameter from the calling layer, thus decoupling the timeout abort logic from the calling context. Furthermore, based on the fundamental difference between the safe abort of erase commands and the inconsistency between error verification and correction codes caused by the forced abort of programming operation commands, the corresponding abort strategy is selected to prevent the implicit error verification and correction code inconsistency problem introduced by the forced abort of programming operation commands.

[0311] In summary, this application relates to the field of on-chip Flash memory control for embedded microcontrollers, specifically a Flash control method for ARM Cortex-M architecture microcontrollers, including: an LVD interrupt-aware Flash operation command safe abort mechanism, an on-demand RAM deployment mechanism for objective functions, and a command type-aware erase timeout differentiated abort protocol. To address the shortcomings of existing technologies in the LVD protection phase, RAM deployment phase, and timeout abort phase, which make it difficult to simultaneously meet the requirements of functional safety levels and compiler toolchain universality, the following solution is proposed:

[0312] Firstly, based on the asynchronous volatile flag variable McuLvdFlag, LVD-aware Flash operation command safety control records only events in the LVD interrupt context. Before each Flash operation command is initiated, the current voltage status is atomically read by directly manipulating the NVIC interrupt clearing pending register and the NVIC interrupt active status register. If the voltage has not recovered, an exception status code is returned, eliminating the risk of data corruption caused by programming operation commands during low voltage periods. McuLvdFlag is the low voltage event flag variable in the above embodiment; volatile indicates that the low voltage event flag variable is volatile; the NVIC interrupt clearing pending register is the interrupt clearing pending register in the above embodiment; and the NVIC interrupt active status register is the interrupt active status register in the above embodiment.

[0313] Secondly, based on lazy loading and the ARM architecture Thumb instruction set address encoding specification, the RAM deployment of target functions is achieved through a three-step sequence of "clearing the least significant bit to obtain the actual starting address of the machine code → copying the machine code byte sequence → resetting the least significant bit to construct a callable function pointer". This allows the target functions to be deployed to the static RAM buffer for execution on demand without relying on the static configuration of the linker script, thus solving the problem of the lack of a RAM execution mechanism in the general compilation toolchain.

[0314] Third, during timeout processing, the current command type is dynamically identified by reading back the Flash command register. Only the page erase operation is performed for erase commands, and the program operation command exits and waits for timeouts. This prevents the error check and correction code from being inconsistent due to forced termination of the program operation command and the introduction of half-write.

[0315] The above scheme is sequentially linked in the timeline from the initiation to the completion of Flash operation commands, forming a full-link security guarantee.

[0316] Furthermore, the technical effects of this application include:

[0317] 1. Eliminate the risk of Flash data corruption during LVD: Through an asynchronous flag mechanism, secure coordination between LVD events and Flash operation commands is achieved without disabling global interrupts, meeting the response timing requirements for functional safety in the automotive safety integrity level of ISO 26262.

[0318] 2. Compiler toolchain-independent RAM execution scheme: By precisely utilizing the least significant bit encoding specification of the function pointer in the ARM architecture Thumb instruction set, the ability to execute in RAM is achieved under the GCC compilation toolchain, and lazy loading avoids unconditional occupation of RAM resources during the startup phase.

[0319] 3. Preventing Hidden Data Corruption Caused by Timeout Aborts: By dynamically identifying the command type through reading back the Flash command register, page erase abort operations are only performed on erase commands that can be safely aborted. This fundamentally eliminates the problem of inconsistent checksums and correction codes caused by forcibly aborting programming commands. Specifically, the Flash command register can be the CMD register in the implementation, and the page erase abort operation can be PERABORT.

[0320] 4. Holistic security across the entire chain: The three sub-solutions are sequentially linked in the call sequence to form a complete closed loop of "voltage check before execution → RAM isolation during execution → timeout handling after execution", without relying on additional processing from upper-layer applications.

[0321] Figure 10 This is a schematic diagram of the structure of the Flash control device provided in this application, as shown below. Figure 10 As shown, the Flash control device 100 provided in this embodiment includes:

[0322] The detection module 1001 is used to detect the state of the low-voltage event flag variable before initiating a Flash operation command. The low-voltage event flag variable is a volatile variable, set by the LVD interrupt callback function when an LVD interrupt occurs. The LVD interrupt callback function runs in an interrupt context, and no Flash-related control operations are performed within the LVD interrupt callback function.

[0323] The clear module 1002 is used to clear the LVD interrupt pending state if the low voltage event flag variable is set.

[0324] The reading module 1003 is used to read the current active status of LVD interrupts in the interrupt controller.

[0325] The execution module 1004 is used to execute Flash operation commands if the current active state of the LVD interrupt indicates that there is currently no LVD event.

[0326] The execution module 1004 is also used to terminate the execution of Flash operation commands if the current active state of the LVD interrupt indicates that an LVD event exists.

[0327] In one possible implementation, the Flash control device 100 further includes a control module for:

[0328] After an LVD interrupt occurs, the LVD interrupt is disabled via the power management module.

[0329] If the current active state of the LVD interrupt indicates that there are currently no LVD events, then the LVD interrupt will be re-enabled through the power management module.

[0330] In one possible implementation, the reading module 1003 is specifically used for:

[0331] Execute at least two no-operation instructions.

[0332] Read the bit corresponding to the LVD interrupt in the interrupt activity status register of the interrupt controller to obtain the current active status of the LVD interrupt.

[0333] In one possible implementation, the Flash control device 100 further includes:

[0334] The detection module 1001 is also used to detect whether the function pointer is null when a Flash operation command needs to be triggered, if the compilation toolchain does not support the keyword of directly linking the function to the static RAM buffer for execution. The function pointer matches the signature of the target function, which is the function that needs to be stored in the static RAM buffer to execute the Flash operation command.

[0335] The module is used to obtain the actual starting address of the machine code of the target function if the function pointer is null.

[0336] The copy module is used to copy the machine code byte sequence of the target function into the static RAM buffer, using the actual starting address of the machine code of the target function as the source address and the starting address of the static RAM buffer as the destination address.

[0337] The building block is used to construct the function pointer corresponding to the target function.

[0338] Flash operation commands are executed by calling the target function in the static RAM buffer through a function pointer, in order to fetch instructions from RAM.

[0339] In one possible implementation, the acquisition module is specifically used for:

[0340] Perform a bitwise AND operation on the compile-time address of the target function, clear the least significant bit of the compile-time address of the target function, and obtain the actual starting address of the machine code of the target function.

[0341] Accordingly, building modules are specifically used for:

[0342] Perform a bitwise OR operation on the starting address of the static RAM buffer, and set the least significant bit of the starting address of the static RAM buffer to generate the processed address.

[0343] The processed address is type-converted and then assigned to the function pointer.

[0344] In one possible implementation, under critical section protection, it is detected whether the function pointer is a null pointer, and when the function pointer is a null pointer, under critical section protection, the following steps are executed sequentially: obtaining the actual starting address of the machine code of the target function, copying the machine code byte sequence of the target function into the static RAM buffer, and constructing the function pointer corresponding to the target function.

[0345] Correspondingly, after constructing the function pointer corresponding to the target function, the control module is also used to exit the critical section.

[0346] In one possible implementation, the reading module 1003 is further configured to read the current command byte value in the Flash command register if a Flash operation command execution timeout is detected during the execution of the Flash operation command.

[0347] The processing module is also used to determine whether the Flash operation command is an erase command based on the current command byte value.

[0348] The execution module 1004 is also used to perform a page erase abort operation if the Flash operation command is an erase command.

[0349] The execution module 1004 is also used to prevent the page erase abort operation if the Flash operation command is not an erase command.

[0350] In one possible implementation, the execution module 1004 is specifically used for:

[0351] Write a set value to the page erase abort control bit in the Flash configuration register to execute the page erase abort request.

[0352] Poll the command completion status flag in the Flash status register until the command completion status flag indicates that the Flash operation command processing flow has ended.

[0353] Write a zero value to the page erase abort control bit in the Flash configuration register to clear the page erase abort request.

[0354] The Flash control device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0355] Figure 11 A schematic diagram of the structure of the electronic device provided in this application. Figure 11 As shown, the electronic device 110 provided in this embodiment includes at least one processor 1101 and a memory 1102. Optionally, the electronic device 110 further includes a communication component 1103. The processor 1101, the memory 1102, and the communication component 1103 are connected via a bus 1104.

[0356] In a specific implementation, at least one processor 1101 executes computer execution instructions stored in memory 1102, causing at least one processor 1101 to perform the above-described method.

[0357] The specific implementation process of processor 1101 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0358] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0359] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0360] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0361] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0362] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0363] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0364] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0365] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0366] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0367] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0368] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0369] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0370] Finally, it should be noted that other embodiments of this application will readily conceive of by those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes may be made without departing from its scope.

Claims

1. A Flash control method, characterized in that, include: Before initiating a Flash operation command, the state of the low voltage event flag variable is checked; wherein, the low voltage event flag variable is a volatile variable, which is set by the LVD interrupt callback function when the power supply voltage drops and an LVD interrupt is generated; the LVD interrupt callback function runs in the interrupt context, and no Flash-related control operations are performed within the LVD interrupt callback function; If the low voltage event flag variable is set, the LVD interrupt pending state is cleared. Read the current active status of LVD interrupts in the interrupt controller; If the current active state of the LVD interrupt indicates that there is currently no LVD event, then the Flash operation command is executed; If the current active state of the LVD interrupt indicates that an LVD event is currently present, then the execution of the Flash operation command will be terminated.

2. The method according to claim 1, characterized in that, The method further includes: After the LVD interrupt is generated, the LVD interrupt is disabled through the power management module; If the current active state of the LVD interrupt indicates that there is currently no LVD event, then the LVD interrupt is re-enabled through the power management module.

3. The method according to claim 1, characterized in that, The current active state of the LVD interrupt in the read interrupt controller includes: Execute at least two no-operation instructions; Read the bit corresponding to the LVD interrupt in the interrupt activity status register of the interrupt controller to obtain the current activity status of the LVD interrupt.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: When the Flash operation command needs to be triggered, if the compilation toolchain does not support the keyword of directly linking the function to the static high-speed memory RAM buffer for execution, then it checks whether the function pointer is a null pointer; wherein, the function pointer matches the signature of the target function, and the target function is the function that needs to be stored in the static RAM buffer for executing the Flash operation command; If the function pointer is a null pointer, then obtain the actual starting address of the machine code of the target function; Using the actual starting address of the machine code of the target function as the source address and the first address of the static RAM buffer as the target address, the machine code byte sequence of the target function is copied into the static RAM buffer; Construct the function pointer corresponding to the target function; The target function in the static RAM buffer is called through the function pointer to execute the Flash operation command by fetching instructions from RAM.

5. The method according to claim 4, characterized in that, Obtaining the actual starting address of the machine code of the target function includes: Perform a bitwise AND operation on the compile-time address of the target function, clear the least significant bit of the compile-time address of the target function, and obtain the actual starting address of the machine code of the target function; Accordingly, constructing the function pointer corresponding to the target function includes: Perform a bitwise OR operation on the starting address of the static RAM buffer, and set the least significant bit of the starting address of the static RAM buffer to generate the processed address; The processed address is type-converted and then assigned to the function pointer.

6. The method according to claim 4, characterized in that, Under critical section protection, it is detected whether the function pointer is a null pointer. When the function pointer is a null pointer, under critical section protection, the following steps are executed in sequence: obtaining the actual starting address of the machine code of the target function, copying the machine code byte sequence of the target function into the static RAM buffer, and constructing the function pointer corresponding to the target function. Accordingly, after constructing the function pointer corresponding to the target function, the method further includes: Exit the critical region.

7. The method according to any one of claims 1-3, characterized in that, The method further includes: If a timeout is detected during the execution of the Flash operation command, the current command byte value in the Flash command register is read. Based on the current command byte value, determine whether the Flash operation command is an erase command; If the Flash operation command is an erase command, then the page erase abort operation is performed; If the Flash operation command is not an erase command, the page erase abort operation will not be performed.

8. The method according to claim 7, characterized in that, The execution of the page erase abort operation includes: Write a set value to the page erase abort control bit in the Flash configuration register to execute the page erase abort request; Poll the command completion status flag in the Flash status register until the command completion status flag indicates that the processing flow of the Flash operation command has ended; Write a zero value to the page erase abort control bit in the Flash configuration register to clear the page erase abort request.

9. A Flash control device, characterized in that, include: The detection module is used to detect the state of the low voltage event flag variable before initiating the Flash operation command; wherein, the low voltage event flag variable is a volatile variable, which is set by the LVD interrupt callback function when the power supply voltage drops and an LVD interrupt is generated; the LVD interrupt callback function runs in the interrupt context, and no Flash-related control operations are performed within the LVD interrupt callback function; The clearing module is used to clear the LVD interrupt pending state if the low voltage event flag variable is set. The read module is used to read the current active status of LVD interrupts in the interrupt controller; The execution module is used to execute the Flash operation command if the current active state of the LVD interrupt indicates that there is currently no LVD event; The execution module is further configured to terminate the execution of the Flash operation command if the current active state of the LVD interrupt indicates that an LVD event currently exists.

10. An electronic device / computer-readable storage medium / computer program product, characterized in that, The electronic device includes: a memory and a processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8; The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-8; The computer program product includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.