Software online upgrading method of DSP chip based on CAN bus interface

Abstract

The invention provides a software online upgrading method of a DSP chip based on a CAN bus interface. The software online upgrading method comprises the steps that an OUT format file generated by compiling a source project is converted into a BIN file; the method comprises the steps that a BIN file is unpacked and subpackaged, generated data packets are sent to an FPGA, DSP software conducts CRC verification on each packet of data forwarded by the FPGA till all the data packets are received, and then the software moves all the data stored in an SDRAM and burns the data into a FLASH; reading data of the FLASH and source data stored in the SDRAM, and comparing the data and the source data one by one; the method comprises the following steps: reading an Entry Point of a Bin file, turning to circularly read an initial address and length of a program segment, moving effective data by a BOOT program according to data distribution in an mxp file, after all the data are read into a memory, calculating the cumulative sum of the read data, turning to an entry address of an APP program or a BACK program, and realizing booting of the program. The method can be used for improving the online upgrading function of the DSP.

Description

Technical Field

[0001] This application relates to the field of online upgrade technology, and in particular to an online software upgrade method for a DSP chip based on a CAN bus interface. Background Technology

[0002] Online upgrade technology is widely used in field upgrades. Offline upgrades using emulators are more complex, often requiring disassembling the device's debugging port, connecting a debugging board, connecting a computer to the emulator, and using CCS software for offline upgrades. This process requires many tools. Therefore, with online upgrade technology, only one upgrade file needs to be prepared. The file is read by the host computer and sent via the CAN bus interface. The new executable file can then be directly burned into the device's FLASH chip. After power-on, the new program can be rebooted and started using the BOOT program.

[0003] The commonly used method is to split the FLASH segment into BOOT and APP segments. The BOOT segment is permanently stored in the FLASH and remains unchanged, while the APP segment is continuously modified according to different software requirements. Upon power-up, the BootLoader assembler first bootstraps the BOOT segment program, which then boots the APP program. The BOOT segment program is permanently stored in the FLASH; if any abnormalities occur during the upgrade process, an online upgrade can be performed again.

[0004] However, existing DSP chip software upgrades have the following problems: 1) Currently, there are various hardware architectures and interface methods for software upgrades of DSP chips. Upgrades can be performed by directly connecting the DSP chip to various interfaces such as serial ports, Ethernet ports, and SPI ports. Other methods utilize an FPGA+DSP hardware architecture, where the FPGA is directly connected to the aforementioned interfaces, and then the FPGA sends the upgrade data packet to the DSP via the EMIF bus to achieve the software upgrade. Online upgrade methods and hardware architectures differ to some extent, and implementation methods are also diverse. Even with the same interface method, the implementation details vary considerably, lacking a degree of universality.

[0005] 2) Regarding online upgrades of DSP chip software, some upgrade software lacks a backup system. The implementation involves first erasing the source code data in the FLASH memory, and then writing new program data to the original location. This method fails during online upgrades in the field if a sudden power outage occurs. In such cases, an offline upgrade using a simulator is necessary, which is time-consuming and labor-intensive.

[0006] When some software is upgraded online, the program is split into two parts in FLASH: a BOOT segment and an APP segment. If the program selection is incorrect or there is a sudden power outage during the online upgrade, the BootLoader will first start the BOOT segment program and then execute the function of booting the APP program. Summary of the Invention

[0007] In view of this, the present invention provides a method for online software upgrade of a DSP chip based on a CAN bus interface.

