A method for force updating USIM files

Abstract

This invention provides a method for implementing strong updates of USIM files. It includes setting a strong update area in the USIM card, which has built-in power-off protection. A private tag indicates the number of backups for the strong update file, satisfying the inconsistent update frequency requirements of different files. The creation of a strong update file includes: receiving and parsing a file creation command, determining whether a tag is included; if not, setting UpdateIndex to 0, updating the file header, updating the file content to the file body, modifying parent attributes, and ending file creation; if a tag is included, searching the strong update configuration area, returning the offset index, setting UpdateIndex, updating the strong update configuration area, and updating the file content structure to the strong update area. Within the strong update file area, each file body contains a structure byte Struct_P, which contains a Counter to record the update count. This invention can improve update lifespan, flexibly meet different needs, and improve data reliability and security.

Description

Technical Field

[0001] This invention relates to the field of mobile communication technology, and specifically to a method for implementing strong updates of USIM files. Background Technology

[0002] With the widespread application of USIM cards (Universal Subscriber Identity Module cards) in M2M (machine-to-machine) devices, such as in-vehicle systems, higher demands are being placed on the update frequency of certain files within the USIM card. Particularly in some high-frequency update scenarios, the number of file updates needs to reach 1 million or even more. However, current USIM chips on the market have significant limitations in terms of update lifespan.

[0003] Typical USIM chips have a lifespan of only 100,000 to 200,000 updates. Even industrial-grade USIM chips only reach around 500,000 updates, far from meeting the needs of some high-frequency update applications. Furthermore, different application scenarios and file types have varying requirements for update frequency; some files may require higher update frequencies, while others have lower requirements.

[0004] In the current technological context, the following are the main problems:

[0005] Mixed storage of strong update files and regular files: USIM card FLASH storage is typically updated page-by-page. Because strong update files and regular files are stored together, updating a regular file might accidentally update an area of ​​a strong update file, resulting in the actual number of strong update file updates falling short of expectations. This mixed storage method limits the potential for increasing the update frequency of strong update files.

[0006] Limitations of the ETSI TS102 222 specification: While the current ETSI TS102 222 specification can indicate that a file is a strong update file when it is created, it cannot meet the requirement of different files having different update frequencies. The specification does not provide a mechanism to set different update frequencies for different file types, making it difficult to flexibly respond to the update needs of different files in practical applications.

[0007] Power outage protection zone resource strain: Regular files and forced update files share the power outage protection zone. The power outage protection zone is a special area designed to prevent data loss in abnormal situations such as power outages. As the number of forced update files increases, the power outage protection zone also needs to expand accordingly. When multiple forced update files are used together, the power outage protection zone becomes very large, not only consuming significant storage resources but also increasing the risk of power outage protection zone corruption. Once the power outage protection zone is corrupted, it may lead to data loss or files failing to update properly, severely impacting the reliability and lifespan of the USIM card.

[0008] In summary, current USIM cards have many limitations in file updates, failing to meet the demands of high-frequency update applications. Therefore, it is necessary to develop a new USIM file update method to address these issues and improve the update lifespan and reliability of USIM cards. Summary of the Invention

[0009] To address the shortcomings of existing technologies, this invention provides a method for implementing strong updates of USIM files. This method can improve update lifespan, flexibly meet different needs, and enhance data reliability and security.

[0010] The present invention achieves the above objectives through the following technical solutions:

[0011] A method for forcefully updating a USIM file includes the following steps:

[0012] Set a strong update zone in the USIM card; the strong update zone has a built-in power-off protection function.

[0013] The number of backups for a strong update file is indicated by a private tag to meet the inconsistent update frequency requirements of different files; the creation of the strong update file includes:

[0014] Receive and parse the file creation command, and determine whether it contains a tag:

[0015] If not included, set UpdateIndex to 0, update the file header, update the file content to the file body, modify the parent attribute, and end file creation; if included, search for the strong update configuration area, return the offset index, set UpdateIndex, update the strong update configuration area, and update the file content structure to the strong update area.

[0016] Within the strongly updated file area, each file body contains a structure byte Struct_P, which contains a Counter to record the number of updates.

[0017] According to the present invention, a method for forcefully updating a USIM file is provided, wherein the FLASH memory of the force-updated file is divided into the following areas:

[0018] Power outage protection zone, used as a power outage protection when updating ordinary files;

