Page transaction differential firmware update method for single-bank flash memory and computer device

Abstract

This invention relates to a page transaction differential firmware update method and computer device for single-bank flash memory. The update is executed by a bootloader that runs before the application program after a reset. The single-bank flash memory includes an application area, a swap area, and a transaction record area. During the update, after verifying the old content summary of the target erase unit, the old content is copied to the swap area. The erase unit is erased after the snapshot summary matches the old content summary and the backup record passes verification. Then, according to an instruction stream consisting of copy instructions and literal instructions, the erase unit is reconstructed using the old content in the swap area and the updated data via an output buffer at the smallest programming granularity. A readback verification is performed, and the swap area snapshot is released after the target page summary matches the target content summary and the page commit record passes verification. This invention does not require a second application image, can still safely update even when the random access memory cannot hold the complete target page, and can redetermine the recovery starting point after a reset, thus improving reliability.

Description

Technical Field

[0001] This invention relates to firmware updates for embedded devices, and more specifically to a page transaction differential firmware update method and computer device for a single-bank flash memory device. Background Technology

[0002] Many microcontrollers store application programs in on-chip flash memory. Flash memory cannot be overwritten with arbitrary bytes like ordinary memory. Usually, a complete physical unit must be erased first, and then new data is written in a smaller programming granularity. The device datasheet may refer to this physical erased unit as a page, sector, or block.

[0003] Devices with sufficient resources can set up two application image areas: one image continues to run, and the other image receives updates. After verification, they are switched. Single-bank devices have only one application image area, and often do not have enough random access memory to store the complete target image, or even to accommodate an erase unit at a time. Therefore, it is difficult to directly adopt dual-image updates.

[0004] Differential updates only transmit the differences between the old and new firmware. The copy command reuses data from the old firmware, while the literal command provides new data. If the target page is erased before the copy command is executed, the old data that was originally intended to be reused will also be lost. If only the unchanged markings in the area are skipped during writing, the area that has been completely erased cannot be recovered.

[0005] Power outages further complicate matters. After erasure or programming is interrupted, the target page may be in a state of being erased, partially written, or with unknown content. The progress record itself may also be incomplete. A single stage value is insufficient to prove that the old page has been fully preserved or that the target page has been reconstructed. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a page transaction differential firmware update method and computer device for single-bank flash memory.

[0007] The technical solution adopted by this invention to solve the above problems is as follows: a page transaction differential firmware update method for single-bank flash memory, executed by a bootloader that obtains execution rights before the application program after reset, the bootloader being stored in a protected boot area; the single-bank flash memory is provided with an application area, a swap area, and a transaction record area, the capacity of the swap area being not less than the capacity of the largest target erase unit in the application area; the page transaction differential firmware update method includes: S1. Obtain page update information and update data for the current target erasure unit to be updated. The page update information includes an update identifier, target address, old content summary, target content summary, and an instruction stream arranged in order of target address. The instruction stream includes a copy instruction to retrieve data from the old content of the current target erasure unit and a literal instruction to retrieve data from the update data. The output of the instruction stream covers all target bytes of the current target erasure unit. S2. Read the current target erasure unit, calculate the actual digest and check it against the old content digest; after the check is successful, copy the complete old content of the current target erasure unit to the exchange area, read the complete old content in the exchange area and calculate the snapshot digest; after the snapshot digest is consistent with the old content digest, form a backup valid record in the transaction record area that binds the update identifier, target address, old content digest and target content digest; under the condition that the backup valid record passes the verification and the snapshot digest is consistent with the old content digest, erase the current target erasure unit; S3. After erasure is completed, the instruction stream is executed in the order of the target address. The copy instruction reads data only from the complete old content in the swap area through digest verification, and the literal instruction reads data from the updated data obtained in step S1. The output of the two types of instructions is sent to the output buffer. The capacity of the output buffer is less than the current target erase unit and not less than the minimum programming granularity of the flash memory. Then, the current target erase unit is written according to the minimum programming granularity of the flash memory until all target bytes are reconstructed. S4. Read back the reconstructed current target erase unit and calculate the target page digest; after the target page digest is consistent with the target content digest, form a page commit record in the transaction record area that binds the update identifier, target address and target content digest; only when the page commit record passes the verification and the target page digest read again is still consistent with the target content digest, release the current page snapshot in the swap area and start processing the next target erase unit.

[0008] More specifically, the page update information is carried by a page descriptor, which also includes an instruction stream digest, an instruction stream length, and a target erase unit capacity. For a target erase unit with completely identical old and new content, reconstruction is skipped only if the actual digest of the erase unit read matches the target content digest, and the erase unit is included in the verification scope of the target image digest.