[0008] This invention proposes an online software upgrade method for a DSP chip based on a CAN bus interface, comprising: Step 1: Convert the OUT format file generated by compiling the source project into a BIN file; Step 2: The BIN file is split into smaller packets, and the generated data packets are sent to the FPGA. When an online upgrade command is received, the programming software sends an upgrade data packet. The DSP software performs a CRC check on each data packet forwarded by the FPGA. If the check passes, the received data is stored in SDRAM. If the data packet does not meet the CRC check, a CRC check error message is sent to the programming software, which retransmits the data packet. If the CRC check and calculation are successful after retransmission, new data packets are sent until all data packets are received. Then, the software moves all the data stored in SDRAM to FLASH. The data in FLASH is read and compared one by one with the source data stored in SDRAM. If the data is completely consistent, an upgrade success message is reported. If any byte is inconsistent, an upgrade failure message is sent, and the upgrade is re-run. Step 3: Respond to the power-on startup of the BOOT segment program, read the entry point address of the Bin file. If the entry point address is all 0s or all Fs, exit the boot process directly; otherwise, loop through the program segment start address and length. The BOOT program moves the valid data according to the data distribution in the mxp file. After all the data is read into memory, calculate the cumulative sum of the read data and compare it with the cumulative sum of the last 4 bytes of the BIN file. If the cumulative sums match, jump to the entry address of the APP program or BACK program to boot the program.

[0009] In one embodiment, step 1 includes: The OUT format file of the source program generated by compiling the source project using CCS5.5 software; Place the OUT format file, the cmd memory allocation file, and the OutToBin.bat file in the same directory; Execute the OutToBin.bat file to perform batch processing and generate a Bin format file; An accumulation calculation program is executed to add a cumulative sum to the end of the BIN file for subsequent data verification during startup.

[0010] In one implementation, during step 2, when the BIN file is split into multiple packets, the length of each packet is fixed at 128 bytes.

[0011] In one embodiment, in step 2, if the verification passes, the received data is stored in SDRAM with a starting address of 0x80300000.

[0012] In one implementation, the mxp file is an intermediate file generated in step 1. It needs to be opened in Notepad format, and its content represents the data content distribution of the BIN file generated by the OutToBin.bat batch file.

[0013] In one implementation, the BIN file includes: Entry Point, vectors section, text section, switch section, cinit section, text section, const section; Here, Entry Point is the program entry point address, btad is the starting address of the memory segment, dest is the destination address of the memory segment, and size is the size of the segment. Based on the above allocation of segments in memory, the BOOT program first reads Entry Point, then reads the data of size in the vectors segment, and then reads the destination address dest. The program reads the data in a loop according to the above rules until the data of the const segment is read. Then, all the data in the BIN file is moved into memory, thereby realizing the startup boot of the APP program or BACK program.

[0014] In one embodiment, the method further includes: The BOOT program, written in C, directly boots the APP program. If the BOOT program fails to boot the APP program, it boots the BACK program. Once the BACK program successfully boots, the APP program can be upgraded again, thus ensuring that the software always has online upgrade capabilities.

[0015] In one embodiment, the method is applied to a DSP chip platform, specifically including: DSP6416, DSP6713, DSP6455, and DSP6678 chip platforms.

[0016] By adopting the above technical solution, the present invention has at least the following advantages: The method provided by this invention employs a general hardware upgrade architecture based on an FPGA+DSP chip using a CAN bus interface. Furthermore, compared to methods without backup programs, this invention adds a backup system, enabling software upgrades to be performed again in the event of a sudden power outage during field upgrades. The bootloader can also correctly boot the upgraded program into FLASH upon power-up. Additionally, this invention divides the FLASH memory into three parts: a BOOT segment, an APP segment, and a BACK segment. The BOOT segment program is written in C language, facilitating development and maintenance, and replacing the difficult-to-write and read BootLoader program written in assembly language. The APP segment contains the user program, and the BACK segment is the backup program area. The function of the BOOT segment program is to boot either the APP program or the BACK program. The APP program contains all the software functions required by the user. The BACK program only has the single function of re-upgrading the APP segment program. Upon power-up, the BOOT segment program starts first, then boots the APP program. If the APP program fails to boot, the BACK segment program is then booted. Attached Figure Description

[0017] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a schematic diagram of an FPGA+DSP upgrade hardware structure based on a CAN bus according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the Bin file generation process according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the online upgrade process according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the program startup and boot process according to an embodiment of the present invention; Figure 5 A schematic diagram illustrating the memory allocation for generating the mxp intermediate file from OutToBin.bat according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the contents of the Transfer.cmd memory allocation file according to an embodiment of the present invention. Detailed Implementation

