DSP (Digital Signal Processor) remote online upgrading method for brick prevention mechanism
In the DSP remote online upgrade method, the upgrade package and boot loading actions built with preset data organization format are solved, and the system is stable and reliable upgrade is achieved.
Patent Information
- Application Number
- CN202510537405.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-27
- Publication Date
- 2025-06-17
AI Technical Summary
The existing DSP remote online upgrade method cannot ensure the correctness and integrity of the upgraded program, resulting in the system becoming bricked and unable to work properly.
By receiving an upgrade package built based on the preset data organization format, performing boot loading actions, including obtaining stored byte data, version detection, valid content verification and other steps, ensuring the correctness and integrity of the upgrade process.
The correctness and integrity of the online upgrade process of the DSP system is realized, the system is avoided and the correctness and reliability of the upgraded program is ensured.
Smart Images

Figure CN120162069A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of embedded systems, and particularly to a method for remotely online upgrading of a DSP with an anti-brick mechanism. Background Art
[0002] In the prior art, DSP has been widely used in the fields of power control, image signal processing, motor control, etc. When there are defects in the program in the DSP or new functions need to be imported, the program needs to be upgraded. There are many ways to upgrade the DSP program, and among them, the long-distance online upgrade method has gradually become popular. Generally speaking, the long-distance online upgrade process is to receive the upgrade program bin file, then erase the old execution program of the DSP device, and then write the data of the new program bin file into this area, and restart the DSP device to complete the program upgrade.
[0003] However, there are still some deficiencies in the use of this upgrade method: First, it is impossible to ensure the correctness of the program after upgrading. If an exception occurs during the upgrade process, the written data may be different from the expected program data, which may lead to a fatal vulnerability in the system. Second, it is impossible to ensure the integrity of the upgrade process. Abnormalities may occur during the upgrade process due to interrupting the upgrade, etc. Especially during the erasing and writing processes of the program, if the relevant steps are interrupted or even stopped when they are partially executed, in severe cases, the system may become bricked, that is, the execution program of the DSP system is lost or incomplete, resulting in the inability to work properly. Summary of the Invention
[0004] The present invention provides a method for remotely online upgrading of a DSP with an anti-brick mechanism, which can solve the problems of inability to ensure the correctness and integrity of the program after upgrading in the prior art, ensure the correctness and integrity of the online upgrade execution process of the DSP system, and avoid the system from becoming bricked.
[0005] The present invention provides a method for remotely online upgrading of a DSP with an anti-brick mechanism, including:
[0006] Receiving an upgrade program package constructed based on a preset data organization format;
[0007] Performing a boot loading action:
[0008] Obtaining the stored byte data of the download storage area corresponding to the upgrade program package;
[0009] Obtaining the upgrade program package data based on a preset reading rule and the stored byte data;
[0010] Obtaining the current program version number to perform version detection on the upgrade program package based on the upgrade program package data and the current program version number, and obtaining the detection result;
[0011] When the detection result is executable, update the executable program area based on the upgrade package data to obtain executable upgrade data;
[0012] Perform a valid content verification based on the executable upgrade data to obtain a valid content verification result;
[0013] When the valid content verification result is normal, update the corresponding information storage area based on the upgrade package data to complete the remote online upgrade of the DSP system.
[0014] The method provided by the present invention, by packing and constructing the upgrade package according to the preset data organization format, provides data format support for subsequent processes such as the reception, detection, and verification of the anti-brick mechanism of the upgrade installation package; first, check whether there is an upgrade installation package through data reading, and then judge the relationship between the upgrade installation package and the current version by verifying the consistency of the version number of the upgrade package and the current system version number, so as to determine whether the system needs to be upgraded and whether it meets the file information required for the upgrade, ensuring the correct execution of the upgrade process; then ensure the correct integrity of the content information of the upgrade package through valid content verification, avoiding abnormal upgrades when executing the anti-brick upgrade program due to problems such as damage to the upgrade package; at the same time, during the entire inspection and upgrade process, different types of data are stored independently, avoiding the loss of key data due to accidental erasure, accidental overwriting, etc. when data is in the same area, which may lead to the system becoming bricked; and through multi-layer data verification and determination, the correctness and integrity of the upgrade process execution are ensured, avoiding situations such as the system becoming bricked, such as the execution program of the DSP system being lost or incomplete, resulting in abnormal operation.
[0015] Further, obtain the upgrade package data based on the preset reading rule and the stored byte data, including: reading and identifying the stored byte data based on the preset reading rule, and judging that there is an upgrade package when there are a head identifier and a tail identifier; obtaining the packet header information and the Bin file based on the head identifier, the tail identifier, and the preset data organization format; obtaining the upgrade version number, the Bin file check value, and the Bin file size based on the packet header information and the preset packet header information format; obtaining the upgrade package data based on the packet header information, the upgrade version number, the Bin file check value, and the Bin file size.
[0016] Further, reading and identifying the stored byte data based on the preset reading rule, and when there are a head identifier and a tail identifier, judging that there is an upgrade package, further includes: reading and identifying the stored byte data based on the preset reading rule, and judging that there is no upgrade package when the head identifier and the tail identifier cannot be identified. At this time, no upgrade is required and the boot loading action ends.
[0017] The above solution is based on the preset data organization format of the upgrade package. By using the preset reading rules to read and identify whether there are a head identifier and a tail identifier in the stored byte data, it determines whether there is an upgrade package, providing a real-time judgment mechanism for whether the upgrade loading action can continue. When the head identifier and the tail identifier cannot be recognized, it is determined that there is no upgrade package, directly ending the system boot loading action, preventing abnormalities caused by the continued execution of the program when the corresponding data of the upgrade package does not exist, and ensuring the integrity of the data during the system upgrade process.
[0018] Furthermore, obtain the current program version number to perform version detection on the upgrade package based on the upgrade package data and the current program version number, and obtain the detection result, including: obtaining the current program version number to obtain the upgrade determination result based on the current program version number and the upgrade version number; when the upgrade determination result is inconsistent, obtain the upgrade verification value based on the Bin file, the Bin file size, and the preset verification method, and obtain the consistency verification result based on the upgrade verification value and the Bin file verification value; when the consistency verification result is consistent, obtain the executable detection result.
[0019] Furthermore, obtaining the current program version number to obtain the upgrade determination result based on the current program version number and the upgrade version number further includes: when the upgrade determination result is consistent, obtaining the result of no need to execute the detection.
[0020] The above solution further identifies the upgrade version number in the upgrade package and performs a consistency judgment with the current program version number, etc., to obtain the upgrade determination result. When the two are consistent, it indicates that the current program is already the corresponding version of the upgrade package. At this time, the system does not need to upgrade again according to the upgrade package, obtaining the result of no need to execute the detection. Then, based on the result of no need to execute the detection, perform an erase action, delete the stored byte data in the corresponding download storage area, and end the boot loading action, avoiding unnecessary upgrade steps of the system. At the same time, delete the corresponding upgrade package information stored locally, avoiding subsequent repeated identification and verification or confusion and overlap with newly received information, ensuring the integrity and feasibility of the system upgrade process.
[0021] Furthermore, when the upgrade determination result is inconsistent, obtain the upgrade verification value based on the Bin file, the Bin file size, and the preset verification method, and obtain the consistency verification result based on the upgrade verification value and the Bin file verification value further includes: when the consistency verification result is inconsistent, obtaining the result of non-executable detection.
[0022] The above solution further identifies the Bin files included in the upgrade package through a preset verification method, and performs a consistency verification with the Bin file verification values in the header information to ensure the integrity of the Bin files in the upgrade package stored in the current corresponding download storage area. When the verification result is inconsistent, it can be determined that there are problems such as incomplete or damaged header information or Bin files in the upgrade package stored in the current corresponding download storage area. Performing a program upgrade is dangerous and this upgrade is not allowed. At this time, an unexecutable detection result is obtained, and thus an erasure action is performed according to the unexecutable detection result, deleting the stored byte data in the corresponding download storage area, and ending the boot loading action, avoiding the system from upgrading according to incomplete or incorrect Bin files, thus preventing system anomalies or bricking. At the same time, the corresponding upgrade package information stored locally is deleted to avoid subsequent repeated identification and verification or confusion and overlap with newly received information, ensuring the integrity and feasibility of the system upgrade process.
[0023] Furthermore, an effective content verification is performed based on the executable upgrade data to obtain an effective content verification result, including: identifying the starting address of the executable program area based on the execution upgrade package data, so as to obtain an effective verification value based on the starting address, the Bin file size, and the Bin file; performing a consistency judgment based on the effective verification value and the upgrade verification value to obtain an effective judgment result; when the effective judgment result is consistent, the effective content verification result is normal.
[0024] Furthermore, performing a consistency judgment based on the effective verification value and the upgrade verification value to obtain an effective judgment result further includes: when the effective judgment result is inconsistent, the effective content verification result is abnormal, and then return to the step to perform the boot loading action.
[0025] The above solution further verifies the upgrade verification value in the previous step with the effective verification value in the Bin file that has been written into the executable program area, verifying the byte amount and content of the Bin file size, to ensure that the relevant programs in the Bin file in the current area are completely and correctly written into the executable program area, and the next upgrade process can be entered. When the effective judgment result is inconsistent, it means that an operation anomaly has occurred. At this time, directly return to the step to perform the boot loading action. By directly returning to the beginning of the action, the program design is simplified, and at the same time, the problem of writing anomalies can be solved. After re-initializing the configuration and re-performing the boot loading action to write the data again, the problem of writing anomalies can be solved.
[0026] Furthermore, when the detection result is executable, the executable program area is updated based on the upgrade package data to obtain executable upgrade data, including: when the detection result is executable, erasing all the data in the executable program area; writing the upgrade package data into the executable program area in the preset byte sequence.
[0027] The above solution realizes the update by first erasing all the data in the executable program area and then writing new data, effectively avoiding data overlap and confusion, and simplifies the program design to avoid logical errors caused by complex logic during the R & D process, thereby avoiding abnormal situations during the DSP system upgrade. At the same time, the upgrade program package data is written in the preset byte sequence, which is coordinated with the previous storage and parsing steps to ensure the correct writing of the corresponding data.
[0028] Further, when the valid content verification result is normal, the corresponding information storage area is updated based on the upgrade program package data to complete the remote online upgrade of the DSP system, including: when the valid content verification result is normal, the upgrade version number is obtained based on the upgrade program package data; the corresponding information storage area is updated based on the updated upgrade version number; the stored byte data is deleted, and the DSP system is run based on the executable upgrade data to end the boot loading operation and complete the remote online upgrade of the DSP system.
[0029] The above solution first performs a valid content verification on the data content of the updated executable program area to ensure that when the data information is normal, the new program version number, that is, the upgrade version number, is written into the corresponding information storage area to overwrite the old version number information, and the program overwrite operation in the DSP program upgrade operation is completed. If an exception occurs at this time (such as power failure, abnormal interference causing system reset, etc.), the boot loading operation in the previous anti-brick mechanism upgrade process will not be executed again, and the data writing operation in the executable program area will be prohibited. And after completion, the entire download area is erased, and due to the preset data organization format of the upgrade program package, the header information containing identification information, etc. is erased first, avoiding the boot loading operation that restarts due to an exception during erasure from writing damaged data into the executable program area, ensuring the security and integrity of the data during the upgrade process, and ensuring the correctness of the program after the upgrade.
[0030] The method provided by the present invention combines the logical closed-loop of the upgrade program package data format and the arrangement of the step execution sequence to realize the design of the anti-brick mechanism in the DSP remote online upgrade process. Through the relevant verification information carried in the header information set in the upgrade program package and the verification of the correctness before and after writing in the process, the integrity of the data during the upgrade process and the correctness of the program after the upgrade are ensured. At the same time, it can still complete the program upgrade goal after being abnormally interrupted during the upgrade process, without fear of abnormal situations during the upgrade process. Through multi-layer data verification and determination, the correctness and integrity of the upgrade process execution are ensured, and situations such as system brickification, such as the loss or incompleteness of the execution program of the DSP system, resulting in abnormal operation, are avoided. BRIEF DESCRIPTION OF THE DRAWINGS
[0031] To more clearly illustrate the technical solutions of this application, the following will briefly introduce the drawings required for the implementation. Obviously, the drawings in the following description are only some embodiments of this application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.
[0032] Figure 1 It is a schematic flowchart of a DSP remote online upgrade method with a brick prevention mechanism provided in this embodiment;
[0033] Figure 2 It is a schematic flowchart of the implementation steps of a DSP remote online upgrade with a brick prevention mechanism provided in this embodiment;
[0034] Figure 3 It is a schematic diagram of a preset data organization format of a brick prevention mechanism provided in this embodiment;
[0035] Figure 4 It is a schematic diagram of the memory partition of a brick prevention mechanism provided in this embodiment;
[0036] Figure 5 It is a schematic flowchart of a DSP remote online upgrade program with a brick prevention mechanism provided in this embodiment. Specific implementation manners
[0037] To make the objectives, technical solutions and advantages of this application clearer, the following will clearly and completely describe the technical solutions in this application in combination with the drawings in the embodiments of this application. Obviously, the described embodiments are some but not all of the embodiments of this application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in this application without creative efforts fall within the scope of protection of this application.
[0038] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which this application belongs; the terms used herein are only for the purpose of describing specific embodiments and are not intended to limit this application; the terms "including" and "having" and any variations thereof in the description of the specification and claims of this application and the above drawings are intended to cover non-exclusive inclusion.
[0039] In the description of the embodiments of this application, technical terms such as "first" and "second" are only used to distinguish different objects and cannot be understood as indicating or implying relative importance or implicitly specifying the quantity, specific order or primary-secondary relationship of the indicated technical features. In the description of the embodiments of this application, "a plurality of" means two or more unless otherwise specifically defined.
[0040] References to "embodiments" in this document mean that the specific features, structures, or characteristics described in connection with the embodiments can be included in at least one embodiment of this application. The phrase appears in various places in the specification and does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. Those skilled in the art will explicitly and implicitly understand that the embodiments described herein can be combined with other embodiments.
[0041] In the description of the embodiments of this application, the term "and / or" is merely a description of the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this document generally represents an "or" relationship between the associated objects before and after.
[0042] In the description of the embodiments of this application, the term "plurality" refers to more than two (including two). Similarly, "multiple groups" refers to more than two groups (including two groups), and "multiple pieces" refers to more than two pieces (including two pieces).
[0043] In the description of the embodiments of this application, unless otherwise clearly specified and limited, technical terms such as "installation", "connection", "connection", "fixation", etc. should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or integrated; it can also be a mechanical connection or an electrical connection; it can be directly connected, or indirectly connected through an intermediate medium, and can be the communication inside two components or the interaction relationship between two components. For those of ordinary skill in the art, the specific meanings of the above terms in the embodiments of this application can be understood according to specific situations.
[0044] Embodiment 1:
[0045] See Figure 1 , to solve the problem that the correctness and integrity of the program cannot be ensured after the upgrade in the prior art, and to ensure the correctness and integrity of the execution process of the DSP system's online upgrade and avoid the system from becoming a "brick", this embodiment provides a DSP remote online upgrade method with an anti-brick mechanism, including:
[0046] S01. Receive the upgrade program package constructed based on the preset data organization format;
[0047] S02. Perform the boot loading action:
[0048] S021. Obtain the stored byte data in the storage area corresponding to the upgrade program package;
[0049] S022. Obtain the upgrade program package data based on the preset reading rule and the stored byte data;
[0050] S023. Obtain the current program version number, and based on the upgrade package data and the current program version number, perform version detection on the upgrade package to obtain the detection result;
[0051] S024. When the detection result is executable, update the executable program area based on the upgrade package data to obtain executable upgrade data;
[0052] S025. Perform a valid content verification based on the executable upgrade data to obtain the valid content verification result;
[0053] S026. When the valid content verification result is normal, update the corresponding information storage area based on the upgrade package data to complete the remote online upgrade of the DSP system.
[0054] The method provided in this embodiment packs and constructs the upgrade package according to the preset data organization format, providing data format support for subsequent processes such as the reception, detection, and verification of the anti-brick mechanism of the upgrade installation package; first, it checks whether there is an upgrade installation package through data reading, and then judges the relationship between the upgrade installation package and the current version by verifying the consistency between the version number of the upgrade package and the current system version number, thereby determining whether the system needs to be upgraded and whether it meets the file information required for the upgrade, ensuring the correct execution of the upgrade process; then, it ensures the correct integrity of the content information of the upgrade package through valid content verification, avoiding abnormal upgrades when executing the anti-brick upgrade program due to problems such as damage to the upgrade package; at the same time, during the entire inspection and upgrade process, different types of data are stored independently, avoiding the loss of key data due to situations such as accidental erasure and accidental overwriting when data is in the same area, which may lead to the system becoming bricked; and through multi-layer data verification and determination, the correctness and integrity of the upgrade process execution are ensured, avoiding situations such as the system becoming bricked, such as the execution program of the DSP system being lost or incomplete, resulting in abnormal operation.
[0055] In the specific implementation process, as Figure 2 shown, the process of the DSP system receiving and upgrading the upgrade package includes the following processes:
[0056] S11. Before the DSP system receives the upgrade package, first perform a packaging operation on the required upgrade program based on the preset data organization format, and send the packaged upgrade package to the DSP system through the remote communication system;
[0057] S12. After the DSP system receives the upgrade package, perform a reset operation, software-reset the DSP system, so that the DSP system enters the Bootloader program;
[0058] S13. Execute the upgrade package detection logic to perform the anti-brick mechanism program upgrade, that is, execute the boot loading action;
[0059] S14. The program jumps to the service program and reports the upgrade status through the remote communication system.
[0060] For example, the upgraded program is an executable file generated by the compilation software provided by the chip manufacturer based on the service code written by the developer, which is usually uniformly called the Bin file. After the data of this file is written into the FLASH of the executable program area, it can be executed by the DSP.
[0061] After step S11 completes the construction of the upgrade program package, it is necessary to send the upgrade program package through the remote communication system. Here, the remote communication system refers to a system with long-distance communication data capabilities and its supporting hardware devices. In this technical solution, a WIFI module is used to connect to the Internet of Things cloud platform. Through the file transfer function of the Internet of Things cloud platform, the data packet of the upgrade program is sent to the device locally in the order of bytes, and then through the board-level communication interface provided by the WIFI module, the DSP receives the upgrade program package.
[0062] In step S12, the DSP receives the upgrade program package. It mainly obtains data through the board-level communication interface and then stores it in the specified area of the memory of the DSP device in the order of data reception. The specific storage method also needs to be adaptively modified in combination with the characteristics of the specific communication module, and the method is not unique. The purpose is to make the content represented by the received upgrade program package in the memory consistent with that before transmission, otherwise it will affect the correctness of the subsequent local verification step.
[0063] In step S12, after the software resets the DSP system and the system enters the Bootloader program, it means that after receiving the upgrade program package, through the program logic designed in the software, the DSP system reset function is triggered to make the DSP system execute the program again (that is, start executing the program from the default program start address), and this address should be the starting address of the Bootloader program.
[0064] Step S14 means that after the Bootloader program completes the program upgrade process, the DSP enters the program that implements the service function. After entering, it obtains the current program version number from the corresponding information storage area, and then reports the version number through the communication interface provided by the communication system to inform the system that the upgrade has been completed.
[0065] Optionally, this embodiment provides a preset data organization format, such as Figure 3As shown, during the process of packaging the upgrade program, the content of the data is reorganized according to the preset data organization format of the upgrade program package to construct the upgrade program package. This preset data organization format is part of the anti-brick mechanism design of this solution. The detailed preset data organization method is to supplement the header information segment (i.e., the header information) in front of the Bin file. The specific format requirement of the header information segment is 16 bytes, specifically: the 1st to 2nd bytes are the header identifier, and in this solution, 0x55AA is used as the header identifier, a total of 2 bytes; the 3rd to 6th bytes are the version number (corresponding to the upgrade version number), and the version number is the unique identifier of the current version of the upgrade program package, which means that each version corresponds to a corresponding upgrade program package, a total of 4 bytes; the 7th to 10th bytes are the Bin file check value. For the Bin file check value, in this solution, CRC-16 check is used. CRC-16 check is a common and mature check algorithm. The way to obtain it is to perform the check calculation of this algorithm on the Bin file. At the same time, it should be noted that the check value obtained by CRC-16 is only 2 bytes, while 4 bytes of space are reserved here to provide storage space for the 4-byte check value obtained by CRC-32 check in some special scenarios, ensuring the flexibility and adaptability of data information verification and judgment, a total of 4 bytes; the 11th to 14th bytes are the size of the Bin file, and the way to obtain it is to count the number of bytes of data in the Bin file, a total of 4 bytes; the 15th to 16th bytes are the tail identifier, and in this solution, 0x0D0A is used as the tail identifier, a total of 2 bytes; in the following specific judgment steps such as data verification, the information format of each field in the header information segment will be used as the basis for verification and detection.
[0066] In the specific implementation process, the boot loading action is part of the execution of the Bootloader program logic. After the DSP enters the Bootloader program, it should first perform system initialization. The main process of this program is to perform the initialization configuration of the memory controller and the memory. After the configuration is completed, wait for the DSP system to stabilize, and then enter the next process.
[0067] Optionally, step S022 includes: reading and identifying the stored byte data based on the preset reading rule, and judging that there is an upgrade program package when there is a header identifier and a tail identifier; obtaining the header information and the Bin file based on the header identifier, the tail identifier and the preset data organization format; obtaining the upgrade version number, the Bin file check value and the size of the Bin file based on the header information and the preset header information format; obtaining the upgrade program package data based on the header information, the upgrade version number, the Bin file check value and the size of the Bin file.
[0068] Optionally, when reading and identifying the stored byte data based on the preset reading rule, if the header identifier and the tail identifier cannot be identified, it is judged that there is no upgrade program package. At this time, there is no need to upgrade, and the boot loading action ends.
[0069] In the specific implementation process, when determining whether there is an upgrade program package in the download area, the action of reading and identifying the stored byte data corresponds to reading and identifying the first 16 bytes of the corresponding download storage area. First, judge the first to the second byte and the 15th to the 16th byte. These four bytes respectively correspond to the head and tail identifiers in the header information segment of the upgrade program package. If they exist, it is determined that there is an upgrade program package and the next process is entered; otherwise, there is no need for an upgrade and the boot loading action ends.
[0070] In the specific implementation process, obtaining the header information and the Bin file based on the head identifier, the tail identifier, and the preset data organization format lies in, according to the head and tail identifiers in the header information identified in the previous process, splitting the header information of the upgrade program package and the Bin file from the corresponding download storage area, and then extracting the header information. Further, the extracted header information is divided into corresponding items according to the preset header information format to obtain the upgrade version number, the Bin file check value, and the Bin file size.
[0071] Optionally, step S023 includes: obtaining the current program version number to obtain an upgrade determination result based on the current program version number and the upgrade version number; when the upgrade determination result is inconsistent, obtaining an upgrade check value based on the Bin file, the Bin file size, and the preset check method to obtain a consistency check result based on the upgrade check value and the Bin file check value; when the consistency check result is consistent, obtaining an executable detection result.
[0072] Optionally, when the upgrade determination result is consistent, obtain a result indicating that there is no need to execute the detection.
[0073] In the specific implementation process, the process of judging the difference between the current program version number and the upgrade version number in the upgrade program package is mainly to judge whether the value of the current program version number in the current executable program is consistent with the value of the upgrade version number in the header information extracted in the previous process. The upgrade version number in the header information represents the version identifier of the upgrade program. If they are consistent, it means that the program in the current executable program area is consistent with the Bin file in the upgrade program package and no upgrade operation is required; if they are inconsistent, it means that the program in the executable program area needs to be upgraded and the next process is entered.
[0074] Optionally, when the consistency check result is inconsistent, obtain a non-executable detection result.
[0075] In the specific implementation process, this process refers to using a DSP or hardware devices related to the DSP board level to perform CRC verification on the valid content of the Bin file in the upgrade package. The basis for identifying the valid content of the Bin file is the size of the Bin file in the header information. Specifically, through CRC-16 or CRC-32, the same CRC verification algorithm as that used when building the upgrade package is used for verification, otherwise the calculation cannot be performed correctly. The purpose of this verification calculation is to verify the integrity of the Bin file of the upgrade package in the current download area, and at the same time, the obtained upgrade verification value provides a judgment basis for the next process.
[0076] Optionally, step S025 includes: based on the execution of the upgrade package data, identify the starting address of the executable program area, so as to obtain a valid verification value based on the starting address, the size of the Bin file, and the Bin file; perform a consistency judgment based on the valid verification value and the upgrade verification value to obtain a valid judgment result; when the valid judgment result is consistent, the valid content verification result is normal.
[0077] Optionally, step S025 further includes: when the valid judgment result is inconsistent, the valid content verification result is abnormal, and then return to the step to perform the boot loading action.
[0078] In the specific implementation process, by further judging the upgrade verification value calculated in the previous process according to the upgrade verification value in the previous step, whether it is consistent with the Bin file verification value (CRC verification) in the header information of the upgrade package. If it is consistent, it means that the Bin file in the upgrade package in the current download area is complete and correct, and the upgrade is allowed, and the next upgrade process can be entered; otherwise, it means that the header information or Bin file information of the upgrade package in the current download area is damaged, and it is dangerous to perform the program upgrade, and this upgrade is not allowed.
[0079] Optionally, when the detection result is executable, erase all data in the executable program area; write the upgrade package data into the executable program area in the preset byte sequence.
[0080] In the specific implementation process, the memory controller is used to erase the executable program area. In this solution, a full erasure of this area is adopted to simplify the program design and avoid logical errors caused by complex logic during the R & D process. After the erasure is completed, the memory controller writes the valid content of the Bin file in the corresponding download storage area into the executable program area in accordance with the size of the Bin file in the byte sequence. After the write operation is completed, the next process is entered.
[0081] Optionally, when the verification result of the valid content is normal, update the corresponding information storage area based on the upgrade package data to complete the remote online upgrade of the DSP system, including: when the verification result of the valid content is normal, obtain the upgrade version number based on the upgrade package data; update the corresponding information storage area based on the updated upgrade version number; delete the stored byte data, and run the DSP system based on the executable upgrade data to end the boot loading action and complete the remote online upgrade of the DSP system.
[0082] In the specific implementation process, during the CRC verification of the program in the executable program area, the program is divided based on the Bin file size in the header information. Starting from the starting address of the executable program area, verify the number of bytes of the Bin file size. After obtaining the verification value, make a consistency judgment with the upgrade verification value. If they are consistent, it means the program is completely and correctly written into the executable program area, and the next process can be entered; otherwise, it means that the write operation has an exception, return to the step to execute the boot loading action, and the upgrade process of the anti-brick mechanism needs to be re-executed. The purpose of returning to the step to execute the boot loading action is to simplify the program design and solve the problem of write exceptions. When there is a write exception, it can be solved by re-initializing the memory controller and then writing the data again. Then write the new program upgrade version number into the corresponding information storage area to overwrite the old version number information. When this process is completed, it indicates that the program overwrite operation in the DSP program upgrade operation has been completed. If an exception occurs at this time (such as power-off, abnormal interference causing system reset, etc.), the previous anti-brick mechanism upgrade will not be executed again, and the data write operation in the executable program area is prohibited.
[0083] In the specific implementation process, the purpose of deleting the stored byte data is to delete the upgrade package, that is, to perform a whole-area erasure of the corresponding download storage area. During the erasure process, due to the format design of the upgrade package, the header information and its identifier are erased first, avoiding the situation where an exception occurs during erasure, resulting in restarting the boot loading action process and writing damaged data into the executable program area.
[0084] In the specific implementation process, after the above process is completed, there is also an executable program to be executed. This process is the exit of the complete anti-brick mechanism upgrade, and the main operation is to make the DSP system execute the program in the executable program area.
[0085] In the specific implementation process, the storage logic of the memory associated with the DSP in this solution is divided as Figure 4The four major blocks shown specifically include: the Bootloader area, the executable program area, the download area (corresponding to the download storage area), and the information area (corresponding to the information storage area). The purpose is to avoid misoperations caused by data sharing the same storage area, such as accidental erasure and accidental overwriting resulting in the loss of critical data, which may further lead to the system becoming bricked. This design is also part of the anti-brick mechanism design of this solution. Among them, the memory associated with the DSP refers to the FLASH used to execute programs inside the DSP chip and the externally expanded non-volatile memory on the board.
[0086] In the specific implementation process, the Bootloader area is in the memory. Its starting address needs to be the address to which the DSP jumps after defaultly executing the chip-cured configuration program, and this section needs to store the Bootloader program. Therefore, this area can only be divided in the FLASH area where the program code is executed inside the DSP chip. In this solution, a DSP chip of Texas Instruments (Ti) with the model number TMS320F28034 is used, and its jump address is 0x3F7FF6. The addresses of DSP chips from different manufacturers or of different models are different and not unique. The executable program area stores the service function programs that the DSP needs to implement, that is, the programs that need to be upgraded. Since the programs need to be executed, they should be stored in the FLASH area where the program code is executed inside the DSP chip. It should be specifically noted that this area should be clearly separated from the FLASH area to which the Bootloader segment belongs, and there should be no intersection or common use of the same sector between the two sections. Otherwise, when the erase program operation is executed, data may be accidentally erased, resulting in the DSP system becoming bricked. The download area and the information area are mainly for storing data that is not lost when the power is off and do not need to execute programs. Therefore, there is no strict requirement for the memory to which they belong, as long as the situation of intersecting and sharing with other areas is avoided. Among them, the download section stores the upgrade program package, and the information section stores the information data for the normal operation of the Bootloader program.
[0087] The method provided in this embodiment combines the logical closed-loop of the upgrade program package data format and the arrangement of the step execution order to achieve the design of the anti-brick mechanism in the DSP remote online upgrade process. Through the relevant verification information carried in the header information set in the upgrade program package and the verification of the correctness before and after writing in the process, the integrity of the data during the upgrade process and the correctness of the program after the upgrade are ensured. At the same time, it is ensured that the program upgrade can still be completed after being abnormally interrupted during the upgrade process, without fearing abnormal situations during the upgrade process. Through multi-layer data verification and determination, the correctness and integrity of the upgrade process execution are ensured, and situations such as the system becoming bricked, such as the loss or incompleteness of the execution program of the DSP system, resulting in abnormal operation, are avoided.
[0088] It can be understood that the above device item embodiments correspond to the method item embodiments of the present invention, and can implement a DSP remote online upgrade method with an anti-brick mechanism provided by any one of the above method item embodiments of the present invention.
[0089] It should be noted that the device embodiments described above are only illustrative. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. In addition, in the attached drawings of the device embodiments provided by the present invention, the connection relationship between the modules indicates that there is a communication connection between them, which can be specifically implemented as one or more communication buses or signal lines. Those of ordinary skill in the art can understand and implement it without creative work.
[0090] Embodiment 2:
[0091] As Figure 5 shown, this embodiment provides a Bootloader program for a DSP remote online upgrade method with an anti-brick mechanism, including the following processes:
[0092] S20. Start;
[0093] S21. Initialize the DSP system;
[0094] S22. Determine whether there is an upgrade program package in the download area. If so, execute step S23. If not, execute step S212;
[0095] S23. Obtain the header information in the upgrade program package, and obtain the upgrade version number and the Bin file check value;
[0096] S24. Obtain the current program version number, and determine whether the current program version number is the same as the upgrade version number. If so, execute step S211. If not, execute step S25;
[0097] S25. Locally calculate the CRC value in the upgrade program package;
[0098] S26. Determine whether the CRC value is the same as the Bin file check value. If so, execute step S27. If not, execute step S211;
[0099] S27. Erase the data in the executable program area;
[0100] S28. Obtain the Bin file in the upgrade program package and write it into the executable program area;
[0101] S29. Determine whether the executable program segment in the current executable program area is valid content: obtain the valid check value of the Bin file, and determine whether the valid check value is the same as the CRC value. If so, execute step S210. If not, return to step S20;
[0102] S210. Write the upgraded version number into the information area;
[0103] S211. Delete the upgrade program package;
[0104] S212. Execute the executable program;
[0105] S213. End.
[0106] In the specific implementation process, the direct process numbers reaching process S212 are processes S22 and S211: Jumping from process S22 to S212 generally falls into two cases. One is the execution process when program upgrade is not required under normal circumstances; the other is that during the execution of process S211, it is abnormally interrupted, resulting in partial content of the upgrade program package being erased but not completely erased, and then re - entering the execution process of the Bootloader program. Jumping from process S211 to S212 generally falls into two cases. One is the execution process when the program executes the complete program upgrade process under normal circumstances; the other is that an exception occurs during the program upgrade process, and then re - enters the execution process of the Bootloader program.
[0107] The program flow of the anti - brick mechanism provided in this embodiment ensures the correctness of the program after upgrade through the verification information carried in the packet header information and the pre - write and post - write correctness verification in the process. Through this logical closed - loop combined with the packet header information and the arrangement of the step execution sequence, the goal of completing the program upgrade can still be achieved after being abnormally interrupted during the upgrade process, ensuring the integrity of the upgrade process execution.
[0108] Embodiment Three:
[0109] Based on the above - mentioned embodiment of the DSP remote online upgrade method with an anti - brick mechanism, another embodiment of the present invention provides a terminal device, which includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements the DSP remote online upgrade method with an anti - brick mechanism according to any embodiment of the present invention.
[0110] Exemplarily, in this embodiment, the computer program can be divided into one or more modules. The one or more modules are stored in the memory and executed by the processor to complete the present invention. The one or more modules can be a series of computer program instruction segments capable of completing specific functions, and these instruction segments are used to describe the execution process of the computer program in the terminal device.
[0111] The terminal device may be a computing device such as a desktop computer, a notebook, a palm computer, and a cloud server. The terminal device may include, but is not limited to, a processor and a memory.
[0112] The so-called processor may be a central processing unit (CPU), or may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The processor is the control center of the terminal device, and uses various interfaces and lines to connect all parts of the entire terminal device.
[0113] Embodiment 4:
[0114] Based on the above method item embodiments, another embodiment of the present invention provides a computer-readable storage medium, including a stored computer program, wherein when the computer program runs, it controls the device where the computer-readable storage medium is located to execute a DSP remote online upgrade method of an anti-brick mechanism described in any one of the above method item embodiments of the present invention.
[0115] Among them, if the modules / units integrated in the device / terminal device are implemented in the form of software function units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on such an understanding, to implement all or part of the processes in the above embodiment methods of the present invention, it can also be completed by a computer program instructing relevant hardware. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps of the above various method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, executable file, or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium, etc.
[0116] The above are the preferred embodiments of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and refinements can be made, and these improvements and refinements are also regarded as the protection scope of the present invention.
Claims
1. A DSP remote online upgrade method with anti-brick mechanism, characterized in that: include: receiving an upgrade package constructed based on a preset data organization format; Execute the bootloader action: Obtain storage byte data of a download storage area corresponding to the upgrade program package; Acquire upgrade program package data based on preset reading rules and the stored byte data; Obtaining a current program version number, performing version detection on the upgrade program package based on the upgrade program package data and the current program version number, and obtaining a detection result; When the detection result is executable, updating the executable program area based on the upgrade program package data to obtain executable upgrade data; Performing effective content verification based on the executable upgrade data to obtain effective content verification results; When the valid content verification result is normal, the corresponding information storage area is updated based on the upgrade package data to complete the remote online upgrade of the DSP system.
2. A DSP remote online upgrade method with anti-brick mechanism as claimed in claim 1, characterized in that: The step of acquiring the upgrade program package data based on the preset reading rule and the stored byte data includes: Read and identify the stored byte data based on a preset reading rule, and determine that an upgrade program package exists when a head mark and a tail mark exist; Acquire packet header information and Bin file based on the header identifier, the tail identifier and the preset data organization format; Obtaining an upgrade version number, a Bin file checksum, and a Bin file size based on the packet header information and a preset packet header information format; Get the upgrade package data based on the package header information, upgrade version number, Bin file checksum and Bin file size.
3. A DSP remote online upgrade method with anti-brick mechanism as claimed in claim 2, characterized in that: The method of reading and identifying the stored byte data based on a preset reading rule, and determining that an upgrade program package exists when a head mark and a tail mark exist, further includes: The stored byte data is read and identified based on a preset reading rule. When the head mark and the tail mark cannot be identified, it is determined that there is no upgrade package. At this time, no upgrade is required, and the boot loading action is terminated.
4. A DSP remote online upgrade method with anti-brick mechanism as claimed in claim 2, characterized in that: The obtaining of the current program version number, performing version detection on the upgrade program package based on the upgrade program package data and the current program version number, and obtaining a detection result, includes: Obtaining the current program version number to obtain an upgrade determination result based on the current program version number and the upgrade version number; When the upgrade determination result is inconsistent, an upgrade verification value is obtained based on the Bin file, the Bin file size and a preset verification method, so as to obtain a consistency verification result based on the upgrade verification value and the Bin file verification value; When the consistency check result is consistent, an executable test result is obtained.
5. A DSP remote online upgrade method with anti-brick mechanism as claimed in claim 4, characterized in that: The obtaining of the current program version number to obtain an upgrade determination result based on the current program version number and the upgrade version number further includes: When the upgrade determination result is consistent, a detection result that does not require execution is obtained.
6. A DSP remote online upgrade method with anti-brick mechanism as claimed in claim 4, characterized in that: When the upgrade determination result is inconsistent, an upgrade verification value is obtained based on the Bin file, the Bin file size and a preset verification method, so as to obtain a consistency verification result based on the upgrade verification value and the Bin file verification value, further comprising: When the consistency check result is inconsistent, an unexecutable detection result is obtained.
7. A DSP remote online upgrade method with anti-brick mechanism as claimed in claim 4, characterized in that: The performing valid content verification based on the executable upgrade data to obtain a valid content verification result includes: Identify the first address of the executable program area based on the execution upgrade program package data, so as to obtain a valid check value based on the first address, the size of the Bin file and the Bin file; Perform consistency judgment based on the valid check value and the upgraded check value to obtain a valid judgment result; When the validity determination result is consistent, the validity content verification result is normal.
8. A DSP remote online upgrade method with anti-brick mechanism as claimed in claim 7, characterized in that: The performing consistency judgment based on the valid check value and the upgraded check value to obtain a valid judgment result also includes: When the validity determination result is inconsistent, the validity content verification result is abnormal, and the process returns to the step of executing the boot loading action.
9. A DSP remote online upgrade method with anti-brick mechanism as claimed in claim 1, characterized in that: When the detection result is executable, updating the executable program area based on the upgrade program package data to obtain executable upgrade data includes: When the detection result is executable, erasing all data in the executable program area; The upgrade program package data is written into the executable program area according to a preset byte order.
10. The DSP remote online upgrade method with anti-brick mechanism as claimed in claim 1, characterized in that: When the valid content verification result is normal, the corresponding information storage area is updated based on the upgrade package data to complete the remote online upgrade of the DSP system, including: When the valid content verification result is normal, obtaining the upgrade version number based on the upgrade package data; Updating the corresponding information storage area based on the upgraded version number; The stored byte data is deleted, and the DSP system is run based on the executable upgrade data to end the boot loading action and complete the remote online upgrade of the DSP system.