[0009] More specifically, when forming the backup valid record and page commit record, the record payload is first written into a new slot in the transaction record area and the payload check value is verified. Then, the commit identifier is written into the flash minimum programming granularity independent of the record payload. Only records whose payload check value, commit identifier, record sequence number and previous valid record summary all pass the verification are recognized as valid records.

[0010] More specifically, in response to a reset during the update process, the bootstrap scans the transaction record area and reads the swap area and the current target erase unit: when no valid backup record is formed and the actual digest of the current target erase unit read matches the old content digest, the swap area is erased again, the complete old content of the current target erase unit is copied to the swap area, a snapshot digest is calculated, and after the snapshot digest matches the old content digest, a valid backup record is re-formed in the transaction record area; when the backup record is valid, the page commit record is invalid, and the snapshot digest matches the old content digest, the current target erase unit is erased again, and the full page reconstruction is re-executed from the starting point of the instruction stream in step S1; when the actual digest of the current target erase unit matches the target content digest, a page commit record is written or confirmed in a new slot; when both the snapshot digest and the actual digest of the current target erase unit fail the corresponding verification, the application startup is blocked and a request is made to recover data that can reconstruct all target bytes of the current target erase unit.

[0011] More specifically, the single-bank flash memory also includes a startup control area. Before processing the first target erase unit, an update activity record bound to the update identifier is formed in the transaction record area. The target image identifier, target image digest, and target version value are obtained from the update list. After all page commit records of the target erase units are valid, the application area is read to calculate the current image digest. When the current image digest matches the target image digest, a startup authorization record bound to the update identifier, target image identifier, target image digest, target version value, and authorization sequence number is formed in the startup control area. Before each application startup, from the startup authorization records where the payload verification, commit identifier, and record chain have all passed verification, the record with the highest target version value and the largest authorization sequence number within that target version is selected. The application startup is allowed only when the selected record has the same update identifier as the update activity record and the target image digest in the selected record matches the current image digest.

[0012] More specifically, the update data described in step S1 is persistently stored on the device side, or authenticated and retransmitted by the update server based on the update identifier, target address, and instruction offset; when using authentication and retransmission, the bootstrap program does not confirm the completion of the current page transaction to the update server before the page submission record is valid.

[0013] More specifically, during the erasure or programming operation of the single-bank flash memory, the flash access routine, its call relationship code, constants, stack, and exception handling code are pre-deployed in random access memory and executed from the random access memory, or the in-application programming routine inside the chip's read-only memory is called; when executing from random access memory, the total capacity occupied by the output buffer, instruction parsing state, digest calculation state, communication state, flash access routine, and its execution stack does not exceed the available random access memory capacity of the microcontroller.

[0014] More specifically, the page update information mentioned in step S1 belongs to an update list with a digital signature. The update list also includes a base image identifier, a target image identifier, a target version value, and an allowed target address range. Before forming a valid backup record, the bootstrap program verifies the digital signature, the base image identifier, the target version value, and the target address range, and excludes the erase unit where runtime variable data is located from the differential update range or uses independent data migration transaction processing.

[0015] A computer device includes a memory and a processor, the memory storing a computer program, characterized in that the processor, when executing the computer program, implements the above-described page transaction differential firmware update method for single-bank flash memory.

[0016] The beneficial effects of this invention are: without saving a second complete application image and when the random access memory cannot accommodate a complete target page, it is still possible to retain a complete and verifiable old page data source before erasing the target erasure unit, and to prevent the data source from being reclaimed until the target page passes verification. Since both the erase permission and the swap area snapshot release permission depend on both rewritable flash memory physical content and persistent transaction records bound to update identifiers, the recovery starting point for the current page can be re-determined after a reset, eliminating the need to guess the continuation position on the sparse page. Attached Figure Description

[0017] Figure 1 This is a flowchart of the page transaction differential firmware update method for single-bank flash memory according to the present invention; Figure 2 This is a schematic diagram of the system composition and single-bank flash memory partition of an embodiment of the present invention; Figure 3 This is a schematic diagram of the current page snapshot and copy / literal streaming data path reconstruction according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the append-only transaction record structure and page transaction security boundary according to an embodiment of the present invention; Figure 5 This is a flowchart illustrating the joint state recovery process after reset according to an embodiment of the present invention. Figure 6This is a flowchart of the full image verification and startup authorization process according to an embodiment of the present invention.

[0018] In the diagram: 100, Update Server; 110, Page Difference Generator; 120, Update Data Service Module; 200, Microcontroller; 210, Processor; 220, Random Access Memory; 230, Single Bank Flash Memory; 231, Protected Boot Sector; 232, Application Sector; 233, Exchange Sector; 234, Transaction Record Sector; 235, Boot Control Sector. Detailed Implementation

