Controller flash file analysis method, system and computer-readable medium

Abstract

The present invention relates to a parsing method, system and computer-readable medium for a controller flash file, the parsing method comprising: step S1: reading the current data row of the controller flash file; step S2: parsing the data row to obtain a storage address, data and a checksum; step S3: determining whether the checksum is verified to be passed, if so, proceeding to step S4; if not, terminating the parsing task; step S4: determining whether the storage address is continuous with the address of the previous data row, if not, creating a new file and proceeding to step S5; if so, proceeding to step S5; step S5: converting the data into a first format and storing it in the current new file; step S6: determining whether the controller flash file has been read to completion, if not, reading the next data row; if reading is completed, terminating the parsing task. The present invention can expose problems existing in the controller flash file in advance, the flash task will not be interrupted, and the flash task is guaranteed to be successful.

Description

Technical Field

[0001] The present invention mainly relates to the field of file parsing technology, and in particular to a parsing method, system and computer-readable medium for flashing files by a controller. Background Art

[0002] During the update process for an Electronic Control Unit (ECU), the data on the chip needs to be flashed based on the data in a target file with a specific format to manage and upgrade the controller ECU. Common flashing file formats include S19 and HEX. A controller flash file contains a series of strings and may contain multiple, discontinuous addresses.

[0003] Currently, in the process of flashing a controller, a common method is to read a line of data from the controller flash file, parse the data line, and after the content of the data line is verified, flash the corresponding data on the controller and continue to read the next data line in the file. This method of flashing while parsing requires a large amount of computing power resources in the diagnostic instrument that flashes the controller, and it is possible that discontinuous address segments in the file will be parsed halfway through the flashing task, resulting in interruption of the flashing task. In the flashing task, the purpose of the flashing is to completely flash all the data to the controller, rather than partially flashing all the data to the controller. The existing technology cannot expose problems in the controller flashing file in advance during the process of flashing the controller, resulting in frequent interruptions of the controller flashing task and failure of the flashing task. Summary of the Invention

[0004] The technical problem to be solved by this application is to provide a method, system and computer-readable medium for parsing controller flash files, which can expose problems existing in the controller flash files in advance, and will not be interrupted during the execution of the controller flash task, thereby ensuring the success of the flash task.

[0005] The technical solution adopted by the present application to solve the above-mentioned technical problems is a parsing method for a controller flash file, comprising: step S1: reading the current data row of the controller flash file; step S2: parsing the current data row according to the parsing rules to obtain the storage address of the current data row, the data of the current data row and the checksum of the current data row; step S3: judging whether the checksum of the current data row has passed the verification, if the verification has passed, proceeding to step S4; if the verification has not passed, ending the parsing task; step S4: judging whether the storage address of the current data row is continuous with the address of the previous data row, if the addresses are not continuous, creating a new file and proceeding to step S5; if the addresses are continuous, proceeding to step S5; step S5: converting the data of the current data row into data in a first format, and storing the data in the first format to the current new file; step S6: judging whether the reading of the controller flash file has been completed, if not, reading the next data row of the controller flash file and repeating steps S2 to S6; if the reading has been completed, ending the parsing task.

[0006] In an embodiment of the present application, the data in the first format is binary format data.

[0007] In one embodiment of the present application, the step of determining whether the storage address of the current data row is continuous with the address of the previous data row includes: matching the storage address of the current data row with the end address of the previous data row. If the match is inconsistent, it indicates that the addresses are discontinuous; if the match is consistent, it indicates that the addresses are continuous.

[0008] In one embodiment of the present application, the end address of the previous data row is calculated as follows: the storage address of the previous data row plus the data length of the previous data row.

[0009] In one embodiment of the present application, in the step of determining whether the checksum of the current data row passes the checksum, if the checksum fails, the step further includes issuing a first alarm and indicating the row number of the current data row.

[0010] In one embodiment of the present application, the step of determining whether the checksum of the current data row has passed the verification includes: matching the checksum Checksum1 of the current data row with the calculated checksum Checksum2. If the match is successful, it indicates that the verification has passed; if the match is unsuccessful, it indicates that the verification has failed.

[0011] In one embodiment of the present application, the controller flashes an S19 file. After parsing the current data row according to the parsing rule, the controller further includes obtaining the record type and the record length of the current data row; and calculating the checksum Checksum2 according to the following formula:

[0012] Checksum2=0xFF–(Count+Address+Data)