[0018] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the present invention will be described in detail below with reference to the accompanying drawings and preferred embodiments.

[0019] While exemplary embodiments of the invention are shown in the accompanying drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the invention and to fully convey its scope to those skilled in the art. The invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0020] This invention provides an online software upgrade method for a DSP chip based on a CAN bus interface, comprising the following steps: Step 1: Convert the OUT format file generated by compiling the source project into a BIN file; Step 2: The BIN file is split into smaller packets, and the generated data packets are sent to the FPGA. When an online upgrade command is received, the programming software sends an upgrade data packet. The DSP software performs a CRC check on each data packet forwarded by the FPGA. If the check passes, the received data is stored in SDRAM. If the data packet does not meet the CRC check, a CRC check error message is sent to the programming software, which retransmits the data packet. If the CRC check and calculation are successful after retransmission, new data packets are sent until all data packets are received. Then, the software moves all the data stored in SDRAM to FLASH. The data in FLASH is read and compared one by one with the source data stored in SDRAM. If the data is completely consistent, an upgrade success message is reported. If any byte is inconsistent, an upgrade failure message is sent, and the upgrade is re-run. Step 3: Respond to the power-on startup of the BOOT segment program, read the entry point address of the Bin file. If the entry point address is all 0s or all Fs, exit the boot process directly; otherwise, loop through the program segment start address and length. The BOOT program moves the valid data according to the data distribution in the mxp file. After all the data is read into memory, calculate the cumulative sum of the read data and compare it with the cumulative sum of the last 4 bytes of the BIN file. If the cumulative sums match, jump to the entry address of the APP program or BACK program to boot the program.

[0021] The method provided in this embodiment will be described in detail below.

[0022] First, this invention proposes a hardware and software architecture design for an online upgrade method based on the CAN bus. The software and hardware required for this method include upgrade software, an FPGA chip, a DSP chip, SDRAM, FLASH, a CAN bus, and an EMIF bus. A block diagram of the components is attached. Figure 1 .

[0023] The CAN bus has the advantages of high reliability, high efficiency, real-time performance, flexibility and low cost. It adopts differential signal transmission, has strong anti-interference ability, supports multi-node communication, and has a priority mechanism to ensure the real-time transmission of high-priority messages, thus meeting the real-time requirements and meeting the low bit error rate requirements for transmitting upgrade data packets.

[0024] The upgrade process is as follows: The upgrade software mainly unpacks and sends the BIN file to be upgraded. The FPGA receives the upgrade data packet sent by the upgrade software through the CAN bus and forwards the upgrade data packet to the DSP through the EMIF bus interface. The DSP then stores it in the static memory SDRAM connected to it. After the upgrade data packet passes the CRC check, the FLASH erasure and writing action is initiated. The DSP then moves the data stored in the SDRAM and writes it to the FLASH until the process is complete.

[0025] Preparations before the upgrade: Step 1: Generating the BIN format upgrade file The source project compiled using CCS 5.5 software generates OUT files, while this method requires BIN executable files. Therefore, a method is needed to convert the OUT files to BIN files. This method uses a batch file to achieve this conversion.

[0026] The specific method involves using the generic Hex6x.exe file and the Transfer.cmd memory allocation file provided by TI, and then calling these two files by running the batch file OutToBin.bat. The contents of the Transfer.cmd file are attached. Figure 6 This converts the OUT file into a BIN file. During the conversion process, an intermediate file in MXP format is generated.

[0027] Since the OutToBin.bat batch file requires the Transfer.cmd memory allocation file and hex6x.exe provided by TI to run, these three files must be placed in the same directory.

[0028] To increase the reliability of the upgrade, the generated BIN file needs to be further processed. This is done by running the Add_Check_Array.exe file, which was written by the software developers. Its function is to read the generated BIN file, calculate a four-byte sum, and append it to the end of the BIN file for subsequent data verification during the boot process.

