TI's high-speed digital signal processor TMS320C6000 series DSP supports parallel processing and adopts a very long instruction word (VLIW) architecture. It has 8 functional units (two multipliers and 6 ALUs) inside. The 8 functional units can operate in parallel and can execute up to eight 32-bit instructions simultaneously in one cycle. The instruction operation is a "pipeline" working mode. The application of high-performance DSP can greatly improve the performance of data-intensive application systems, and can quickly complete digital signal processing such as filtering, convolution, FFT, or perform more complex operations. It has a good application prospect in modern signal digital processing. Due to the difference in internal structure, the boot mode of TMS320C6000 series and TMS320C54 series is very different. When developing and applying TMS320C6000 series DSP, many developers, especially beginners, have some difficulties in implementing DSP ROM booting and spend a lot of time and energy to explore. The author introduces the specific method of implementing external memory booting in combination with development examples. DSP booting process DSP system booting (BOOT) means that when the system is powered on or reset, the DSP copies a section of program code stored in the external non-volatile memory to the internal high-speed memory through DMA to run. This can not only expand the limited storage space of the DSP, but also give full play to the efficiency of the internal resources of the DSP. The user's code can also be written into the internal ROM of the DSP through the mask method, but this is limited by capacity and price, and is not convenient for expansion and upgrading. The boot process of DSP is as follows: 1) After DSP is reset, it reads the data in the external CE1 space into the internal program space address 0 through DMA. The amount of data read varies from chip to chip (TMS320C6712 only copies 1KB at a time). 2) DSP exits the reset state and starts to execute the program at the internal program space address 0. This program first reads the external main program data into the corresponding address of the DSP internal program space, and then jumps to the main program to run. The first step is automatically completed by the chip, and the key is the second step: the user needs to write the corresponding assembly program to realize the secondary boot, that is, the loading of the user's main program. Analysis of the causes of boot failure (1) Link command file (.cmd) file The link command file defines the link parameters, describes the segment names of the executable code segments generated by the system and maps them to the physical space of the target board. When the starting address or segment length of these segments is written incorrectly, the boot program may fail. (2) Binary file format of executable code The user's program is compiled in the COFF file format under the CCS development environment. The COFF file can be directly loaded and run during the simulation process. However, when the debugging simulation passes, if the target board needs to run independently without the CCS environment, the executable code needs to be converted into a binary file format and saved in the external memory of the target board. The correct configuration file needs to be used during conversion. (3) Hardware circuit of the target board (boot mode, system clock) The hardware circuit of the target board will also affect the normal operation of the boot program, such as the boot mode set does not match the actual external memory, the system clock circuit does not work, the reset signal is always valid, etc. The following is a detailed introduction to the implementation of external memory booting based on the development example of TMS320C6212. ROM boot example TMS320C6212 is a simplified version of TMS320C6201 chip, with relatively fewer internal resources and relatively low operating frequency, but it is inexpensive and has a high performance-price ratio. The operating frequency of TMS320C6212 can reach 150MHz, and the maximum processing power is 900MIPS, which is very suitable for the development of small and medium-sized systems. Since FLASH is a high-density, non-volatile electrically erasable memory, the system uses FLASH as an external memory. In addition to the dedicated hardware programmer that can write binary code into FLASH, it can also be written through software programming using the DSP debugging system. The interface connection between DSP and FLASH is shown in Figure 1. System engineering uses C language programming in the CCS development environment, which can shorten the development cycle, improve work efficiency, and has the advantage of good portability. (1) Interrupt vector table vectors.asm The interrupt vector table is saved in the 0x200 byte space starting from address 0 of the internal RAM of the DSP chip by default. After power-on or reset, the chip automatically runs the reset interrupt. Therefore, the reset interrupt vector is set to the entry address of the boot program (_boot), and the main body of the boot program is defined in boot.asm. Part of the program is as follows: .ref _boot ;Call the boot program .sect “.vectors” ;Segment declaration RESET_RST: ;Reset interrupt vector mvkl .S2 _boot, B0 ;Load the boot program address mvkh .S2 _boot, B0 B .S2 B0 ;Jump to the boot program execution NOP 5 (2) The self-booting assembler boot.asm The self-booting assembler mainly configures the basic registers and copies the binary program stored in the external FLASH to the RAM inside the DSP for execution. Since TMS320C6712 automatically copies 1KB, the starting address starts from 0x400. The assembler is as follows: .sect “.boot_load”; define the data segment .ref _c_int00 ;declare external function .global _boot ;define global function _boot: ;set control registers first, such as EMIF_GCR, etc. (omitted) ;copy the program in FLASH to DSP internal RAM mvkl 0x00000400, A4 ;A4 is RAM address pointer || mvkl 0x90000400, B4 ;B4 is FLASH address pointer mvkh 0x00000400, A4 || mvkh 0x90000400, B4 zero A1 ;A1 is used as a counter _boot_loop: ;DSP starts reading the program in FLASH ldb *B4++, B5 mvkl 0x0000F200, B6 ;B6 is the number of bytes to be copied add 1, A1, A1 || mvkh 0x0000F200, B6 cmplt A1, B6, A0 nop stb B5, *A4++ [B0] b _boot_loop [size= 4]nop 5 mvkl .S2 _c_int00, B0 ; After the loop ends, jump to the main function main for execution mvkh .S2 _c_int00, B0 B .S2 B0 Nop 5 (3) Main program main.c The main program is the main body to implement specific functions of DSP. The main function main() defined in it is called in function _c_int00 after compilation. Therefore, at the end of the above boot program, it will jump to function _c_int00, that is, the main function main will be executed. (4) The link command program link.cmd is used to define the address and size of each memory in the system and allocate each segment after compilation to the corresponding storage space. The content of link.cmd is as follows: -c -lrts6201.lib MEMORY {vecs: o = 00000000h =00000200h; BOOT_RAM: o = 00000200h l = 00000200h IRAM: o = 00000400h l = 0000c400h CE0: o = 80000000h l = 01000000 h CE1: o = 90000000h l = 00100000h } SECTIONS { .vectors > vecs fill = 0 .boot_load > BOOT_RAM fill = 0 .text > IRAM fill = 0 .stack > IRAM fill = 0 [size=4 ].bss > IRAM fill = 0 .cinit > IRAM fill = 0 .far > IRAM fill = 0 .sysmem > IRAM fill = 0 .cio > IRAM fill = 0 } (5) Conversion command program convert.cmd The above project files are compiled and assembled by the CCS system to generate executable COFF files (.out). It needs to be converted into binary files and then written into FLASH. The CCS development system comes with a conversion program: hex6x.exe Convert executable COFF files (.out) to hexadecimal files (.hex) hex2bin.exe converts a hexadecimal file (.hex) to a binary file (.bin) The format of the command line is: hex6x.exe convert.cmd hex2bin.exe mboot The content of convert.cmd is as follows: mboot.out; input file name.out format -x -map mboot.map; generate mapping file -image -memwidth 8 ; Memory bit width -o mboot.hex ; Output file name.hex format ROMS { FLASH: org = 0, len = 0x10000, romwidth = 8 } Conclusion To sum up, it is not complicated to realize the external memory self-boot of TMS320C6712. The key is to understand the self-boot process of the chip and the role of each part after the program is assembled, configure the actual physical address of the boot code segment and the program code segment, and correctly initialize the corresponding registers and variables.