[0013] Among them, Count is the record length of the current data row, Address is the storage address of the current data row, and Data is the data of the current data row.

[0014] In one embodiment of the present application, the controller flashes a HEX file. After parsing the current data row according to the parsing rule, the controller further includes obtaining the record type and record length of the current data row; and calculating the checksum Checksum2 according to the following formula:

[0015] Checksum2=0xFF–(Length+Load offset+Record type+Data)

[0016] Among them, Length is the record length of the current data row, Load offset is the storage address of the current data row, Record type is the record type of the current data row, and Data is the data of the current data row.

[0017] In order to solve the above technical problems, the present application also proposes a controller flash file parsing system, including: a memory for storing instructions executable by a processor; a processor for executing instructions to implement the above controller flash file parsing method.

[0018] In order to solve the above technical problems, the present application also proposes a computer-readable medium storing computer program code, which implements the above controller flash file parsing method when executed by a processor.

[0019] The technical solution of the present application uniformly parses the controller flash file before officially starting to flash the controller, reads and parses each data row of the file line by line, and if a data row fails to parse or the checksum verification fails, the current parsing task will be terminated, which can expose the problem of incorrect parsing or verification in the controller flash file before flashing the controller; by judging whether the data storage addresses of adjacent data rows are continuous, a new file is created if the addresses are not continuous, and the data content in the data rows with continuous storage addresses is first converted into data in the first format, and then stored in the new file. This setting can expose the problem of discontinuous storage addresses in the controller flash file before flashing the controller and solve the problem in time. Subsequently, during the formal execution of the controller flash task, the data in each pre-processed file is read, the flashing process will not be interrupted, and the success of the flashing task is guaranteed. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to make the above-mentioned objects, features and advantages of the present application more clearly understood, the specific embodiments of the present application are described in detail below with reference to the accompanying drawings, wherein:

[0021] Figure 1 is an exemplary flow chart of a method for parsing a controller flash file according to an embodiment of the present application;

[0022] Figure 2 This is an exemplary flow chart of a method for parsing a controller flash file S19 according to an embodiment of the present application;

[0023] Figure 3 This is an exemplary flow chart of a method for parsing a HEX file of a controller flashing according to an embodiment of the present application;

[0024] Figure 4 This is a system block diagram of a controller flash file analysis system according to an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to make the above-mentioned objectives, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are described in detail below with reference to the accompanying drawings.

[0026] In the following description, many specific details are set forth to facilitate a full understanding of the present application. However, the present application may also be implemented in other ways different from those described herein. Therefore, the present application is not limited to the specific embodiments disclosed below.

[0027] As used in this application and the claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" are not intended to refer to the singular but may include the plural. Generally speaking, the terms "comprises" and "include" only indicate the inclusion of the steps and elements specifically identified, and these steps and elements do not constitute an exclusive list. A method or apparatus may also include other steps or elements.

[0028] Flowcharts are used in this application to illustrate the operations performed by systems according to embodiments of the present application. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, the various steps may be processed in reverse order or simultaneously. Furthermore, other operations may be added to these processes, or one or more operations may be removed from these processes.

[0029] This application proposes a controller flash file parsing method, which can be used to uniformly parse controller flash files in advance during controller management and upgrade processes. The controller flash file formats used for flashing are, for example, S19 and HEX.

[0030] Figure 1 This is an exemplary flow chart of a method for analyzing a controller flash file according to an embodiment of the present application. Figure 1 As shown, the parsing method of the controller flash file of this embodiment includes the following steps:

[0031] Step S1: Read the current data row of the controller flash file.

[0032] Step S2: Parse the current data row according to the parsing rules to obtain the storage address of the current data row, the data of the current data row, and the checksum of the current data row.

[0033] Step S3: Determine whether the checksum of the current data row passes the checksum verification. If the checksum passes, proceed to step S4; if the checksum fails, end the parsing task.

[0034] Step S4: Determine whether the storage address of the current data row is continuous with the address of the previous data row. If the addresses are not continuous, create a new file and proceed to step S5; if the addresses are continuous, proceed to step S5.

[0035] Step S5: Convert the data in the current data row into data in a first format, and store the data in the first format in the current new file.

[0036] Step S6: Determine whether the controller flash file has been read completely. If not, read the next data row of the controller flash file and repeat steps S2 to S6. If the reading is complete, end the parsing task.

