Design and Implementation of Secondary Bootloader for TMS320C6000 Series

introduction

With the widespread application of DSP (digital signal processor) systems, the size of their programs is also expanding. Using the chip's own Boot-loader to boot the DSP program through the Flash memory is often restricted by the size and structure of the program. For example, the program is too large to fit the manufacturer's fixed boot range, and the different positions of the interrupt vector table affect the program boot jump, etc. Therefore, a more flexible boot method is increasingly needed.

After the system is powered on, the boot program will boot the DSP application program from the memory to the high-speed memory (such as internal SRAM, SDRAM, etc.) on the DSP application board. Since the Flash memory has the function of deleting electrical signals, and has a fast deletion speed and high integration, it has become the first choice for this type of memory. Since the access speed of the Flash memory is slow, the program written to the Flash memory will be loaded into the fast memory by the DSP when the system is powered on. This process is called the Boot loader. Different DSPs have different boot modes. Taking TI's TMS320C6000 series chip as an example, there are three boot modes: No Boot, the CPU directly starts to execute the instructions at address 0; Host Boot, after the system is reset, the host initializes the DSP's storage space through the CPU's HPI (host programming interface); ROM Boot, the DMA controller copies the address 0 of the fixed-length program from the CEl space, and then starts execution from address 0. For 620x/670x DMA, 64 kB of data is copied from CEl to address 0; while for 621x/671x EDMA, 1 kB of data is copied starting from CEl address to address 0.

Many documents have introduced the secondary bootloader of TI's C6000 chip, including the PLL and EMIF settings of the secondary bootloader, the settings of the migration table and the flash memory burning process, but there are few documents on the implementation of the secondary bootloader with an interrupt vector table. This paper takes the TMS320C6000 series chip, a representative of TI's high-performance DSP, as an example to introduce a new approach to the secondary bootloader with an interrupt vector table, thus providing a new idea for the development of the TMS320C6000 series DSP. This method has been applied in practice, and the system runs stably and reliably.

1 Secondary Bootload Process

TMS320C6713 is the latest chip in the TMS320C67xx series floating-point DSP launched by TI. TMS320C6713 can execute 8 32-bit instructions per cycle; supports 32/64-bit data; has a maximum operating speed of 225 MHz and a processing capacity of 1800 MIPs (million operations per second) or 1350 MFLOPS (million floating-point operations per second); and has powerful peripheral support capabilities; EMIP (external memory interface) can be easily connected to synchronous and asynchronous memories such as SDRAM, SBSRAM, Flash memory, SRAM, etc., and the 16-bit EHPI interface can be interfaced with various processors; in addition, there are optimized multi-channel cache serial ports and multi-channel audio serial ports. These external interfaces enable designers to easily implement their own application systems.

When the ROMBoot mode is selected, after RESET changes from low to high, the CPU core of C6713 is in reset state, and the other parts of C6713 start to work. At this time, the CEl space of EMIF is automatically configured as an 8/16/32-bit asynchronous memory interface according to the ROM Boot mode, and the CEl space read/write timing is automatically configured to the maximum, and then the first 1 kB of the CEl space is copied to the address 0x0000 0000. This 1 kB of data is used to boot other programs. For programs with interrupt vector tables set at 0x0000 0000 to 0x0000 0400, the 1 kB data contains not only the EMIF setting code and the moving program, but also the interrupt vector table. This article focuses on the process of Bootloader with interrupt vector table, and the starting address of the interrupt vector table is 0x00000000. If the program length is less than 1 kB, then there is no need for a secondary bootloader, but the program length is often greater than 1 kB, so a secondary bootloader is an inevitable process.

The implementation of the secondary bootloader requires the introduction of EMIF settings and migration programs, that is, writing three files: boot_c671x_2.s62, c6713_emif.s62, lnk2.cmd and boot.cmd. This article uses the program to implement a multi-channel buffered serial port as an example, and the process diagram of implementing the secondary bootload is shown in Figure 1.

First, call in the debugged user program project file MeBSP_test.pjt project as a routine, and then introduce 3 files into this project file.

After the program is written, three very important files need to be introduced; EMIF value definition file (c6713_emif.s62); EMIF settings and data migration program (boot_c67lx_2.s62); cmd configuration file (lnk2.cmd). At the same time, the original mcbsp.cmd file should be removed. Figure 2 makes a comparison. Figure 2 (a) is the original program, Figure 2 (b) is the program for generating the data to be burned, and three files are added to Figure 2 (b), and the original mcbsp.cmd is removed. Among them, boot_c67lx_2.s62 is universal, and c6713_emif.s62 needs to configure the EMIF parameters according to the specific actual chip. [page]