[0019] The strong update configuration area is used to record the number of backups of strong update files and the number of pages occupied by each strong update file body;

[0020] Strong update region, a page-based region used to cache the file body of strongly updated files;

[0021] The file body is used to store the file content of non-force-updated files, and multiple file bodies are stored contiguously in the storage space.

[0022] The file header records file attributes, including at least file size, access permissions, the starting address of ordinary file content, and whether it is a strongly updated file; the file header and file body are dynamically compressed in storage space to accommodate the needs of file content updates and expansions.

[0023] If it is a strongly updated file, then UpdateIndex is the offset of the strongly updated configuration area; if it is not a strongly updated file, then UpdateIndex is set to 0x00.

[0024] According to the present invention, a method for implementing strong update of USIM files is provided, wherein the strong update configuration area is configured in units of 4 bytes, and each strong update file corresponds to one configuration, specifically including:

[0025] The first byte indicates the number of file bodies created, which is determined by the private tag of the file creation instruction. At the same time, this byte is recorded in the file header as part of the UpdateIndex, which is used to indicate whether the file is a strong update file. If it is not a strong update file, the UpdateIndex in the file header is set to 0.

[0026] The second byte indicates the address of the strong update file body corresponding to this configuration, measured in pages plus the starting address of the strong update file;

[0027] The third byte: indicates the size of this strong update file body plus the page size occupied by the scheme structure bytes Struct_P;

[0028] The fourth byte indicates the total number of pages occupied by this strong update file body, and its size is equal to High_Update_File_Size multiplied by High_Update_Bak_Num.

[0029] According to the present invention, when the file body and its structure byte Struct_P are stored, if the total size is not an integer multiple of the storage page size, the remaining storage space is filled with RFU bytes of all zeros; wherein, the structure byte Struct_P includes Tag, Counter and CRC16 located in the last 8 bytes of the occupied page;

[0030] Among them, Tag is used to check whether the strong update area is normal and is related to power failure protection; Counter is used to record the number of updates, with an initial value of (00000000) when the file is created, and is also used to determine which strong update file body is the latest; CRC16 is used to verify the integrity and correctness of the strong update area.

[0031] Furthermore, the calculation scope of CRC16 specifically covers the file body content, all-zero RFU bytes, Tag, and Counter to ensure the integrity and accuracy of the data in the strong update area.

[0032] According to the present invention, when there are multiple strong update file bodies, the strong update file body with the largest and valid Counter value is determined as the latest strong update file body by comparing the Counter value in the corresponding structure byte Struct_P of each strong update file body.

[0033] According to the USIM file strong update implementation method provided by the present invention, the process of creating the strong update file further includes:

[0034] Search for free blocks in the strong update configuration area. Each block is 4 bytes. If the block content is all FF, the block is determined to be a free block, and the offset index of the free block is returned.

[0035] Based on the value of Tag 91 contained in the instructions for creating the file, generate a configuration value and update the free block found in the strong update configuration area with the configuration value;

[0036] For a strongly updated file, after adding the RFU bytes and Struct_P bytes, the starting address of the file content is determined based on the information in the strongly updated configuration area and the predetermined calculation method.

[0037] The strongly updated file content, which includes the RFU bytes and Struct_P bytes, is then updated into the strongly updated region according to the calculated starting address of the file content.

[0038] According to the present invention, a method for implementing strong updates of a USIM file includes the following steps for reading and writing the strong update file:

[0039] The file is determined to be a strongly updated file based on the value of the UpdateIndex attribute in the file header. If UpdateIndex is 0, it is considered a normal file; if UpdateIndex is not 0, it is considered a strongly updated file.

[0040] For regular files, the address in the file header attributes is used to directly access the starting address of the file body for read and write operations;

[0041] For files that require strong updates, the value of the strong update configuration section and the starting address of the file body content are found based on the UpdateIndex attribute in the file header.

[0042] Based on the first byte High_Update_Bak_Num in the strong update configuration area, determine the total number of backup files for this file; and find the valid record by checking the Tag, CRC and RFU bytes, and read the corresponding Counter byte, where the largest Counter byte is the latest valid record;

[0043] When performing a read operation, the content is read directly from the valid record found and returned.

[0044] According to the USIM file strong update implementation method provided by the present invention, when performing a write operation, it further includes:

[0045] Copy the valid records to RAM;