[0037] For example, the controller flash files of this application include S19 files and HEX files. This application does not limit the type of controller flash files. The following first introduces the file format, file parsing rules, etc. of the S19 file and HEX file of this application by example. Steps S1 to S6 described above will be described in detail later.

[0038] (1) Controller flash file S19.

[0039] For example, the data structure of the S19 file of the present application is shown in Table 1 below; the meaning of the record type Type in the S19 file is shown in Table 2 below; the content of the S19 file in one embodiment is shown in Table 3 below.

[0040] Table 1 Data structure of S19 file

[0041]

[0042] For example, referring to Table 1, the meaning of the current row data and the segmentation position of the data can be determined according to the record type Type to correctly parse the data; the record length Count represents the number of bytes remaining in the current row record, which is the sum of the three bytes of the storage address Address, data Data and checksum Checksum; the storage address Address indicates the starting address of the controller memory where the data in the current row record data area should be downloaded; the data Data indicates that the current segment content is the data that needs to be downloaded to the controller; the checksum Checksum indicates that the current segment stores the check data of the current row record.

[0043] Table 2 Meaning of record type Type in S19 file

[0044]

[0045]

[0046] Table 3 Contents of S19 file in one embodiment

[0047]

[0048] Exemplarily, referring to Table 3, the data rows in the S19 file are read and parsed line by line. The record type Type of the first row is S0, indicating the start of the file, and no valid data can be skipped. The record type Type of the second row is S2, the record length Count is 24, the storage address Address is 100000, the data Data is FFFFFF..., the checksum Checksum is EB, the starting address of the current data row is 0x100000, and the end address of the current data row is the starting address plus the length of the data Data, that is, 0x100020. The record type Type of the third row is S2, the record length Count is 24, the storage address Address is 100020, the data Data is FFFFFF..., the checksum Checksum is CB, the starting address of the current data row is 0x100020, and the end address of the current data row is 0x100040. Since the starting address 0x100020 of the third row is the same as the ending address 0x100020 of the second row, the addresses of the third row and the second row are continuous.

[0049] Continuing with Table 3, the record type in row 18 is S2, the record length is 24, the storage address is 200000, the data is FFFFFF..., the checksum is EB, and the starting address of the current data row is 0x200000. Because the starting address 0x200000 of row 18 is different from the ending address of row 17, the addresses of rows 17 and 18 are discontinuous. The record type in row 34 is S8, indicating the end of the file.

[0050] (2) Controller flash file HEX file.

[0051] For example, the data structure of the HEX file of the present application is shown in Table 4 below; the meaning of the record type Recordtype in the HEX file is shown in Table 5 below; the content of the HEX file in one embodiment is shown in Table 6 below.

[0052] Table 4 Data structure of HEX file

[0053]

[0054] For example, referring to Table 4, the record length Length represents the number of bytes remaining in the current row record, that is, the length of the data; the storage address Load offset represents the offset address, and the starting address of the data in the current row record data area that should be downloaded to the controller memory can be calculated based on the extended linear address and the offset address; the meaning of the current row data and the segmentation position of the data can be determined based on the record type Record type to correctly parse the data; the data Data indicates that the content of the current segment is the data that needs to be downloaded to the controller; the checksum Checksum indicates that the current segment stores the check data of the current row record.

[0055] Table 5 Meaning of record type in HEX file

[0056]

[0057] Table 6 Contents of HEX file in one embodiment

[0058]

[0059]

[0060] For example, referring to Table 6, the data rows in the HEX file are read and parsed line by line. The record type of the first row is 04, indicating that the subsequent A001 is an extended linear address. The storage address (offset address) Loadoffset of the second row is 0000, the record type is 00, the data is 000101A0001F00009A..., and the checksum is C0. According to the extended linear address and the offset address, the starting address of the current data row is calculated to be 0xA0010000, and the ending address of the current data row is the starting address plus the length of the data, that is, 0xA0010020. The storage address (offset address) of row 3 is Load offset 0020, the record type is 00, the data is FFFFFFFFFFFFFFFFFFFFFF…, and the checksum is E0. Based on the extended linear address and offset address, the starting address of the current data row is calculated to be 0xA0010020, and the ending address of the current data row is 0xA0010040. Since the starting address of row 3, 0xA0010020, is the same as the ending address of row 2, 0xA0010020, the addresses of row 3 and row 2 are continuous.

