Design of Flash booting and self-starting based on TMS320C6000 DSP and DSP/BIOS system

Abstract: With the development of information technology, DSP has been widely used in modern electronic system design, and DSP's FLASH self-start also plays an important role in DSP system design. DSP/BIOS is an embedded real-time operating system launched by TI.
Keywords: TMS320C6713; boot boot; DSP/BIOS real-time operating system

    FLASH is a non-volatile rewritable memory with a slow read and write speed. It is often used to store system design programs. The microprocessor reads the program in FLASH into the processor in a certain way to run it. However, there is no FLASH inside the DSP of TI's C6000 series, so the DSP program needs to be burned into the external FLASH. After power-on, the DSP will read the program from the external FLASH into the DSP internal RAM or SDRAM through secondary boot and execute it at high speed. TI's C6000 DSP supports three boot modes: host boot, emulation boot and EMIF boot, among which EMIF boot (i.e. on-chip BootLoader boot) is the most commonly used. In this boot mode, the 1kB code in the FLASH of the external storage space CE1 is copied to the on-chip RAM address 0 through EDMA. However, most DSP programs are not limited to 1 kB code, so it is necessary to develop a user boot program to copy the code that the on-chip BootLoader does not copy to the DSP's on-chip RAM. This user boot program is called the secondary BootLoader. Due to the widespread application of the DSP/BIOS operating system, when using DSP/BIOS, it is necessary to combine the system and BootLoader well to achieve the self-startup of the DSP/BIOS system.

1 Design of DSP self-startup system
    After TMS320C6713 is powered on, the system will automatically move 1 kB code from the storage space of CE1 of EMIF according to the external configuration. These codes are moved to the internal RAM address 0 of the DSP for execution. This 1KB code should store the DSP's BootLoader startup code. It is just a copy program, which is only responsible for copying the application code in FLASH to the internal RAM or SDR AM of the DSP for execution. The BootLoader code should be stored in the first 1 kB of the DSP's internal RAM. The application code follows this 1 kB of the startup code. The BootLoader code should be burned into the FLASH together with the application code. The BootLoader code should also be in the first 1 kB of the FIASH. After the DSP is powered on and reset, it first reads the first 1 kB of the BootLoader code from the FLASH to the DSP's internal RAM with the default timing, and then executes the BootLoader code from address 0, reading the application code from the FLASH into the internal RAM or SDRAM. After copying the application code, the DSP jumps to the c_int00() reset interrupt to execute and execute the application, thus completing the FLASH boot self-startup of the entire DSP.
    The FLASH burning of the program code is carried out by another burning project. The burning project should write the erase and programming functions of the FLASH according to the chip manual and burn the program code into the FIASH. Since two projects need to be loaded into DSP or SDRAM through hardware emulator at the same time, it is necessary to modify the CMD file of the burning project so that its various segments do not conflict with the user project containing BootLoader code, otherwise the self-start of FLASH cannot be realized.

2 Introduction to DSP/BIOS embedded real-time operating system and its boot design
    The performance of a series of DSPs launched by TI has been continuously improved. The highest operating clock and computing power of the C6000 series can reach 8800MIPS. How to give full play to the performance advantage of DSP puts forward high requirements for software. First of all, in order to reduce system cost and improve system performance, it is required that the functions implemented by DSP hardware be softwareized. Secondly, for product maintenance and upgrade, the software is required to be modularized as much as possible, using high-level languages ​​such as C for programming, and having a unified interface API. All these new requirements require the use of a real-time operating system. The main difference between a real-time operating system and a general operating system (such as Windows, Unix, etc.) is that a real-time operating system provides a mechanism so that applications running on it can meet real-time requirements.
    The process of booting a DSP/BIOS application system can be divided into the following steps, and the boot process is shown in Figure 1:

    1. Configuring the memory of DSP/BIOS during booting
    2. Building your own DSP/BIOS system application
    3. Writing BootLoader code
    4. Burning the application into FLASH