[0019] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] like Figure 2 As shown, the following explanation uses a microcontroller 200 with only one application image bank receiving and installing a differential firmware update as an example. After reset, the processor 210 prioritizes executing the boot program in the protected boot area 231; during the update, the microcontroller 200 does not have a second independent application bank that can completely store the target application image and switch between it and the current application image. The capacity, digest algorithm, communication link, and record codewords described below are determined based on the specific device selection and no fixed parameters are imposed on the devices.

[0021] The following explains how each physical fact generates the next permission, in the actual order of a normal update.

[0022] Before this update begins, the single-bank flash memory 230 of the microcontroller 200 has been divided into a protected boot area 231, an application area 232, a swap area 233, a transaction record area 234, and a boot control area 235 according to the physical erase boundaries. The protected boot area 231 stores the reset entry, boot program, and boot gate. The data capacity of the swap area 233 is not less than the largest target erase unit in the application area 232. The swap area 233, transaction record area 234, and boot control area 235 will not be simultaneously affected by a single erase operation targeting the erase unit. When a page transaction begins, this partition layout is observable, so even if unknown content subsequently appears in the application area 232, the reset entry, current page snapshot, and persistent record can still be read separately. Each subsequent destructive action must simultaneously acquire the corresponding physical content and valid record; if either is missing, the subsequent processing flow is not allowed to proceed. The page transaction differential firmware update method of this invention is as follows: Figure 1 As shown, it includes the following steps: S1. The update server 100 first obtains the base image and the target image to be installed corresponding to the current firmware of the microcontroller 200. The page difference generator 110 generates page descriptors and ordered instruction streams for each target erase unit to be updated based on the differences between the base image and the target image. The update package explicitly contains update identifier, base image identifier, target image identifier, target image digest, target version value, as well as the address, capacity, old content digest, target content digest, instruction stream digest and instruction stream length of each target erase unit.

[0023] After the microcontroller 200 is powered on or reset, it first enters the boot program in the protected boot area 231. The boot program scans all the used slots in the transaction record area 234 and the startup control area 235, checks the record payload, independent write-after commit flag and front-end / back-end chain relationship, and reads the application area 232 to calculate the current image digest. If there is no ongoing update and there is a valid startup authorization consistent with the current image, the boot program can start the application according to the existing authorization. In this embodiment, after a new update request is detected, the boot program keeps the startup gate closed and obtains the update package provided by the update server 100 or persistently stored on the device side.

[0024] At this point, application area 232 has not yet been corrupted by this update. The bootloader first verifies the integrity or signature of the update package, checks the product and base image identifier, target address range, target version, transaction record slot budget, and the availability of update data after reset, and reads application area 232 to check the summaries of each old content used as the differential base. If all checks pass, it only means that the update can be prepared, but does not yet grant permission to modify application area 232. If any check fails, the bootloader maintains the original persistent state and the startup block, terminating the update preparation.

[0025] After the above preparation and verification are passed, the bootloader writes an update activity record bound to the update identifier in a new slot in transaction record area 234. The bootloader first writes the record payload and performs readback verification, then writes the commit identifier in the smallest flash programming granularity independent of the payload, and performs readback verification again. Only when the payload verification result, the commit identifier, and the record chain are all valid is the record determined to be a valid update activity record. The above writing operation is the first flash persistent state change that occurs in this update process. This valid update activity record can be used by the bootloader to identify the currently ongoing update activity at each reset, and continuously block the application from starting if a matching start authorization is not obtained. Therefore, the target page processing stage can only be entered after a valid update activity record is determined to be obtained.

[0026] S2. The bootloader selects the first target erase unit according to the page order in the update package. When selecting the first target erase unit, it still retains the complete old content, the swap area 233 has not yet acquired a snapshot of the current page, and there is no valid backup record of the current page in the transaction record chain. The bootloader reads the target erase unit and calculates the actual digest. Only when the actual digest is equal to the old content digest provided by the page descriptor is the first target erase unit determined as a qualified old page for this differential update. If the actual digest is already equal to the target content digest, the bootloader checks the preceding records and then proceeds to page commit processing. If the actual digest is neither equal to the old content digest nor equal to the target content digest, the application startup blocking state is maintained and the controlled recovery process is entered.

[0027] After confirming that the first target erase unit is a qualified old page, the bootloader first performs an erase operation on the swap area 233, and then copies all the old content of the first target erase unit to the swap area 233 in segments according to the read and write length allowed by the device. The amount of data copied is equal to the full capacity of the first target erase unit. During the copying process, the first target erase unit remains in an un-erased state and does not advance the transaction record chain. After the copying is completed, the bootloader reads back the data in the swap area 233 completely and calculates the actual digest. Only when the actual digest of the swap area 233 is equal to the old content digest of the page, and the binding relationship between the update identifier corresponding to the data in the swap area 233 and the target address of the first target erase unit is verified, is the data in the swap area 233 recognized as the differential source data of the current page.