[0061] Continuing with Table 6, the load offset for row 11 is 0260, and the record type is 00. Based on the extended linear address and offset address, the starting address of the current data row is calculated to be 0xA0010260, and the ending address of the current data row is 0xA0010280. Because the starting address of row 11, 0xA0010260, is different from the ending address of row 10, the addresses of rows 10 and 11 are discontinuous. The record type for row 20 is 01, indicating the end of the file.

[0062] The following describes the steps S1 to S6 in detail in conjunction with the contents of Tables 1 to 6:

[0063] In step S1, the current data row of the controller flash file is read. In step S2, the current data row is parsed according to the parsing rules to obtain the storage address of the current data row, the data of the current data row, and the checksum of the current data row. For example, referring to Table 1, if the controller flash file is an S19 file, the storage address Address, data Data, and checksum Checksum are obtained after parsing the data row; referring to Table 4, if the controller flash file is a HEX file, the storage address Load offset, data Data, and checksum Checksum are obtained after parsing the data row, where the storage address Load offset is also the offset address. For example, in the process of parsing the data row, if the parsing of a data row fails, the current parsing task will be terminated, and the problem of incorrect parsing in the controller flash file can be exposed before the controller is flashed.

[0064] In some embodiments, the controller writes an S19 file. After parsing the current data row according to the parsing rules, the controller further includes obtaining the record type and record length of the current data row. For example, referring to Table 1, the record type Type and record length Count are obtained after parsing the data row of the S19 file.

[0065] In some embodiments, the controller writes a HEX file. After parsing the current data row according to the parsing rules, the controller further includes obtaining the record type and record length of the current data row. For example, referring to Table 4, after parsing the data row of the HEX file, the record type and record length are obtained.

[0066] In step S3, determine whether the checksum of the current data row has passed the verification. If the verification has passed, proceed to step S4; if the verification has not passed, terminate the parsing task. For example, referring to Table 3, the second row in the S19 file is also the first data row in the S19 file, so when the checksum of the data row passes the verification, a new file will be created and the data of the row will be converted into binary format and saved in the new file. For example, in this application, if the checksum of a data row fails the verification, the current parsing task will be terminated, and the problem of incorrect verification in the controller flash file can be exposed before the controller is flashed.

[0067] In some embodiments, in the step of determining whether the checksum of the current data row has passed verification, if the checksum fails, the step also includes issuing a first alarm and indicating the row number of the current data row. For example, this configuration of the present application allows timely acquisition of information related to parsing errors during the parsing process of the controller flash file, facilitating relevant personnel to troubleshoot and address the location of the controller flash file error.

[0068] In some embodiments, the step of determining whether the checksum of the current data row has passed verification includes: matching the checksum Checksum1 of the current data row with the calculated checksum Checksum2; if the match is successful, the verification has passed; if the match is unsuccessful, the verification has failed. For example, referring to Table 3 and the above content, the checksum Checksum of the second row in the S19 file is EB, that is, the checksum Checksum1 of the current data row (the second row) is EB; subsequently, the checksum Checksum2 is calculated based on the corresponding content of each field in the S19 file; if the results of Checksum1 and Checksum2 match, the verification has passed.

[0069] In some embodiments, if the controller flash file is an S19 file, the checksum Checksum2 is calculated according to the following formula (1):

[0070] Checksum2=0xFF–(Count+Address+Data) (1)

[0071] Among them, Count is the record length of the current data row, Address is the storage address of the current data row, and Data is the data of the current data row.

[0072] In some embodiments, if the controller flash file is a HEX file, the checksum Checksum2 is calculated according to the following formula (2):

[0073] Checksum2=0xFF–(Length+Load offset+Record type+Data) (2)

[0074] Among them, Length is the record length of the current data row, Load offset is the storage address of the current data row, Record type is the record type of the current data row, and Data is the data of the current data row.

[0075] In step S4, it is determined whether the storage address of the current data row is continuous with the address of the previous data row. If the addresses are not continuous, a new file is created and the process goes to step S5; if the addresses are continuous, the process goes to step S5. For example, referring to Table 3 and the above-mentioned content, the starting address 0x200000 of the 18th row in the S19 file is different from the ending address of the 17th row. The addresses of the 17th row and the 18th row are not continuous, so segmentation occurs here. It is necessary to create a new file and store the data Data of the 18th row in the new file. Continuing to refer to Table 3, after parsing the S19 file in this embodiment, two new files will eventually be created to store the data Data of rows 2 to 17 and rows 18 to 33 respectively.