[0029] Step 2: Online Upgrade Process The online upgrade software is launched. Its main function is to unpack and repackage the BIN file generated in step 1. Each packet has a fixed length of 128 bytes. The data packets are sent to the FPGA via the CAN bus interface. When the software receives the online upgrade command, the programming software sends out upgrade data packets. The DSP software performs CRC verification on each data packet forwarded by the FPGA. If the verification passes, the received data is stored in SDRAM with a starting address of 0x80300000. If the data packet does not meet the CRC verification, a CRC verification error message is sent to the programming software. The programming software will retransmit the data packet. If the CRC verification and calculation are successful after retransmission, new data packets are sent out until all data packets are received. Then, the software moves all the data stored in SDRAM and programs it into FLASH.

[0030] After the programming is complete, the software reads the data from the FLASH memory and compares it with the source data stored in the SDRAM one by one. If the data is completely consistent, a success upgrade message is reported; if any single byte is inconsistent, an upgrade failure message is returned, and the upgrade needs to be performed again. See the attached flowchart. Figure 3 .

[0031] Step 3: Program Startup and Boot Process The BOOT segment program is burned into the FLASH memory starting at address 0x64000000 using a programming program. The BOOT segment program occupies three 128KB blocks. The APP program is burned into the FLASH memory starting at address 0x64060000 and occupies two 128KB blocks. The BACK program is burned into the FLASH memory starting at address 0x640C0000 and occupies two 128KB blocks.

[0032] Upon power-up, the BOOT program starts, first reading the entry point address of the Bin file. If the entry point is all 0s or all Fs, the boot process exits directly; otherwise, it loops through reading the start address and length of the program segment. The BOOT program moves the valid data according to the data distribution in the MXP file. After all data is read into memory, it calculates the cumulative sum of the read data and compares it with the cumulative sum of the last four bytes of the Bin file. If the cumulative sums match, it jumps to the entry address of the APP program or BACK program to boot the program.

[0033] The BOOT program first boots the APP program stored at the starting address 0x64060000. If the cumulative checksum of the data stored in the APP program is consistent with the cumulative sum calculated by the BOOT program after the data is moved and booted, the APP program can start booting and running normally. If the accumulated checksums are inconsistent, the BOOT program will boot from the BACK segment program, which starts at address 0x640C0000. In this case, the accumulated checksums also need to be checked for consistency. If the accumulated checksums match, the BACK segment program boots successfully. Once the BACK segment program boots successfully, the program can then perform online upgrades to the APP segment program. See the attached flowchart for the boot process. Figure 4 .

[0034] The intermediate file in mxp format generated in step 1 can be opened with Notepad. Its contents are shown in the attached file. Figure 5 The content represents the data distribution of the BIN file generated by the OutToBin.bat batch file. The BIN file consists of Entry Point, vectors segment, text segment, switch segment, cinit segment, text segment, and const segment. EntryPoint is the program entry point address, btad is the starting address of the memory segment, dest is the destination address of the memory segment, and size is the size of the segment. According to the above segment allocation in memory, the BOOT program first reads the Entry Point, then reads the data of size in the vectors segment, and then reads the dest destination address. The program reads the data in a loop according to the above rules until the data of the const segment is read. Then, all the data in the BIN file is moved into memory, thereby realizing the startup boot of the APP program or BACK program.

[0035] Compared with the prior art, this embodiment has at least the following advantages: 1) This invention proposes an FPGA+DSP online upgrade hardware architecture based on CAN bus; 2) This invention proposes a three-segment FLASH structure, which includes a BOOT program, an APP program, and a BACK program. The method of using the BOOT program to guide the APP program or the BACK program to start ensures that there is always software running normally in the module, thereby ensuring that the software can have online upgrade functionality at any time. 3) This invention provides a program data transfer method that enables precise transfer of valid data, saves startup time, and enables rapid program startup. 4) The embodiments of the present invention have designed and adopted multiple verification methods in the upgrade process, including three verification methods: CRC verification, cumulative sum verification, and byte-by-byte comparison of BIN format files, thereby ensuring the success rate of online software upgrades; 5) The upgrade method of this invention has strong versatility and can be adapted to a variety of different DSP chip platforms.