[page]

    3 Hardware Design
    The connection between TMS320C6713 and FLASH memory chip AM29LV800B is through the DSP's external memory interface EMIF. EMIF can be seamlessly connected to various memories and achieve high data throughput. The EMIF working clock of C6713 can reach up to 100MHz. When the external FLASH is booted, it is booted from the CE1 space of the DSP. The address of FLASH is mapped to the 0x90000000 address of the DSP. In terms of hardware, the CE1 of the DSP and the chip select of FLASH need to be connected, and the address bus and the data bus are connected, as well as the control signals AOE and AWE are connected. FLASH works in 16-bit mode. At the same time, the program may need to store a large amount of data, which requires connecting SDRAM to the DSP. Connect SDRAM to the CE0 space of the EMIF interface of the DSP. SDRAM is mapped to the 0x80000000 address of the DSP. The DSP accesses different peripherals by accessing different access spaces. As long as the EMIF interface register of C6713 is configured, FLASH and SDRAM can be accessed normally. The SDRAM model used in the system is MT48LC2M32BTG.
    The hardware schematic diagram of the system is shown in Figure 2.

4 Software Design
4.1 BootLoader Boot Program Design
    When C6713 is powered on and reset, it will read 1 kB of code from the outside to the DSP internal RAM at the default timing according to the status of the external pins HD4 and HD3. Most programs will exceed 1 kB, so the 1 kB code automatically read by the DSP is designed as a BootLoader boot program, which reads the application code into the DSP and jumps to the main function to execute after reading the application code. The
    reference document provided by TI lists the boot code written in assembly language. The assembly code is obscure, so we provide the C language boot code written by ourselves, as follows:
   
    [page]

    
   
   
    DSP/BIOS will automatically generate CMD files according to the configuration, indicating the storage location of each segment. The boot segment customized by the above code should be located at the address 0-0x3FF inside the DSP. When burning FLASH, it will be burned into the address 0-0x3FF space of FLASH. The IRAM CODE SIZE and SDRAM CODE SIZE macros indicate the program size in the RAM and SDRAM inside the DSP, which can be obtained from the map file compiled by CCS. When starting, the BootLoader code will first be loaded into the DSP and run, read the application into the DSP and SDRAM, and jump to the main function to execute and schedule the operation of DSP/BIOS.
    Some CMD files are as follows:
   
4.2 FLASH burning project program design
    After the user's application containing the BootLoader code is written, compiled, and debugged correctly, an out file will be generated. Burning it into FLASH can realize the automatic
boot . There are many ways to burn, some are converted into bin files, some are burned with FlashBurn tools, and some are implemented with FLASH programmers. We use the method of writing burning code by ourselves
.
    The basic purpose of burning project is to erase and program FLASH. The writing of these sub-functions can be correctly implemented by referring to the chip manual and cooperating with the correct timing. Here we mainly describe how to use sub-functions to burn user applications.
    Since two different projects are to be loaded into the system at the same time, the various segments of the two projects cannot be crossed. Symmetrically, the cmd file for the burning project can be written as follows and placed in the last part of the DSP internal RAM:
    MEMORY
    {
    FLASH: origin=0x90000000,len=0x100000
    SRAM: origin=0x0002D000,len=0x3000
    }
    SRAM indicates that all the codes and ends of the burning project should be placed in the DSP internal RAM starting from 0x0002D000 and occupying a length of 0x3000. This is mainly to avoid conflicts with the user application storage space. This can be adjusted according to actual conditions.
    The burning project needs to burn the programs and data previously downloaded to DSP or SDRAM through the emulator into FLASH. Some codes are as follows:
   
   

5 Conclusion
    With the development of electronic technology, DSP and TI's DSP/BIOS system for its DSP are more and more widely used. It is particularly important to boot and start DSP stably and reliably through external FLASH. The DSP self-booting system designed in this paper has been verified in actual projects and can stably realize the booting of DSP/BIOS system. For different application projects, it only needs to modify simple parameters according to the map file. Moreover, this method can also be used to boot bare metal programs of non-DSP/BIOS systems.