[0028] like Figure 4 As shown, after the snapshot verification is successful, the bootloader writes a valid backup record to a new slot in the transaction record area 234. The operation of writing the valid backup record adopts the method of first writing the payload, reading back the verification, and then writing the commit identifier at the independent flash minimum programming granularity. The payload of the valid backup record is bound to the update identifier, the target address, the old content summary, and the target content summary. After the writing is completed, the bootloader performs a validity verification on the valid backup record. The verified snapshot data in the exchange area 233 is the content data, and the valid backup record that has passed the verification is the status data. The bootloader only allows the first target erase unit to be erased when the page update information associated with the content data and the status data matches each other.

[0029] After the bootloader reads back and confirms the validity of the backup record, it sends a command to the flash controller to erase the first target erase unit and waits for the erase operation to complete. The erase operation itself does not generate a new flash persistent transaction state. During the period when the first target erase unit may be in an erased, partially erased, or unknown state, the verified snapshot data in the swap area 233 remains unchanged, and the backup record maintains the binding relationship between the snapshot and the update identifier and the target address. Since the old content required for the copy operation can still be recovered from the independently configured swap area 233, the bootloader can then start the target content reconstruction.

[0030] S3, such as Figure 3 As shown, after erasure is completed, the instruction parser parses the instruction stream of this page in ascending order of target address; the copy instruction reads the specified segment only from the verified current page snapshot in swap area 233; the literal instruction reads the corresponding segment from the update data available in this update session; the data segments read by the two types of instructions together cover all the target bytes of the first target erasure unit; the operation on the erased address will not be skipped based on the marker that the region in the update packet has not changed.

[0031] The data output by the instruction is first sent to the output buffer; the capacity of the output buffer is not less than the minimum programming granularity of the flash memory and is less than the capacity of the first target erase unit; the digest state stores the current snapshot of the swap area 233 and the intermediate state required for segmented digest calculation of the target page; when the data accumulated in the output buffer reaches one or more complete programming granularities, the flash memory access executor performs programming operations on the first target erase unit in the order of the target address; during this programming stage, the persistent transaction records effective on the flash memory are still backup valid records; the bootloader does not perform reuse or reclamation operations on the swap area 233; only after the entire page of data is output and the readback verification passes can a new transaction boundary state representing the completion of the page update be generated.

[0032] S4. After all target bytes of the first target erase unit have been written, the bootloader waits for the flash controller to enter an idle state, checks for error states, and processes the cache or prefetch according to device requirements. Then, it reads back the first target erase unit completely and calculates the actual digest. If the actual digest is inconsistent with the target content digest in the page descriptor, the bootloader does not use the residual content in the first target erase unit to resume writing from the breakpoint, nor does it advance the persistent transaction record on the flash side. The bootloader retains a snapshot of swap area 233, re-executes the erase for the entire first target erase unit, and replays the execution from the beginning of the current page instruction stream. If the actual digest is equal to the target content digest, the physical content of the page in the first target erase unit reaches the committable state, and the bootloader can then write the page commit record.

[0033] After successful readback verification, the bootstrap program writes a page commit record to a new slot in transaction record area 234. First, it writes the payload and reads it back for verification. Then, it writes the commit identifier at the smallest programming granularity of the flash memory, independent of the payload. After writing and verification, a valid page commit record is obtained. This page commit record is bound to an update identifier, a target address, and a target content digest. At this point, the target page with the target content digest is considered first-type evidence, and the valid page commit record is considered second-type evidence. Only when the update identifier and target address associated with the first-type evidence and the second-type evidence match are the page transaction considered complete. Only then can the bootstrap program obtain the release condition for swap area 233 and proceed to the next page's processing flow.

[0034] The bootloader then selects the next target erase unit to be updated and executes the complete processing flow in a loop: old content verification, generating a complete snapshot backup, obtaining erase permission based on valid backup records, executing the target erase unit erase, streaming reconstruction of the target content, read-back verification, and writing the page commit record. For target erase units where the old and new content are completely identical, the update package still needs to provide the target digest corresponding to the unit, or include the unit in the verification coverage of the image digest. The bootloader only allows skipping the reconstruction process when the physical digest obtained from the reread matches the target digest, and cannot skip processing directly based solely on the unchanged content marker carried by the update package. Thus, after each page is processed, the persistent transaction record stored in the flash memory and the actual digest of that page together serve as the verification basis for allowing the next page to be processed.