[0046] Modify the content to be modified in RAM;

[0047] Increment the Counter value by 1;

[0048] Recalculate the CRC of the modified content and write it back to the corresponding location in RAM;

[0049] Find the oldest record to write to FLASH.

[0050] According to the present invention, a method for strong updating of a USIM file is provided, which includes finding the oldest record, comprising:

[0051] If this is the first time a strong update operation is performed on the file, the next address is selected as the update target address. This address is calculated based on the file content, RFU bytes, and Struct_P bytes, and the storage space corresponding to this address contains all FF bytes.

[0052] If no storage space containing all records in the strong update area is found, it means that the strong update area of ​​this file has been used repeatedly. At this time, continue searching and select the oldest record that is not all records in the strong update area, contains other content, but does not meet the Tag and CRC check rules, as the oldest record to be written.

[0053] If neither of the above two situations occurs, the record with the smallest Counter value is selected as the oldest record and written by comparing the Counter values ​​in each record.

[0054] According to the USIM file strong update implementation method provided by the present invention, each strong update file is stored independently, that is, each strong update file has its own exclusive storage area and is not stored together with any other files.

[0055] Therefore, compared with the prior art, the present invention has the following beneficial effects:

[0056] This invention adds a strong update zone with built-in power-off protection, eliminating the need for additional power-off protection resources used by regular files. This effectively prevents the power-off protection zone from prematurely reaching its erase / write lifespan due to frequent updates, thus significantly extending the overall update lifespan of the USIM card. The strong update zone design allows frequently updated files to have a longer lifespan, meeting the needs of high-frequency update applications such as M2M devices, extending the USIM card's lifespan, and reducing replacement costs.

[0057] This invention adds a private tag when creating a USIM file to indicate the number of backup files. This allows different files to have different backup numbers based on their actual update needs, thus meeting the varying requirements for update frequency among different files. For example, some critical files may require more frequent updates, and this invention, by increasing the number of backups, ensures that these files maintain data integrity and reliability even with high-frequency updates.

[0058] This invention stores strong update files and ordinary files independently, avoiding the problem of inaccurate erase / write lifespan caused by mixed storage. Each strong update file has independent storage space and update count, making the calculation of erase / write lifespan more accurate. This accuracy not only improves the efficiency of USIM card usage, but also provides users with more reliable data storage and update protection.

[0059] This invention introduces a Counter mechanism to accurately record the update count of each strongly updated file. This not only provides users with a file update history but also helps them monitor the file update status, ensuring data integrity and consistency. During the data update process, the incrementing of Counter and the verification of the checksum (CRC16) together constitute a data integrity guarantee mechanism, effectively preventing data loss or corruption during the update process.

[0060] In summary, the USIM file strong update method proposed in this invention significantly improves the update lifespan of the USIM card, flexibly meets the update needs of different files, improves the accuracy of data erasure lifespan, and accurately tracks the number of file updates through innovative designs such as adding a strong update area and introducing a private tag and counter mechanism, thus ensuring the integrity and reliability of the data.

[0061] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0062] Figure 1 This is a FLASH partitioning diagram of the file for strong update in an embodiment of the USIM file strong update method of the present invention.

[0063] Figure 2 This is a schematic diagram of the configuration of the UpdateIndex attribute in the file header in an embodiment of a method for strong updating of a USIM file according to the present invention.

[0064] Figure 3 This is a schematic diagram illustrating the structure of the file body size plus the structure bytes Struct_P occupying one page in an embodiment of the USIM file strong update method of the present invention.

[0065] Figure 4 This is a schematic diagram of the structure of the file body size plus the structure bytes Struct_P occupying two pages in an embodiment of the USIM file strong update method of the present invention.

[0066] Figure 5 This is a flowchart illustrating the creation of a strong update file in an embodiment of a USIM file strong update method according to the present invention.

[0067] Figure 6 This is a flowchart illustrating the reading and writing of a strongly updated USIM file in an embodiment of the present invention. Detailed Implementation

[0068] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0069] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0070] See Figures 1 to 5 This embodiment provides a method for forcefully updating a USIM file, which includes the following steps:

[0071] Set a strong update zone in the USIM card; the strong update zone has a built-in power-off protection function.

[0072] The number of backups for a strong update file is indicated by a private tag to meet the inconsistent update frequency requirements of different files; the creation of the strong update file includes:

[0073] Receive and parse the file creation command, and determine whether it contains a tag:

[0074] If not included, set UpdateIndex to 0, update the file header, update the file content to the file body, modify the parent attribute, and end file creation; if included, search for the strong update configuration area, return the offset index, set UpdateIndex, update the strong update configuration area, and update the file content structure to the strong update area.

[0075] Within the strongly updated file area, each file body contains a structure byte Struct_P, which contains a Counter to record the number of updates.

[0076] In this embodiment, as Figure 1 As shown, the FLASH memory for the forced update file is divided into the following areas:

[0077] Power outage protection zone, used as a power outage protection when updating ordinary files.

[0078] The strong update configuration area records the number of strong update file backups and the number of pages occupied by each strong update file body. FLASH chips typically use page erasure, with common page sizes including 512B / 256B. The page size described below refers to 512B. The chip's page erase / write lifespan is 100,000 cycles, and after erasure, the entire chip is left blank (FF).

[0079] Strong update region, a page-based region used to cache the file body of strong update files.

[0080] The file body is used to store the file content of non-force-updated files, and multiple file bodies are stored contiguously in the storage space.

[0081] The file header records file attributes, including at least file size, access permissions, the starting address of ordinary file content, and whether it is a strongly updated file. The file header and file body are dynamically compressed in storage space to accommodate the needs of file content updates and expansions.

[0082] If it is a strongly updated file, then UpdateIndex is the offset of the strongly updated configuration area; if it is not a strongly updated file, then UpdateIndex is set to 0x00.

[0083] In this embodiment, the strong update configuration area is divided into 4-byte units as one configuration, and each strong update file corresponds to one configuration, which specifically includes:

[0084] The first byte (High_Update_Bak_Num): indicates the number of file bodies created, indicated by the private tag (TLV format 9101XX) of the file creation instruction (if 500,000 erase / write cycles are required, the tag is 910105, where 91 indicates the creation of a strong update file and 05 indicates the number of file bodies created); simultaneously, the 4 bytes of the configuration area are recorded in the file header as part of the UpdateIndex (1 byte, e.g., 05000105 is 1, 06050106 is 2), as shown below. Figure 2 As shown, this is used to indicate whether the file is a strong update file. If it is not a strong update file, the UpdateIndex in the file header is set to 0, and the file body content is found based on the UpdateIndex when searching for and updating the file.

[0085] The second byte (High_Update_Bak_Addr) indicates the address of the strong update file body corresponding to this configuration, measured in pages plus the starting address of the strong update file.

[0086] The first strong update file body is located at 0x0001B600, the second strong update file body is located at 0x0001C000 (0x0001B600+0x05*0x200), and the third strong update file body is located at 0x0001CC00 (i.e., 0x0001B600+0x05*0x200+0x06*0x200).

[0087] The third byte (High_Update_File_Size) indicates the size of the strong update file body plus the page size occupied by the Struct_P byte. For example, if the third byte of the first strong update file configuration is 01, it means that it occupies a total of one page. If the third byte of the third strong update file configuration is 02, it means that it occupies a total of two pages.

[0088] The fourth byte (High_Update_File_AllSize): indicates the total number of pages occupied by this strong update file body. The size is equal to High_Update_File_Size multiplied by High_Update_Bak_Num. For example, for the third strong update file, the number of pages occupied by the file body size and +Struct_P size is 0x02, and the number of file backups is 0x05, so the total number of pages occupied is 0x0A.

[0089] In this embodiment, when the file body and its structure byte Struct_P are stored, if the total size is not an integer multiple of the storage page size, the remaining storage space is filled with all-zero RFU bytes; wherein, the structure byte Struct_P includes the Tag, Counter and CRC16 located in the last 8 bytes of the occupied page.

[0090] Tag is used to check whether the strong update area is normal and is related to power failure protection; Counter is used to record the number of updates, with an initial value of (00000000) when the file is created, and is also used to determine which strong update file body is the latest; CRC16 is used to verify the integrity and correctness of the strong update area.

[0091] Furthermore, the calculation scope of CRC16 specifically covers the file body content, all-zero RFU bytes, Tag (A55A), and Counter (4) to ensure the integrity and accuracy of the data in the strong update region.