[0076] For example, by judging whether the data storage addresses of adjacent data rows are continuous, a new file is created if the addresses are not continuous. This setting can resolve multiple discontinuous addresses into multiple files, exposing and solving the problem of discontinuous storage addresses in the controller flash file before flashing the controller.

[0077] In some embodiments, the step of determining whether the storage address of the current data row is continuous with the address of the previous data row includes: matching the storage address of the current data row with the end address of the previous data row; if the matches are inconsistent, the addresses are discontinuous; if the matches are consistent, the addresses are continuous. For example, referring to Table 3 and the above content, the storage address (starting address) of the third row (current data row) in the S19 file is 0x100020, and the ending address of the second row (previous data row) in the S19 file is 0x100020. The starting address of the third row matches the ending address of the second row, so the addresses of the third row and the second row are continuous.

[0078] In some embodiments, the end address of the previous data row is calculated by adding the storage address of the previous data row to the data length of the previous data row.

[0079] In step S5, the data in the current data row is converted to data in a first format and stored in the current new file. In some embodiments, the data in the first format is binary format. For example, by first converting the data content in the data row into binary format before storing it in the current new file, the controller can read the binary data in each pre-processed file during the subsequent execution of the controller flash task without interruption, ensuring the success of the flash task. Furthermore, the data parsed into binary format can be adapted to other subsequent upgrade file formats.

[0080] In step S6, it is determined whether the controller flash file has been read completely. If not, the next data row of the controller flash file is read, and steps S2 to S6 are repeated. If the reading is complete, the parsing task is terminated.

[0081] Below through Figure 2 and Figure 3 Let's take an example to illustrate the process of parsing the controller flash file S19 file and HEX file in this application. Figure 2 This is an exemplary flow chart of the parsing method of the controller flash file S19 according to an embodiment of the present application. Figure 2 As shown, in step S210, a row of data in the S19 file is read; in step S220, the record type Type, record length Count, storage address Address, data Data, and checksum Checksum of the current data row are parsed according to the parsing rules; in step S230, it is determined whether the checksum of the current data row is verified. If the checksum fails, the parsing task is terminated in step S231; if the checksum passes, the process proceeds to step S240; in step S240, it is determined whether the current data row is the first data row in the S19 file. If it is the first data row, a new file is created in step S251, and the process proceeds to step S26. 0; if it is not the first data row, proceed to step S250; in step S250, determine whether the storage address of the current data row matches the end address of the previous data row. If the addresses do not match, create a new file in step S251 and proceed to step S260; if the addresses match, proceed to step S260; in step S260, convert the data of the current data row into binary format data and store it in the current new file, and calculate the end address of the current data row; in step S270, determine whether all data rows of the S19 file have been read to the end. If not, proceed to step S210; if they have been read to the end, end the parsing task in step S280.

[0082] Figure 3 This is an exemplary flow chart of a method for parsing a HEX file of a controller flashing file according to an embodiment of the present application. Figure 3As shown, in step S310, a data row of the HEX file is read; in step S320, the record length Length, storage address Load offset, record type Record type, data Data and checksum Checksum of the current data row are parsed according to the parsing rules; in step S330, it is determined whether the checksum of the current data row is verified. If the checksum fails, the parsing task is ended in step S331; if the checksum passes, the process proceeds to step S340; in step S340, it is determined whether the identifier of the record type Record type is 04. If the identifier is 04, the extended linear address is saved in step S341, and the process proceeds to step S390; if the identifier is not 04, the starting address of the current data row is calculated according to the extended linear address and the storage address Load offset in step S350, and the process proceeds to step S360.

[0083] Continue to refer Figure 3 As shown, in step S360, it is determined whether the current data row is the first data row of the HEX file. If it is the first data row, a new file is created in step S371 and the process goes to step S380; if it is not the first data row, the process goes to step S370; in step S370, it is determined whether the starting address of the current data row matches the ending address of the previous data row. If the addresses do not match, a new file is created in step S371 and the process goes to step S380; if the addresses match, the process goes to step S380; in step S380, the data of the current data row is converted into binary format data and stored in the current new file, and the ending address of the current data row is calculated; in step S390, it is determined whether all data rows of the HEX file have been read to the end. If not, the process goes to step S310; if reading has been completed, the parsing task is ended in step S3010.