[0035] like Figure 6 As shown, when all target erase units listed in the update package have valid page commit records, and the target content digest bound to each page commit record passes the verification, the bootloader reads all data from the entire application area 232, or the complete image range specified by the update package, recalculates the current image digest, and compares it with the target image identifier and target image digest carried in the update package. The completion of page commits for all target erase units is only used to initiate the full image verification process and does not directly remove the boot block to allow system startup. If the full image verification fails, the bootloader maintains the incomplete transaction state of this update, keeps the boot block in effect, and does not generate new boot authorization records.

[0036] After the full image verification is successful, the bootloader can write a boot authorization record to the new erase slot in the boot control area 235. The payload of the boot authorization record includes an update identifier, a target image identifier, a target image digest, a target version value, a monotonically increasing authorization sequence number, and a link to the previous valid boot authorization record. The bootloader first writes the payload and reads it back for verification, then writes the boot authorization commit identifier at the smallest programming granularity of the flash memory, independent of the payload, and reads it back for verification again. After the payload, commit identifier, and authorization chain are all verified, a valid boot authorization record is obtained. The current application area 232 with the target image digest is the first type of evidence, and the verified valid boot authorization record is the second type of evidence. Only when the update identifiers of both the first and second types of evidence are consistent with the update identifier of the current update activity record can the candidate condition for lifting the boot blockade be met.

[0037] During the startup determination phase following this update, the bootloader rescans the transaction record chain and startup authorization chain. On the valid authorization chain, it selects a valid startup authorization record based on the target version value and authorization sequence number. Then, it reads application area 232 and verifies the current image identifier against the actual digest. Only if the update identifier bound to the selected startup authorization record matches a valid update activity record is the bootloader allowed to jump to the application entry point. Simultaneously, the target image identifier and target image digest bound to this startup authorization record must match the actual information in the current application area 232, and there must be no update activity record where the version has been updated but authorization has not yet been completed. Thus, the success of this update is jointly confirmed by the current physical image and a valid startup authorization. The cleanup of swap area 233 and the recycling of ordinary logs can be postponed and do not affect the startup permission determination.

[0038] In the above normal path, the execution entity is always the bootstrap program that has priority to obtain execution rights after reset; the update activity record first closes the startup release path of the update destruction phase; then, the actual summary of the swap area 233 and the backup valid record together form the erasure condition, the actual summary of the target page and the page commit record together form the snapshot release and next page processing condition, and the actual summary of the current image and the startup authorization record together form the application startup release condition.

[0039] like Figure 5 As shown, the aforementioned correspondence verification relationship between the physical content of the flash memory medium and the persistent transaction records is also applied to the power failure recovery process; the bootloader does not speculate on which instruction was executed before the power failure; after the reset is completed, the bootloader rereads the valid transaction records in the flash memory, the actual summary of the swap area 233, and the actual summary of the current target erase unit, and performs full page redo, confirms page commit, or maintains the boot blocking based on the verification results.

[0040] After a power outage, when the microcontroller 200 is powered on again, it will still prioritize entering the protected boot area 231. The boot program will use the update list, all used transaction record slots, all used startup authorization slots, the actual summary of the exchange area 233, the actual summary of the current target erase unit, the actual summary of the current application area 232, and the availability status of updated data as inputs for status determination. During slot scanning, the scanning will not stop when the first invalid slot is encountered; for slots with incomplete writes, such as those with failed load verification, incomplete commit identifiers, or illegal chain relationships, they will be ignored and isolated. Therefore, the inputs and validity conditions required for status determination after a reset can be reconstructed after a power-down reset.

[0041] The first typical breakpoint occurs before a complete old page backup is formed; for example, the update activity record has taken effect, but the erasure of swap area 233, old page copying, or snapshot verification has not yet been completed, and there is no valid backup record for this page. After reset, the bootloader detects a valid update activity record, but does not read a valid backup record for this page, and then performs a re-read on the target erase unit; according to the operating rules of this update process, erasing the target page is prohibited before the valid backup record takes effect; the target erase unit retains the old content, but this state must be verified by actually reading the calculated digest after reset. If the verification is normal, the bootloader re-erases swap area 233, copies the complete old page, completes snapshot verification, and writes the generated valid backup record into the new slot; if the target erase unit actually reads the calculated digest, which does not match either the old content digest or the target content digest, then the startup blockade is maintained, and the controlled recovery state is entered, and no erasure operation is performed on the target erase unit.

[0042] The second typical breakpoint occurs after the target erase unit has started erasing or streaming reconstruction, but the page commit record has not yet taken effect. After a reset, the bootloader reads the valid backup record bound to this page, but does not read the valid page commit record, and verifies that the actual digest of swap area 233 is consistent with the old content digest. At this time, the target erase unit may be in an erased state, a tattered page, or present other unknown digests. The bootloader does not locate the power failure interruption point, nor does it continue writing on the tattered page. Instead, it re-erases the entire target erase unit, performs a copy operation based on the same verified snapshot, performs literal operations based on the retrievable updated data, and completes a full replay from the beginning of the instruction stream. Only after reading back and verifying the target digest is a valid page commit record written and generated is the bootloader executed. Throughout the entire recovery process, the valid security verification basis for this page remains the same as the valid backup record.