[0092] When multiple strong update file bodies exist, the latest strong update file body is determined by comparing the Counter value in the corresponding structure byte Struct_P of each strong update file body and identifying the strong update file body with the largest and valid Counter value.

[0093] Specifically, a forced update of the file body size plus the structure bytes (Struct_P) occupying one page is as follows: Figure 3 As shown; a forced update of the file body size + structure bytes, with Struct_P occupying two pages, is as follows. Figure 4 As shown.

[0094] The situation is similar when forcibly updating the file body size plus the structure bytes Struct_P, which occupy multiple pages. If the file body content plus the size of Struct_P is not exactly an integer multiple of the number of pages occupied, there will be remaining RFU bytes, which will be set to all zeros.

[0095] The structure byte Struct_P consists of a Tag (A55A2 bytes) + Counter (4 bytes) + CRC16 (2 bytes), totaling 8 bytes, and is placed in the last 8 bytes of the page it occupies.

[0096] like Figure 5 As shown, the process of creating a strong update file also includes:

[0097] Search for free blocks in the strong update configuration area. Each block is 4 bytes. If the block content is all FF, the block is determined to be a free block, and the offset index of the free block is returned.

[0098] Based on the value of Tag 91 contained in the file creation instructions, generate a configuration value (such as 05000105) and update the free block found in the strong update configuration area with this configuration value.

[0099] Unlike regular files, whose content is directly updated in the file body, for files requiring a strong update, the file content's starting address is determined after adding the RFU and Struct_P bytes, based on information in the strong update configuration area and a predetermined calculation method.

[0100] The strongly updated file content, which includes the RFU bytes and Struct_P bytes, is then updated into the strongly updated region according to the calculated starting address of the file content.

[0101] like Figure 6 As shown, the process of reading and writing a strong update file includes:

[0102] The file is determined to be a strongly updated file based on the value of the UpdateIndex attribute in the file header. If UpdateIndex is 0, it is considered a normal file; if UpdateIndex is not 0, it is considered a strongly updated file.

[0103] For regular files, the address in the file header attributes is used to directly access the starting address of the file body for read and write operations.

[0104] For files requiring a strong update, the value of the strong update configuration section and the starting address of the file body content are found based on the UpdateIndex attribute in the file header.

[0105] Based on the first byte High_Update_Bak_Num in the strong update configuration area, determine how many backup files there are for this file; and find the valid records by checking the Tag, CRC and RFU bytes, and read the corresponding Counter bytes, where the largest Counter byte is the latest valid record (if it is the first read and write after the file is created, there is only one valid record, and the Counter is 00000000).

[0106] When performing a read operation, the content is read directly from the valid record found and returned.

[0107] In this embodiment, when performing a write operation, the following is further included:

[0108] Copy the valid records to RAM;

[0109] Modify the content to be modified in RAM;

[0110] Increment the Counter value by 1;

[0111] Recalculate the CRC of the modified content and write it back to the corresponding location in RAM;

[0112] Find the oldest record to write to FLASH.

[0113] In this embodiment, finding the oldest record includes:

[0114] If this is the first time a strong update operation is performed on the file, the next address is selected as the update target address. This address is calculated based on the file content, RFU bytes, and Struct_P bytes, and the storage space corresponding to this address contains all FF bytes.

[0115] If no storage space containing all records in the strong update area is found, it means that the strong update area of ​​this file has been used repeatedly. At this time, continue searching and select the oldest record that is not all records in the strong update area, contains other content, but does not meet the Tag and CRC check rules, as the oldest record to be written.

[0116] If neither of the above two situations occurs, the record with the smallest Counter value is selected as the oldest record and written by comparing the Counter values ​​in each record.

[0117] Specifically, if the current operation is a read operation, the content is directly read and returned based on the valid record found in the previous step. If the operation is a write operation, the valid record found in the previous step is copied into RAM, the content to be modified is modified in RAM, the CRC is recalculated, and Counter is incremented by 1 and written back to RAM. Then, the oldest record is found and written to FLASH. The method for finding the oldest record is as follows: If it is the first update, the next address (which may be one or more pages, calculated based on file content + RFU bytes and Struct_P bytes) with all FF bytes is the target address for the update. If there is no record with all FF bytes, it means that the strong update area of ​​this file has been cycled through once. The search continues, and the record that is not all FF bytes, has other content, and does not meet the Tag and CRC rules is selected as the oldest record to be written (indicating that a power outage occurred when this record was written). If none of the above situations occur, the record with the smallest Counter is selected as the oldest record to be written.

