Implementation of the External Memory Self-Booting Function of TMS320C6712

The booting methods of the TMS320C6000 series and the TMS320C54 series are very different. When developing and applying the TMS320C6000 series DSP, many developers, especially beginners, have some difficulties in implementing the 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.

The booting process of the DSP

The booting (BOOT) of the DSP system 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 booting process of the DSP is as follows:

1) After the DSP is reset, the data in the external CE1 space is read into the internal program space address 0 through DMA. The amount of data read varies depending on the chip (TMS320C6712 only copies 1KB at a time).

2) DSP exits the reset state and starts to execute the program at address 0 of the internal program space. 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 completed automatically by the chip, and the key is the second step: the user needs to write the corresponding assembly program to achieve 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 parameters of the link, describes the segment names of each segment of the executable code generated by the system and maps them to the physical space of the target board. When the starting address or 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 to binary file format and saved in the external memory of the target board. The correct configuration file needs to be used for conversion.

(3) The 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 set boot mode 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 few internal resources and relatively low operating frequency, but its price is low 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 use the DSP debugging system to write through software programming. 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. The file flow of the boot project is shown in Figure 2.

(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 and execute
NOP 5

(2) The self-booting assembler boot.asm

is mainly used to configure basic registers and copy the binary program stored in the external FLASH to the RAM inside the DSP for execution. Since TMS320C6712 automatically copies 1KB, the starting address is from 0x400. The assembly program is as follows:

.sect ".boot_load" ; define the data segment
.ref _c_int00 ; declare external function
.global _boot ; define global function
_boot:
; first set the control register, such as EMIF_GCR, etc. (omitted)
; copy the program in FLASH to DSP internal RAM
mvkl 0x00000400, A4 ; A4 is the RAM address pointer
|| mvkl 0x90000400, B4 ; B4 is the FLASH address pointer
mvkh 0x00000400, A4
|| mvkh 0x90000400, B4
zero A1 ; A1 is used as a counter
_boot_loop: ; DSP starts to read 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
nop 5
mvkl .S2 _c_int00, B0 ; After the loop ends, jump to the main function main to execute
mvkh .S2 _c_int00, B0
B .S2 B0
Nop 5

(3) Main program main.c

The main program is the main body of DSP to implement specific functions. 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) Link command program link.cmd

The link command program 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 = 01000000h
CE1: o = 90000000h l = 00100000h
}
SECTIONS
{
.vectors > vecs fill = 0
.boot_load > BOOT_RAM fill = 0
.text > IRAM fill = 0
.stack ＞ IRAM fill = 0
.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 file is compiled and assembled by the CCS system to generate an executable COFF file (.out), which needs to be converted into a binary file and then written into FLASH. The CCS development system comes with a conversion program:

hex6x.exe converts executable COFF files (.out) to hexadecimal files (.hex)
hex2bin.exe converts hexadecimal files (.hex) to binary files (.bin)

The command line format 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

In summary, it is not complicated to realize the external memory self-boot of TMS320C6712. The key is to understand the chip's self-boot process and the role of each part after program assembly, configure the actual physical address of the boot code segment and program code segment, and correctly initialize the corresponding registers and variables.