[0043] The third typical breakpoint occurs when part of the page commit record has been physically written to flash memory, but the bootloader has not yet completed post-write verification. After a reset, when the bootloader scans the slot, it first re-verifies the payload, commit identifier, and record chain of the page commit record, and then reads the target erase unit to check the actual digest. If the record is fully verified and the target page digest matches the target content digest, the bootloader recognizes the page commit record as valid and allows processing to proceed to the next page. If the commit identifier has write defects, but the target page digest is already equal to the target content digest, a valid page commit record is generated in a new slot after verifying the preceding boundary. If the target page digest does not match the target content digest, the backup valid record is still used as the security verification boundary, and a re-erase and full replay recovery process is performed on the entire target erase unit. Therefore, in scenarios where a valid commit occurs but verification is not completed, the unverified page will not be reused.

[0044] The fourth typical breakpoint occurs during a power outage interruption in the programming phase of the boot authorization record's commit identifier. After reset, the bootloader checks that all pages have been committed. For the interrupted boot authorization slot, the boot authorization record is considered valid only if all conditions are met simultaneously: the payload verification is correct, the commit identifier precisely matches the complete codeword, the authorization chain is valid, the version and authorization sequence number meet the selection rules, and the actual digest of the current application area 232 matches the target image digest. If any of the above conditions are not met, the slot is isolated. The bootloader determines that there is a valid update activity record, but there is no valid boot authorization record matching the same update identifier. The bootloader continues to maintain the application boot blocking and re-completes the verification of the complete application image. Only after the full image verification passes is the boot authorization record rewritten in the new erase slot, without overwriting the original stub slot.

[0045] All other power outage locations can be handled uniformly according to the same set of security judgment principles. If the payload has not yet been written, there is no valid new transaction record; if the payload is being written or the payload verification fails, the record is deemed invalid; if the payload verification passes but the commit identifier has not yet been written, the corresponding new state is still not recognized; if the commit identifier is valid but the bootloader has not yet completed software confirmation, the record validity verification and the corresponding physical digest verification will be re-executed during the reset scan. Under each processing branch, the state update is only performed after the two types of evidence reach a new consensus; successful termination is when the current image and the matching boot authorization record simultaneously meet the conditions, allowing a jump to the application entry point; controlled termination is maintaining boot blocking, waiting for data recovery or entering maintenance state.

[0046] The transaction record area 234 and the startup control area 235 can use append-only slots; the transaction record payload may include the record magic number, update identifier, sequence number, record type, target address, old content digest, target content digest, previous record digest, and payload check value; the startup authorization payload may include the record magic number, update identifier, target image identifier and digest, target version value, authorization sequence number, previous authorization digest, and authorization payload check value. The commit identifier may use a single codeword with the smallest programmable granularity of flash memory, a double codeword distributed at different programmable granularities, or other encodings with equivalent write-damped detection capabilities; however, it does not use single-field polymorphism that can be partially rewritten, but is directly used to represent multiple security phases.

[0047] When using a single swap zone 233, the data source for the copy operation is limited to a validated snapshot of the current target erase unit. Cross-page copy operations are only permitted in the following variations: multiple swap units are configured; the base image is persistently stored; or cross-page page dependencies have been verified to be free of circular dependencies, and the source page continues to undergo validity checks while being used as a data source. Furthermore, reused fragments from other old pages must be encoded as literals to prevent updates to the target page from corrupting the data source required by subsequent processes.

[0048] Updated data can be pre-stored persistently in external serial flash memory or a dedicated internal storage area of ​​the microcontroller 200, or it can be retransmitted by the update data service module 120 after a reset, based on the update identifier, target address, and instruction offset. When using the retransmission method to obtain update data, the microcontroller 200 performs authentication or integrity verification on each received segment; and before the corresponding page commit record takes effect, it does not confirm the completion of the page transaction to the update server 100, ensuring that even after the target page is erased, the literal data and instruction stream can still be re-obtained.

[0049] If the device cannot fetch instructions from a bank during a busy erase / write period for that bank, the flash access actuator, necessary call relationship code, constants, stack, and necessary exception handling code can be placed in random access memory 220, or an in-process programming routine in on-chip read-only memory can be called. The random access memory 220 is required to simultaneously cover the output buffer, input segmentation, instruction parser and digest state, communication or authentication workspace, erase / write code and its stack; and handle watchdog timers, interrupts, direct memory access, caching, and prefetching according to device requirements. This solution does not predefine a fixed value for the random access memory 220.

