Online Upgrade Method of DSP Application Program Based on Serial Communication

灞波儿奔

Online Upgrade Method of DSP Application Program Based on Serial Communication [Copy link]

The TMS320C2000 series DSP is a DSP series launched by Texas Instruments (TI) in the United States that combines the features of microcontrollers and high-performance DSPs. This series of DSPs has powerful control signal processing capabilities [1] and can implement complex control algorithms. With the continuous development of electronic technology and the continuous improvement of user needs, it may be necessary to frequently update the programs of embedded devices that have been put into use. The current general program upgrade method is to remove the device on site, expose the JTAG port, and then update the program through the emulator [2-4]. Although this method is simple and effective, it will bring great inconvenience to program upgrades in some special occasions [2]. Taking TMS320F28035 as an example, this paper describes a method for online updating of TMS320C2000 series DSP applications without changing the DSP power-on startup mode without using the JTAG emulator.
1 Basic idea of online upgrade
Generally, DSP-based software program updates are implemented through JTAG interface operations in the CCS environment. Although the method based on the JTAG interface is easy to operate and convenient to debug, it is often limited by space and transmission distance. For example, if a DSP system is installed in a complex and closed environment, when the program needs to be updated or upgraded, it is difficult to achieve online program upgrade using the JTAG interface [3]. The online upgrade technology based on serial communication achieves the purpose of program upgrade by burning the application program with the underlying program. This method is not limited by complex systems and complex environments. In addition, the online upgrade method does not need to change the DSP startup method, and directly uses the DSP's default internal Flash method to start [5], thus eliminating the trouble of hardware settings for some DSP pins. The underlying program refers to the program that has been solidified in the DSP's designated Flash space and is not allowed to be modified or erased by the user. It is mainly used to implement online upgrade timing judgment, data reception, and code burning functions. The Flash2803x_API stock function (see Section 2.2 for details) is used in this program; the application program is the user's upgrade program [3].
Every time the F28035 DSP is powered on and reset, it first runs the underlying program to establish a connection with the PC, and then determines whether the application needs to be upgraded based on the PC's instructions. If necessary, the application code sent through the serial port will be burned into the specified sector of the F28035 on-chip Flash; otherwise, the original application will continue to execute. When the application is large or the RAM space of the DSP is relatively small, the application code can be sent to the DSP in batches. After the DSP receives and burns a batch of code, it will receive and burn the next batch of code until all the application codes are burned.
2 Specific implementation of online upgrade
2.1 Application
The user's application is compiled and linked by CCS to generate a target file (.out) with a modular format. The code and data in this file are stored in different segments, so it cannot be used directly to burn Flash. It needs to be converted into a data format that Flash can recognize - a binary file (.bin). This article uses hex2000.exe and FileOshell.exe tools to implement file conversion. First, the application is compiled and linked to generate a .out file, and then the .out file is converted into a .hex file through hex2000.exe, and then the file is converted into a .bin file through FileOshell.exe. First, make a batch file with the following content:
Example_2803xAdcSoc.out
-map Example_2803xAdcSoc.map
-o Example_2803xAdcSoc.hex
-m
-memwidth 16
-image
ROMS
{
Flash28035: origin = 0x3e8000, len= 0x1000, romwidth=
16, fill=0xFFFF
}

Among them, Example_2803xAdcSoc.out is the file generated by the application through CCS; -map is the generated map file; -o is the generated hex file; -m is the Motorola-S format; -memwidth 16 means the memory bit number is 16 bits; -image means selecting the image file; ROMS is the starting address, length, bit number and padding to be converted. This article chooses to start from 0x3e8000, the length is 4 KB, that is, FlashH, and the unused part of FlashH is filled with 0xFFFF. This article names this batch file: Example_2803xAdcSoc.cmd. Next, to generate a .bin file, first make an MS-DOS batch file, its content is as follows: IFileIOShell.exe -i Example_2803xAdcSoc.hex -o Example_2803xAdcSoc.bin
Note that Example_2803xAdcSoc.out, hex2000.exe, FileIO
Shell.exe, Example_2803xAdcSoc.cmd and MS-DOS batch file should be placed in the same directory, and then double-click the MS-DOS batch file to generate the required Example_2803xAdcSoc.bin file.
2.2 Low-level program
The low-level program is used to burn the data sent by the serial port into the specified part of the Flash. It involves the correct positioning of the application and the startup process after reset, and is the key to the entire online upgrade. The low-level program flow chart is shown in Figure 1. The low-level program mainly implements the following functions [3]:

(1) Power-on reset query function. After power-on reset, the command sent by the host computer is received to determine whether to upgrade. If the host computer sends an upgrade command, it will jump to the upgrade part of the underlying program for execution; otherwise, it will jump to the original application program for execution.
(2) Function of moving the burning program. Since the on-chip Flash of F28035 does not support running a program in one sector to erase or burn other sectors, the part of the program that completes the work of receiving data and burning Flash (that is, the upgrade part of the underlying program) needs to be moved to the on-chip RAM or off-chip RAM for execution. The function for implementing program migration is:
void MemCopy (Uint16 *SourceAddr, Uint16 *Source End
Addr, Uint16 *DestAddr)
{
while (SourceAddr < SourceEndAddr)
{
*DestAddr++ = *SourceAddr++；
}
return ；
}
Where SourceAddr is the starting address of the upgrade program in Flash, SourceEndAddr is the ending address of the upgrade program in Flash; DestAddr is the first address to be moved to the memory.
(3) Receive the application code sent by the host computer and save it to
the memory specified by DSP (usually RAM area). This is achieved through the serial port RS232. And make sure that this part of the memory used for data storage is not occupied. For example, if you need to temporarily store the application code in the L0 SARAM area of F28035 (address space 0x3F8000-0x3F8800). Define the array Uint16 BlockBuffer[2048] to store the application code. Use the memory positioning statement in the bottom-level program to locate the above buffer array to the corresponding storage space:
#pragma DATA_SECTION(BlockBuffer, "BlockTransferbuffer");
In the bottom-level program CMD file, use the positioning statement to locate BlockTransferbuffer to the L0 SRAM space of DSP:
BlockTransferBuffer:> L0 SARAM PAGE=2
//Address space: 0x3F8000~0x3F8800
Through the above bottom-level program settings, the application can be cached in the specified RAM area.
(4) After the code is received, the code in the memory is burned to the specified Flash sector. This step is completed by calling the Flash2803x_API library function. The Flash2803x_API library functions used in the underlying program are as follows [6]:
① The function for erasing a sector is Uint16 Flash28035_Erase(Uint16 SectorMask, &Fstatus), where SectorMask is the sector to be erased; &Fstatus is the status value returned after the erase operation is performed, which is used to determine whether the erase operation is successful. ② The function for burning the program to the Flash sector is Uintl6 Flash28035_Program(&FlashAddr, &BuffAddr, Length, &Fstatus), where &FlashAddr is the starting address of the Flash sector to be burned; &BuffAddr is the first address of the program to be burned currently stored in the memory space; Length is the program length; &Fstatus is the status value returned after the burn operation is performed, which is used to determine whether the burn operation is successful. ③ The verification program burned into the Flash is Uint16 Flash28035_Verify (&FlashAddr, &BuffAddr, Length, &Fstatus), where &FlashAddr specifies the first address to be compared from the Flash; &BuffAddr is the storage first address of the file to be compared; Length is the number of 16-bit words to be compared, the program length; &Fstatus is the status value returned after the verification operation is executed, which is used to determine whether the verification operation is successful.
2.3 Positioning of the bottom-level program and application program
After the DSP F28035 is powered on and reset, the CPU will obtain the reset vector from the internal Boot Rom. The reset vector points to the Boot Rom and executes its internal Bootloader program. After the execution is completed, it is determined to start from the internal Flash. The program pointer jumps to 0x3F7FF6 of the Flash. Since this address is fixed, the bottom-level program must be burned into the space with this address as the starting address. DSP enters the bottom software program and runs. First, it receives the command from the host computer to determine whether to perform online upgrade. If online upgrade is performed, it jumps to the corresponding upgrade program for execution; otherwise, it jumps to the original application for execution. When jumping from the bottom program to the original application for execution, an absolute address jump is used. Part of the program is as follows:
#define Jumpgxcx (void (*)(void))0x3E8FFE
//Define the jump address of the application
SCI_SendStatus(“upgrade program? (y/n):”)
//Ask the host computer whether to upgrade
temp = SCIA_GetByteData_app();
//Receive the upgrade command sent by the host computer
if (temp=='y')
{
main2(); //If upgrade, jump to the upgrade program for execution
}
Else
{
(*Jumpgxcx)();
//If not upgrade, use the absolute address to jump to the application for execution
}
}
The cmd configuration of the bottom program should be consistent with the cmd configuration of the application, and no address conflict should occur. At the same time, pay attention to the jump address configuration of the bottom program and the application.
The configuration of the bottom-level program cmd file is as follows:
BEGIN: origin = 0x3F7FF6, length = 0x000002
RESET: origin = 0x3FFFC0, length = 0x000002 /*
codestart: > BEGIN PAGE = 0
The configuration of the application cmd file is as follows:
BEGIN: origin = 0x3E8FFE, length = 0x000002
codestart: > BEGIN PAGE = 0
3 Burning steps
First, burn the bottom-level program into F28035 through the JTAG interface, and then burn the application. The burning steps of the application are: first configure the parameters of the serial port debugging tool to baud rate 9600 bit/s, 8 bit data bit, 1 bit stop bit, no parity bit; select the text file sending method, and send the application .bin file to DSP. Since the RAM area of F28035 is relatively small, the application code can be sent in multiple times.