[0084] The technical solution of the present application uniformly parses the controller flash file before officially starting to flash the controller, reads and parses each data row of the file line by line, and if a data row fails to parse or the checksum verification fails, the current parsing task will be terminated, which can expose the problem of incorrect parsing or verification in the controller flash file before flashing the controller; by judging whether the data storage addresses of adjacent data rows are continuous, a new file is created if the addresses are not continuous, and the data content in the data rows with continuous storage addresses is first converted into binary format data, and then stored in the new file. This setting can expose the problem of discontinuous storage addresses in the controller flash file before flashing the controller and solve the problem in time. Subsequently, during the formal execution of the controller flash task, the data in each pre-processed file is read, the flashing process will not be interrupted, and the success of the flashing task is guaranteed.

[0085] The present application also includes a controller flash file parsing system, comprising a memory and a processor, wherein the memory is used to store instructions executable by the processor; the processor is used to execute the instructions to implement the controller flash file parsing method described above.

[0086] Figure 4 This is a system block diagram of a controller flash file analysis system according to an embodiment of the present application. Figure 4 As shown, the parsing system 400 for the controller flashing files may include an internal communication bus 401, a processor 402, a read-only memory (ROM) 403, a random access memory (RAM) 404, and a communication port 405. When applied on a personal computer, the parsing system 400 for the controller flashing files may also include a hard disk 406. The internal communication bus 401 can realize data communication between the components of the parsing system 400 for the controller flashing files. The processor 402 can make judgments and issue prompts. In some embodiments, the processor 402 can be composed of one or more processors. The communication port 405 can realize data communication between the parsing system 400 for the controller flashing files and the outside. In some embodiments, the parsing system 400 for the controller flashing files can send and receive information and data from the network through the communication port 405. The controller flash file parsing system 400 may also include various forms of program storage units and data storage units, such as a hard disk 406, a read-only memory (ROM) 403, and a random access memory (RAM) 404, capable of storing various data files used for computer processing and / or communication, as well as possible program instructions executed by the processor 402. The processor executes these instructions to implement the main part of the method. The results of the processor processing are transmitted to the user device through the communication port and displayed on the user interface.

[0087] The above-mentioned controller flash file parsing method can be implemented as a computer program, stored in the hard disk 406, and loaded into the processor 402 for execution to implement the controller flash file parsing method of the present application.

[0088] The present application also includes a computer-readable medium storing computer program code, which, when executed by a processor, implements the controller flash file parsing method described above.

[0089] When the parsing method of the controller flash file is implemented as a computer program, it can also be stored in a computer-readable storage medium as a product. For example, a computer-readable storage medium may include, but is not limited to, magnetic storage devices (e.g., hard disks, floppy disks, magnetic strips), optical disks (e.g., compact disks (CDs), digital versatile disks (DVDs)), smart cards, and flash memory devices (e.g., electrically erasable programmable read-only memories (EPROMs), cards, sticks, key drives). In addition, the various storage media described herein can represent one or more devices and / or other machine-readable media for storing information. The term "machine-readable medium" may include, but is not limited to, wireless channels and various other media (and / or storage media) that can store, contain, and / or carry code and / or instructions and / or data.

[0090] It should be understood that the embodiments described above are merely illustrative. The embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or any combination thereof. For hardware implementation, the processor may be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, and / or other electronic units designed to perform the functions described herein, or a combination thereof.

[0091] Some aspects of the present application can be performed entirely by hardware, entirely by software (including firmware, resident software, microcode, etc.), or by a combination of hardware and software. The above hardware or software can be referred to as "data blocks", "modules", "engines", "units", "components" or "systems". The processor can be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DAPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors or combinations thereof. In addition, various aspects of the present application may be expressed as computer products located in one or more computer-readable media, which include computer-readable program code. For example, computer-readable media may include, but are not limited to, magnetic storage devices (e.g., hard disks, floppy disks, tapes...), optical disks (e.g., compact disks CDs, digital versatile disks DVDs...), smart cards, and flash memory devices (e.g., cards, sticks, key drives...).

[0092] A computer-readable medium may include a propagated data signal embodying computer program code, for example, in baseband or as part of a carrier wave. The propagated signal may be in a variety of forms, including electromagnetic, optical, etc., or a suitable combination thereof. A computer-readable medium may be any computer-readable medium other than a computer-readable storage medium that can be connected to an instruction execution system, apparatus, or device to communicate, propagate, or transmit the program for use. The program code on the computer-readable medium may be transmitted via any suitable medium, including radio, cable, fiber optic cable, radio frequency signal, or similar medium, or any combination of the above.