[0118] In this embodiment, each strong update file is stored independently, that is, each strong update file has its own dedicated storage area and is not stored together with any other files.

[0119] Of course, the above scheme is described with the chip supporting page erase and page write as an example. In reality, the chip also supports page erase and byte write. (Multiple blocks (file content + supplementary alignment bytes + Struct_P bytes) can exist in a page. Chips that support page erase and word write can save a lot of strong update areas.

[0120] In summary, the USIM file strong update method proposed in this embodiment significantly improves the update lifespan of the USIM card, flexibly meets the update needs of different files, improves the accuracy of data erasure lifespan, and accurately tracks the number of file updates by adding a strong update area and introducing a private tag and counter mechanism, thus ensuring the integrity and reliability of the data.

[0121] Furthermore, this embodiment adds a strong update area with built-in power-off protection, eliminating the need to use the power-off protection resources of ordinary files. This effectively avoids the problem of the power-off protection area reaching its erase / write lifespan prematurely due to frequent updates, thus significantly improving the overall update lifespan of the USIM card. The design of the strong update area allows frequently updated files to have a longer lifespan, meeting the needs of high-frequency update applications such as M2M devices, extending the service life of the USIM card, and reducing replacement costs.

[0122] Furthermore, this embodiment adds a private tag when creating a USIM file to indicate the number of backup files. This allows different files to have different backup numbers based on their actual update needs, thus meeting the varying update frequency requirements of different files (e.g., file A updated 500,000 times, file B updated 1.5 million times). For example, some critical files may require more frequent updates, and this embodiment ensures that these files maintain data integrity and reliability even with high-frequency updates by increasing the number of backups.

[0123] Furthermore, this embodiment stores strong update files and ordinary files independently (avoiding strong update files or ordinary files being mixed together), thus avoiding the problem of inaccurate erase / write lifespan caused by mixed storage. Each strong update file has independent storage space and update count, making the calculation of erase / write lifespan more accurate. This accuracy not only improves the usage efficiency of the USIM card, but also provides users with more reliable data storage and update protection.

[0124] Furthermore, this embodiment introduces a Counter mechanism to accurately record the update count of each strongly updated file. This not only provides users with a file update history but also helps them monitor the file update status, ensuring data integrity and consistency. During the data update process, the incrementing of Counter and the verification of the checksum (CRC16) together constitute a data integrity guarantee mechanism, effectively preventing data loss or corruption during the update process.

[0125] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0126] The above embodiments are merely preferred embodiments of the present invention and should not be construed as limiting the scope of protection of the present invention. Any non-substantial changes and substitutions made by those skilled in the art based on the present invention shall fall within the scope of protection claimed by the present invention.

Claims

1. A method for implementing USIM file strong update, characterized in that, Includes the following steps: Set a strong update zone in the USIM card; the strong update zone has a built-in power-off protection function. The number of backups for a strong update file is indicated by a private tag to meet the inconsistent update frequency requirements of different files; the creation of the strong update file includes: Receive and parse the file creation command, and determine whether it contains a tag: If not included, set UpdateIndex to 0, update the file header, update the file content to the file body, modify the parent attribute, and end file creation; if included, search for the strong update configuration area, return the offset index, set UpdateIndex, update the strong update configuration area, and update the file content structure to the strong update area. Within the strongly updated file area, each file body contains a structure byte Struct_P, which contains a Counter to record the number of updates.

2. The method of claim 1, wherein, The FLASH memory for the forced update file is divided into the following areas: Power outage protection zone, used as a power outage protection when updating ordinary files; The strong update configuration area is used to record the number of backups of strong update files and the number of pages occupied by each strong update file body; Strong update region, a page-based region used to cache the file body of strongly updated files; The file body is used to store the file content of non-force-updated files, and multiple file bodies are stored contiguously in the storage space. The file header records file attributes, including at least file size, access permissions, the starting address of ordinary file content, and whether it is a strongly updated file; the file header and file body are dynamically compressed in storage space to accommodate the needs of file content updates and expansions. Where, if it is a strongly updated file, then UpdateIndex is the offset of the strongly updated configuration area; If it is not a forced update of the file, then UpdateIndex is set to 0x00.