[0036] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims. All of these forms are within the protection scope of this application.

Claims

1. A method for online software upgrade of a DSP chip based on a CAN bus interface, characterized in that, include: Step 1: Convert the OUT format file generated by compiling the source project into a BIN file; Step 2: The BIN file is split into packets, and the generated data packets are sent to the FPGA. When an online upgrade command is received, the programming software sends an upgrade data packet. The DSP software performs CRC verification on each data packet forwarded by the FPGA. If the verification passes, the received data is stored in SDRAM. If the data packet does not meet the CRC verification, a CRC verification error message is sent to the programming software. The programming software will retransmit the data packet. If the CRC verification and calculation are successful after retransmission, new data packets are sent. After all data packets are received, the software moves all the data stored in SDRAM and programs it into FLASH. The data in the FLASH memory is read and compared one by one with the source data stored in the SDRAM. If the data is completely consistent, an upgrade success message is reported. If any single byte is inconsistent, an upgrade failure message will be sent, and the upgrade will be performed again. Step 3: Respond to the power-on startup of the BOOT segment program, read the entry point address of the Bin file. If the entry point address is all 0s or all Fs, exit the boot process directly; otherwise, switch to a loop to read the start address and length of the program segment. The BOOT program moves the valid data according to the data distribution in the mxp file. After all the data is read into memory, calculate the cumulative sum of the read data and compare it with the cumulative sum of the last 4 bytes of the BIN file. If the sums match, the program is redirected to the entry address of the APP or BACK program to boot and start the program.

2. The online software upgrade method for a DSP chip based on a CAN bus interface according to claim 1, characterized in that, Step 1 includes: The OUT format file of the source program generated by compiling the source project using CCS5.5 software; Place the OUT format file, the cmd memory allocation file, and the OutToBin.bat file in the same directory; Execute the OutToBin.bat file to perform batch processing and generate a Bin format file; An accumulation calculation program is executed to add a cumulative sum to the end of the BIN file for subsequent data verification during startup.

3. The online software upgrade method for a DSP chip based on a CAN bus interface according to claim 1, characterized in that, In step 2, during the process of disassembling and repackaging the BIN file, the length of each packet is fixed at 128 bytes.

4. The online software upgrade method for a DSP chip based on a CAN bus interface according to claim 1, characterized in that, In step 2, if the verification passes, the received data is stored in SDRAM with a starting address of 0x80300000.

5. The online software upgrade method for a DSP chip based on a CAN bus interface according to claim 2, characterized in that, The MXP file is an intermediate file generated in step 1. It needs to be opened in Notepad format. Its content represents the data content distribution of the BIN file generated by the OutToBin.bat batch file.

6. The online software upgrade method for a DSP chip based on a CAN bus interface according to claim 1, characterized in that, The BIN file includes: Entry Point, vectors section, text section, switch section, cinit section, text section, const section; Here, Entry Point is the program entry point address, btad is the starting address of the memory segment, dest is the destination address of the memory segment, and size is the size of the segment. Based on the above allocation of segments in memory, the BOOT program first reads Entry Point, then reads the data of size in the vectors segment, and then reads the dest destination address. The program reads the data in a loop according to the above rules until the data of the const segment is read. Then, all the data in the BIN file is moved into memory, thereby realizing the startup boot of the APP program or BACK program.

7. The online software upgrade method for a DSP chip based on a CAN bus interface according to claim 1, characterized in that, The method further includes: The BOOT program, written in C, directly boots the APP program. If the BOOT program fails to boot the APP program, it boots the BACK program. Once the BACK program successfully boots, the APP program can be upgraded again, thus ensuring that the software always has online upgrade capabilities.

8. The online software upgrade method for a DSP chip based on a CAN bus interface according to claim 1, characterized in that, The method is applied to DSP chip platforms, specifically including: DSP6416, DSP6713, DSP6455, and DSP6678 chip platforms.

Images