[0093] The basic concepts have been described above. It will be apparent to those skilled in the art that the above disclosures are merely examples and do not limit the present application. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and revisions to the present application. Such modifications, improvements, and revisions are suggested in the present application and remain within the spirit and scope of the exemplary embodiments of the present application.

[0094] At the same time, this application uses specific terms to describe the embodiments of this application. For example, "one embodiment," "an embodiment," and / or "some embodiments" refer to a certain feature, structure, or characteristic related to at least one embodiment of this application. Therefore, it should be emphasized and noted that "one embodiment," "an embodiment," or "an alternative embodiment" mentioned twice or multiple times in different locations in this specification does not necessarily refer to the same embodiment. In addition, certain features, structures, or characteristics in one or more embodiments of this application may be appropriately combined.

[0095] In some embodiments, numbers are used to describe the quantity of components and attributes. It should be understood that such numbers used in the description of the embodiments are modified by the modifiers "about", "approximately" or "substantially" in some examples. Unless otherwise stated, "about", "approximately" or "substantially" indicate that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the description and claims are approximate values, which may change according to the required features of individual embodiments. In some embodiments, the numerical parameters should take into account the specified significant digits and adopt the general method of retaining digits. Although the numerical domains and parameters used to confirm the breadth of their range in some embodiments of the present application are approximate values, in specific embodiments, the settings of such numerical values are as accurate as possible within the feasible range.

Claims

1. A method for parsing a controller flash file, characterized in that: include: Step S1: Read the current data row of the controller flash file; Step S2: parsing the current data row according to the parsing rules to obtain the storage address of the current data row, the data of the current data row, and the checksum of the current data row; Step S3: Determine whether the checksum of the current data row passes the checksum verification. If the checksum passes, proceed to step S4. If the verification fails, the parsing task ends; Step S4: determining whether the storage address of the current data row is continuous with the address of the previous data row; if the addresses are not continuous, creating a new file and proceeding to step S5; If the addresses are continuous, proceed to step S5; Step S5: converting the data of the current data row into data in a first format, and storing the data in the first format into the current new file; Step S6: Determine whether the controller flash file has been read completely. If not, read the next data row of the controller flash file and repeat steps S2 to S6. If the reading is complete, terminate the parsing task. The step of determining whether the checksum of the current data row has passed verification includes: matching the checksum Checksum1 of the current data row with the calculated checksum Checksum2, if the match is successful, indicating that the verification has passed; if the match is unsuccessful, indicating that the verification has failed; The controller flash file is an S19 file. After parsing the current data row according to the parsing rule, the controller also includes obtaining the record type and record length of the current data row; and calculating the checksum Checksum2 according to the following formula: Checksum2=0xFF–(Count+Address+Data) Wherein, Count is the record length of the current data row, Address is the storage address of the current data row, and Data is the data of the current data row; Alternatively, the controller flash file is a HEX file. After parsing the current data row according to the parsing rule, the process further includes obtaining the record type and the record length of the current data row; and calculating the checksum 2 according to the following formula: Checksum2=0xFF–(Lenghth+Load offset+Record type+Data) Wherein, Length is the record length of the current data row, Load offset is the storage address of the current data row, Record type is the record type of the current data row, and Data is the data of the current data row.

2. The analysis method according to claim 1, wherein: The data in the first format is binary format data.

3. The analysis method according to claim 1, wherein: The step of determining whether the storage address of the current data row is continuous with the address of the previous data row includes: matching the storage address of the current data row with the end address of the previous data row; if the match is inconsistent, it indicates that the addresses are discontinuous; if the match is consistent, it indicates that the addresses are continuous.

4. The analysis method according to claim 3, wherein: The end address of the previous data row is calculated as follows: the storage address of the previous data row plus the data length of the previous data row.

5. The analysis method according to claim 1, wherein: In the step of determining whether the checksum of the current data row passes the checksum verification, if the checksum fails, the method further includes issuing a first alarm and indicating the row number of the current data row.

6. A controller flash file analysis system, characterized in that: include: a memory for storing instructions executable by the processor; A processor, configured to execute the instructions to implement the parsing method according to any one of claims 1 to 5.

7. A computer-readable medium storing computer program code, characterized in that: When the computer program code is executed by a processor, the computer program code implements the parsing method according to any one of claims 1 to 5.

Images