The boot_c671x_2.s62 file contains the .boot_load function, which contains several processes, as shown in Figure 3. The c6713_emif.s62 file contains several EMIF parameter configurations. The ink2.cmd file is the COFF configuration.

Secondly, use the tool Hex6x.exe that comes with the CCS development environment to convert the *.out file generated by the project into hex format. In the DOS environment, the command is >Hex6x.exeboot.cmd.

Finally, according to the requirements of the Flash memory chip, the hex file can be burned to the specified address in the Flash memory. The AM29LV800BB-70ecFlash memory chip used in this example is powered by 3.3 V, is fully compatible with the JEDEC standard, and supports in-system programming. Users only need to write command sequences to its internal command register to implement partial erase, full erase, data write and other functions; at the same time, hardware and software methods can be provided to check the operation execution of the Flash memory. First, the chip needs to be erased and all changed to 0xFFFF, and then burned. Since the Flash memory is accessed in 16 bits, the physical address of the Flash memory is addressed in 16-bit units, and the logical address used in the program is addressed in bytes. The relationship between the two is as follows: logical address = physical address << 1, so there is an address offset in the program. The burning program is given below.

2 Implementation of Secondary Bootloader with Interrupt Vector Table

Section 1 introduces the general secondary bootload process, but when you need to boot a program with an interrupt vector table, you need to carefully consider the programming of three important files, otherwise you will encounter unexpected consequences. [page]

2.1 Configuration file Ink2.cmd

Ink2.cmd is slightly different. There is an interrupt vector table now, so the allocation space of vectors must be considered when allocating. The difference in the configuration file is mainly in the Memory section. The following is the section:

SECTIONS

The differences in MEMORY are as follows:

a) Part of the program that does not consider the interrupt vector table configuration:

b) Consider the partial program of interrupt vector table configuration:

.vectors is the interrupt vector table, which has a length of 0x200 data and must be placed at the address 0x90000000, and .boot_load is placed immediately afterwards.

2.2 Interrupt vector table file vec.asm

Another very important point is the change of vec.asm file in Figure 2. When debugging the program, the interrupt vector table will jump directly to c_int00 at the beginning, but the first 1 kB data to be burned must first go through the EMIF setting and moving process, so its pointing needs to change.

Part of the vecter.asm program is as follows:

a) The vecter.asm part of the original program:

[page]

b) The vecter.asm part of the program that generates Bootload data:

In the above program, program a) starts by pointing to c_int00, and program b) points to _boot, which is the entrance of .boot_load(). This is because the program starts to execute after the 1 kB program is copied. First, the secondary boot program, that is, the entry point _boot, should be executed. After the secondary boot is completed, the normal initialization C language environment code is executed, and then jumps to the user main function. The .out file generated at this time is converted into data that can be burned through hex6x.exe.

2.3 Convert data configuration file boot.cmd

The boot.out file can be converted into boot.hex format through hex6x.exe, which is convenient for burning into the Flash memory. At this time, Boot.cmd should also be changed accordingly, and the interrupt vector table program, .boot_load program, program segment, and data segment should be converted as well.

The boot.cmd configuration program is as follows:

a) The boot.cmd configuration without considering the interrupt vector table:

b) Consider the interrupt vector table boot.cmd configuration:

In the above program, len can be modified according to the actual program length. If hex6x.exe boot.cmd is used for conversion, a warning will be generated when the program length is too short. At this time, you can check the map file to see the space occupied by the program and data to determine the size of len, as long as len is greater than the actual program length. Romwidth is determined according to the number of bits of the Flash memory used. If it is 8 bits, write 8, and if it is 16 bits, change it to 16. In the above program, the difference between program b) and program a) is that .vectors is added, so that the address 0x0000 0000 in the generated boot.hex file is the program of vectors. The *.hex file generated at this time can be burned into Flash.

3 Conclusion

This article takes TI's high-performance DSP TMS320C6000 series chip as an example to introduce a new way to boot from Flash memory and a secondary Bootloader with an interrupt vector table. The specific differences in the parts of the Bootloader program that need to be rewritten are described in detail, thus providing a new idea for the development of TMS320C6000 series DSP. This method is simple and feasible. In the documents provided by TI, you can get the correct results with just a slight modification. This method has been specifically applied in actual projects and the system performance is stable. In general, the first address of the interrupt vector table is 0x0000 0000. If the interrupt vector table is not set at 0x0000 0000, you need to set ISTP in the boot_c671x_2.s62 file. At this time, vectors do not need to be placed in 1 kB of data, but point to the initial address of vectors in 1 kB of program space.