3. The method according to claim 2, characterized in that: The strong update configuration area uses 4 bytes as a unit for each configuration, and each strong update file corresponds to one configuration, which specifically includes: The first byte indicates the number of file bodies created, which is determined by the private tag of the file creation instruction. At the same time, this byte is recorded in the file header as part of the UpdateIndex, which is used to indicate whether the file is a strong update file. If it is not a strong update file, the UpdateIndex in the file header is set to 0. The second byte indicates the address of the strong update file body corresponding to this configuration, measured in pages plus the starting address of the strong update file; The third byte: indicates the size of this strong update file body plus the page size occupied by the scheme structure bytes Struct_P; The fourth byte indicates the total number of pages occupied by this strong update file body, and its size is equal to High_Update_File_Size multiplied by High_Update_Bak_Num.

4. The method according to claim 3, characterized in that: When the file body and its structure byte Struct_P are stored, if the total size is not an integer multiple of the storage page size, the remaining storage space is filled with RFU bytes of all zeros; among them, the structure byte Struct_P includes the Tag, Counter and CRC16 located in the last 8 bytes of the occupied page. Among them, Tag is used to check whether the strong update area is normal and is related to power failure protection; Counter is used to record the number of updates, with an initial value of (00000000) when the file is created, and is also used to determine which strong update file body is the latest; CRC16 is used to verify the integrity and correctness of the strong update area. Furthermore, the calculation scope of CRC16 specifically covers the file body content, all-zero RFU bytes, Tag, and Counter to ensure the integrity and accuracy of the data in the strong update area.

5. The method according to claim 4, characterized in that: When multiple strong update file bodies exist, the latest strong update file body is determined by comparing the Counter value in the corresponding structure byte Struct_P of each strong update file body and identifying the strong update file body with the largest and valid Counter value.

6. The method of claim 1, wherein, The process of creating a strong update file also includes: Search for free blocks in the strong update configuration area. Each block is 4 bytes. If the block content is all FF, the block is determined to be a free block, and the offset index of the free block is returned. Based on the value of Tag 91 contained in the instructions for creating the file, generate a configuration value and update the free block found in the strong update configuration area with the configuration value; For a strongly updated file, after adding the RFU bytes and Struct_P bytes, the starting address of the file content is determined based on the information in the strongly updated configuration area and the predetermined calculation method. The strongly updated file content, which includes the RFU bytes and Struct_P bytes, is then updated into the strongly updated region according to the calculated starting address of the file content.

7. The method according to any one of claims 1 to 6, characterized in that, The process of reading and writing strong update files includes: The file is determined to be a strongly updated file based on the value of the UpdateIndex attribute in the file header. If UpdateIndex is 0, it is considered a normal file; if UpdateIndex is not 0, it is considered a strongly updated file. For regular files, the address in the file header attributes is used to directly access the starting address of the file body for read and write operations; For files that require strong updates, the value of the strong update configuration section and the starting address of the file body content are found based on the UpdateIndex attribute in the file header. Based on the first byte High_Update_Bak_Num in the strong update configuration area, determine the total number of backup files for this file; and find the valid record by checking the Tag, CRC and RFU bytes, and read the corresponding Counter byte, where the largest Counter byte is the latest valid record; When performing a read operation, the content is read directly from the valid record found and returned.

8. The method according to claim 7, characterized in that: When performing a write operation, it further includes: Copy the valid records to RAM; Modify the content to be modified in RAM; Increment the Counter value by 1; Recalculate the CRC of the modified content and write it back to the corresponding location in RAM; Find the oldest record to write to FLASH.

9. The method of claim 8, wherein, Find the oldest record, including: If this is the first time a strong update operation is performed on the file, the next address is selected as the update target address. This address is calculated based on the file content, RFU bytes, and Struct_P bytes, and the storage space corresponding to this address contains all FF bytes. If no storage space containing all records in the strong update area is found, it means that the strong update area of ​​this file has been used repeatedly. At this time, continue searching and select the oldest record that is not all records in the strong update area, contains other content, but does not meet the Tag and CRC check rules, as the oldest record to be written. If neither of the above two situations occurs, the record with the smallest Counter value is selected as the oldest record and written by comparing the Counter values ​​in each record.

10. The method according to any one of claims 1 to 6, characterized in that: Each strong update file is stored independently, meaning each strong update file has its own dedicated storage area and is not stored together with any other files.

Images