How to enable high performance of TMS320C62xx in wireless transmission technology

Aguilera

How to enable high performance of TMS320C62xx in wireless transmission technology [Copy link]

1 IntroductionIn the large-capacity wireless transmission technology with extremely low spectral density and high spectrum utilization, high-speed real-time signal processing has become the key technology. Currently, the devices on the market that can meet the needs of high-speed real-time signal processing and have good programmability mainly includeDSP and FPGA. The TMS320C6000 series DSP is a high-performance digital signal processor launched by TI, including two series: fixed-point and floating-point. The fixed-point series includes TMS320C62xx and TMS320C64xx, and the floating-point series includes TMS320C67xx. The C6000 series DSP has three startup modes: (1) Host startup If the host startup mode is selected, after the reset signal ends, the CPU of the DSP is internally "blocked" and the other parts are released. During this period, an external host can initialize the CPU's memory space through the host interface if necessary, including configuring the internal registers related to startup. Once the host has completed all necessary initialization, it must set the DSPINT bit of the HPIC register to "1" to complete the startup process. After the program is loaded, the CPU is awakened from "blocking" and then executes instructions from address 0. After the CPU is awakened, the CPU needs to clear the DSPINT bit [1]. (2) ROM startup If the ROM startup mode is used, the C6000 series DSP (C621x/C671x/C64x) automatically copies 1K bytes of code from the beginning of the CE1 space to the memory space after reset. The copy process is completed by EDMA, using the default Rom clock. During this process, the CPU is always in a "blocked" state until the copy is completed, and then it is awakened and starts executing the program from address 0 [1]. (3) No boot If the no boot mode is selected, the CPU starts executing instructions directly from address 0 after reset. The device configuration of the C6000 series DSP determines the selected boot mode. Specifically, it refers to whether the DSP's boot mode pins are connected to pull-up or pull-down resistors. Taking C6416 as an example, BEA[19:18] is the boot mode pin. The meanings of different values (pull-up resistor represents "1", pull-down resistor represents "0") are shown in Table 1-1: http://www.logicdsp.com/data/attachment/forum/201307/13/190115vih77hgtfhfpk3ph.jpg If the DSP program is less than 1K bytes, the above ROM boot mechanism can complete the program loading. However, in fact, most DSP programs are larger than 1K bytes. In this case, a specific boot program needs to be created to complete the loading of more code. This specific boot program is also called a secondary bootloader[2]. In programs that require a secondary bootloader, this specific boot code usually resides at the beginning of the ROM memory so that it can be automatically loaded to memory address 0 after the DSP is reset. When the 1K byte code is loaded, the CPU starts to execute from address 0, that is, to execute the content of the secondary bootloader. The function of the secondary bootloader is to copy the rest of the program to the memory. 2 Design and implementation of the boot method The implementation of the DSP boot method using the secondary bootloader is generally divided into four steps: configure the memory; write the secondary bootloader code; compile the program and convert the format of the target file; burn the program into the Flash. Figure 1 is a schematic diagram of the hardware platform for implementing the boot method, where the DSP model is C6416 and the Flash model is AM29LV800B. In order to implement ROM boot using the secondary bootloader, the Flash needs to be divided into two areas: FLASH_BOOT and FLASH_REST. These two areas store the program segments copied by the on-chip bootloader and the program segments copied by the secondary bootloader respectively. For BIOS programs, the memory segment is defined in the MEM (Memory Section Manager) object. For non-BIOS programs, the memory segment is defined in the linker command file. An example of the memory segment definition for C6416 is shown below: 2.1.2 Location of COFF segments DSP programs are stored in memory in the form of COFF segments. A COFF segment is a block of code or data that occupies continuous space in memory. COFF segments are divided into three types: custom segments, initialized segments, and uninitialized segments. COFF segments can have various attributes, among which the load attribute and run attribute are closely related to DSP startup. The load attribute indicates the storage address of the segment, and the run attribute indicates the execution address of the segment. The secondary bootloader is responsible for copying all segments from the load address to the run address. For example: .text: LOAD= FLASH,RUN= IRAM indicates that the code segment .text is stored in the flash. When the DSP starts, the secondary bootloader copies the segment to IRAM. 2.2 Write the Secondary Bootloader Code For C6416, the external memory interface (EMIF) needs to be correctly configured before accessing the external memory device. After this work is completed, the secondary bootloader should copy all the initialization segments from their load addresses to the run address, and then jump to _c_int00, which is the program entry point. The Secondary Bootloader is written in assembly language because the C environment has not yet been established. The second-level bootloader must know the size of all the initialization segments, where they are stored in the Flash, and where they should be loaded to make the correct copy. In fact, the second-level bootloader obtains the above information by reading the segment copy table. The third part of this article details the contents of the segment copy table. After the second-level bootloader code is written, it should be added to the project and compiled and linked with the other code of the project to generate a .out file. 2.3 Converting the format of the target file The compilation and linking generates a .out format file, while the Flash generally receives an ASCII format file [3]. The included tool hex conversion utility can convert .out files into ASCII .hex files. Hex6x is executed as a command line file. In the Hex command line file, first specify the input file (.out), the format of the output file, the size and type of the ROM, and which segments need to be placed in the ROM. An example of a Hex command line file is shown below (comments are enclosed in “/*” and “*/”): 2.4 Burn the program into Flash To burn the ASCII file generated in Section 2.3 into Flash, you can use the FlashBurn tool that comes with CCS. FlashBurn is a software with a graphical interface. It first downloads a program called FlashBurn Target Component (FBTC) to the DSP memory, and completes the erasing and programming of the Flash through real-time data exchange with FBTC. Modifying FBTC for different hardware (DSP, Flash model) is the key to this method. The required modifications include the base address, size, and read and write command words of the Flash. 3 Segment copy table The secondary bootloader uses a section copy table to copy segments. The segment copy table contains the necessary information for each segment to be copied, such as the load address of the segment, the run address of the segment, and the size of the segment. The segment copy table is inserted at the end of the secondary bootloader. There are two ways to generate a segment copy table: 1) Use the -boot option of the hex conversion utility. In Section 2.3, we discussed the conversion of program file formats and hex command line files. In fact, the hex conversion utility tool that comes with Code Composer Studio provides a more convenient way to generate a segment copy table. Just use some special options in the hex command line file. Special options include –boot, ?bootorg and –bootsection. The meanings of these three options are as follows: -boot When using this option, the hex conversion utility will automatically convert the format of all initialization segments. -bootorg specifies the address of the segment copy table. -bootsection specifies the name of the segment where the secondary bootloader is located. 2) Use linker options (LOAD_START, RUN_START, SIZE) There are three options related to the generation of the segment copy table: LOAD_START, RUN_START and SIZE, which can respectively obtain the resident address, running address and size of a segment. For example, the following code can obtain the resident address of the text segment (stored in _text_ld_start), the running address (_text_rn_start) and the size of the segment (stored in _text_size) .text : load = FLASH_REST, run = IRAM LOAD_START(_text_ld_start), RUN_START(_text_rn_start), SIZE(_text_size) 4 Conclusion This paper proposes a method to start DSP from Flash using a secondary bootloader in the case of C6000 series DSP application program larger than 1K bytes in the research of large-capacity wireless transmission technology with extremely low spectral density and high spectrum utilization. This method can be applied to embedded systems using C6000 series DSP, does not require an additional Flash programmer, and has wide applicability.