[0050] For devices with different erase sizes, each page descriptor carries the capacity information of the corresponding target erase unit. The capacity of swap area 233 is not less than the maximum capacity among all target erase units. To alleviate concentrated wear in swap area 233, multiple candidate swap units can be configured, selected based on erase count or rotation index. However, candidate swap units carrying the current page snapshot are not allowed to be reclaimed before the page commit record takes effect. Transaction record slots can also adopt a dual-log erase unit or log pool rotation mechanism; however, erasure must not be performed on the only latest valid transaction chain in the active update until the new transaction record chain is reliably established.

[0051] In implementations requiring protection against unauthorized updates, the update package may also carry a digital signature, product identifier, target address whitelist, and monotonically increasing version value; the digest may employ a cryptographic hash algorithm, message authentication code, or a verification algorithm with predetermined error detection capabilities. Configurations, calibration values, counters, and user data that change during runtime should be excluded from the firmware base image; or handled through data migration transactions with independent versions and recovery rules to prevent inconsistencies between the actual old content in flash memory and the base image upon which the differential update depends.

[0052] The power-down recovery mechanism in this embodiment is based on the flash memory behavior specified in the device datasheet: interrupted erase or programming operations may cause uncertainty in the content of the current operating unit, but the device hardware will not be damaged beyond its limits, and the protected boot area 231, independent transaction record unit, and exchange unit will not be tampered with; during implementation, slots need to be reserved according to the number of target pages, the number of security boundary records per page, and the allowable number of retries; the undervoltage reset threshold, power monitoring, energy storage unit, and erase / write endurance characteristics should all meet the device specifications.

[0053] To provide a procedural description of the reset status determination, the update list, the legitimate transaction record chain, the legitimate startup authorization chain, the actual summary of exchange area 233, the actual summary of the current target page, the actual summary of the current application area 232, and the availability of update data can be used as inputs. The status determination first filters valid records based on the commit identifier, payload verification, and chain relationships. Then, it performs pairing verification according to the update identifier, page identifier, and physical summary: If no valid backup record exists, erasing the target page is not allowed; if a valid backup record exists but the summary of exchange area 233 does not match, page reconstruction is not allowed; if a valid backup record exists, no valid page commit record exists, and the target page summary is not equal to the target content summary, a full page erase and replay is performed; if the target page already contains the target content summary, it is written in a new slot, or a valid page commit record is identified and confirmed; even if a valid page commit record exists, the target page physical summary must be verified before the snapshot can be released; after all pages have been committed, a full image verification must be completed and a matching startup authorization record obtained. Status updates, successful termination, and controlled termination are all determined by the above dual-evidence determination logic.

[0054] This invention also provides a computer device, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the page transaction differential firmware update method for single-bank flash memory described in any of the above embodiments.

[0055] This invention can be applied to metering instruments, sensor nodes, controllers, wearable devices, and other resource-constrained embedded devices. The aforementioned execution entity can be implemented through software programs, hardware state machines, or a combination of both. The digest algorithm, communication link, record codewords, and exchange unit selection strategy can all be replaced, but after replacement, under the same update identity, the following causal relationships should still be maintained: the update activation record is destroyed before application area 232; the verified complete old page and the valid backup record are erased before the target page; the verified target page and the valid page commit record are reclaimed before the snapshot; the verified target image and the valid startup authorization record are started before the application.

[0056] It should be emphasized that the above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any way. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention shall still fall within the scope of the technical solution of the present invention.

Claims

1. A page transaction differential firmware update method for single-bank flash memory, characterized in that, The bootloader, which gains execution rights before the application after reset, is executed and stored in a protected boot area; the single-bank flash memory is provided with an application area, a swap area and a transaction record area, and the capacity of the swap area is not less than the capacity of the largest target erase unit in the application area; The page transaction differential firmware update method includes: S1. Obtain page update information and update data for the current target erasure unit to be updated. The page update information includes an update identifier, target address, old content summary, target content summary, and an instruction stream arranged in order of target address. The instruction stream includes a copy instruction to retrieve data from the old content of the current target erasure unit and a literal instruction to retrieve data from the update data. The output of the instruction stream covers all target bytes of the current target erasure unit. S2. Read the current target erasure unit, calculate the actual digest and check it against the old content digest; after the check is successful, copy the complete old content of the current target erasure unit to the exchange area, read the complete old content in the exchange area and calculate the snapshot digest; after the snapshot digest is consistent with the old content digest, form a backup valid record in the transaction record area that binds the update identifier, target address, old content digest and target content digest; under the condition that the backup valid record passes the verification and the snapshot digest is consistent with the old content digest, erase the current target erasure unit; S3. After erasure is completed, the instruction stream is executed in the order of the target address. The copy instruction reads data only from the complete old content in the swap area through digest verification, and the literal instruction reads data from the updated data obtained in step S1. The output of the two types of instructions is sent to the output buffer. The capacity of the output buffer is less than the current target erase unit and not less than the minimum programming granularity of the flash memory. Then, the current target erase unit is written according to the minimum programming granularity of the flash memory until all target bytes are reconstructed. S4. Read back the reconstructed current target erase unit and calculate the target page digest; after the target page digest is consistent with the target content digest, form a page commit record in the transaction record area that binds the update identifier, target address and target content digest; only when the page commit record passes the verification and the target page digest read again is still consistent with the target content digest, release the current page snapshot in the swap area and start processing the next target erase unit.

2. The page transaction differential firmware update method for single-bank flash memory according to claim 1, characterized in that, The page update information is carried by a page descriptor, which also includes an instruction stream digest, instruction stream length, and target erase unit capacity. For a target erase unit with completely identical old and new content, reconstruction is skipped only if the actual digest of the erase unit read matches the target content digest, and the erase unit is included in the verification scope of the target image digest.

3. The page transaction differential firmware update method for single-bank flash memory according to claim 1, characterized in that, When forming the backup valid record and page commit record, first write the record payload to a new slot in the transaction record area and verify the payload check value, then write the commit identifier in the flash minimum programming granularity independent of the record payload; only records whose payload check value, commit identifier, record sequence number and previous valid record summary all pass the verification are recognized as valid records.

4. The page transaction differential firmware update method for single-bank flash memory according to claim 1, characterized in that, In response to a reset during the update process, the bootstrap scans the transaction record area and reads the swap area and the current target erase unit: when no valid backup record is formed and the actual digest of the current target erase unit read matches the old content digest, the swap area is erased again, the complete old content of the current target erase unit is copied to the swap area, a snapshot digest is calculated, and after the snapshot digest matches the old content digest, a valid backup record is re-formed in the transaction record area; when the backup record is valid, the page commit record is invalid, and the snapshot digest matches the old content digest, the current target erase unit is erased again, and the full page reconstruction is re-executed from the starting point of the instruction stream in step S1; when the actual digest of the current target erase unit matches the target content digest, a page commit record is written or confirmed in a new slot; when neither the snapshot digest nor the actual digest of the current target erase unit passes the corresponding verification, the application startup is blocked and a request is made to recover data that can reconstruct all target bytes of the current target erase unit.

5. The page transaction differential firmware update method for single-bank flash memory according to claim 1, characterized in that, The single-bank flash memory also has a startup control area. Before processing the first target erase unit, an update activity record bound to the update identifier is formed in the transaction record area. The target image identifier, target image digest, and target version value are obtained from the update list. After all page submission records of the target erase units are valid, the application area is read to calculate the current image digest. When the current image digest is consistent with the target image digest, a startup authorization record bound to the update identifier, target image identifier, target image digest, target version value, and authorization sequence number is formed in the startup control area. Before each application launch, select the record with the highest target version value and the largest authorization sequence number within that target version from the launch authorization records that have passed the load verification, commit identifier, and record chain verification. Allow the application to launch only if the selected record has the same update identifier as the update activity record and the target image digest in the selected record is consistent with the current image digest.

6. The page transaction differential firmware update method for single-bank flash memory according to claim 1, characterized in that, The update data described in step S1 is persistently stored on the device side, or authenticated and retransmitted by the update server based on the update identifier, target address, and instruction offset. When using authentication and retransmission, the bootstrap program does not confirm the completion of the current page transaction to the update server before the page submission record is valid.

7. The page transaction differential firmware update method for single-bank flash memory according to claim 1, characterized in that, During the erasure or programming operation of the single-bank flash memory, the flash access routines, their call relationship code, constants, stack, and exception handling code are pre-deployed in random access memory and executed from the random access memory, or the in-application programming routines inside the chip's read-only memory are called; when executing from random access memory, the total capacity occupied by the output buffer, instruction parsing state, digest calculation state, communication state, flash access routines and their execution stack does not exceed the available random access memory capacity of the microcontroller.

8. The page transaction differential firmware update method for single-bank flash memory according to claim 1, characterized in that, The page update information mentioned in step S1 belongs to an update list with a digital signature. The update list also includes a base image identifier, a target image identifier, a target version value, and an allowed target address range. Before forming a valid backup record, the bootstrap program verifies the digital signature, the base image identifier, the target version value, and the target address range, and excludes the erase unit where runtime variable data is located from the differential update range or uses independent data migration transaction processing.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the page transaction differential firmware update method for single-bank flash memory as described in any one of claims 1-8.

Images