Design and implementation of DSP+FLASH boot loading system

　　In some DSP systems running offline, user code needs to be automatically loaded and run after power-on. The boot load of the DSP system means that when the system is powered on, the DSP transplants a piece of code stored in the external non-volatile memory to the internal high-speed memory unit for execution. This not only utilizes external storage units to expand the limited ROM resources of the DSP itself, but also fully utilizes the performance of the internal resources of the DSP. Although the user code is relatively fixed for a period of time, if it is directly masked into the internal ROM, on the one hand it is limited by capacity and price, and on the other hand it is not very flexible and convenient at the system code level. FLASH is a high-density, non-volatile electrically rewritable memory, and the price per unit storage bit is lower than that of traditional EPROM. It is very suitable for portable systems with low power consumption, small size and high performance. In addition to using a dedicated hardware programmer to pour the code into FLASH, you can also use a ready-made DSP to achieve the same function through software programming. This article discusses how to implement FLASH read and write operations through DSP software programming, and introduces the implementation of a simple system boot loading solution.

　　1 System description

　　This system consists of DSP (TMS320VC5410), external FLASH (M29W400T) and related power management units. The connection between DSP and FLASH is shown in Figure 1. DSP and FLASH have a master-slave relationship, and the relevant output pins of the DSP control the erasing, reading and writing of FLASH. Among them, A0~D15 are data lines, /MSTRB is the storage strobe signal, R/W is the read and write pulse signal, /OE and /WE are read enable and write enable respectively, /CE is the chip enable, /BYTE Select 8-bit or 16-bit data mode (connecting high voltage to 16-bit mode in the picture). FLASH is used to store boot program segments and user codes, which are written by DSP software programming. When the system is powered on offline, the DSP first starts boot loading from the starting position of the boot program segment specified by external FLASH. The so-called boot loading is to transplant the user code originally stored in FLASH to the high-speed execution inside the DSP, and then set the program pointer to the starting address of the user code. In this way, DSP resources can then be used to execute user code at high speed.

　　2 DSP operation on FLASH

　　2.1 Introduction to DSP and FLASH

　　TMS320VC5410 is a fixed-point DSP of TI's C54x series. It has low power consumption and high speed and is often used in portable system development. Its internal resources include 256Kb of maskable RO memory and 128Kb of DARAM and 896Kb of SARAM that can run at high speeds. The boot loading code provided by TI is solidified in the ROM, and the solution uses a self-written boot program. ST's M29W400 series has a FLASH capacity of 4Mb, is divided into 11 block structures of different sizes, and supports 8-bit or 16-bit operation modes. Each block can be erased, read and written independently through a special command word sequence. Compared with previous FLASH, it is powered by an external single voltage and can be erased and written without additional high voltage, so there is no need to consider special level matching in system design. This solution uses 16-bit mode.

　　2.2 Address mapping method

　　Since DSP is used to operate FLASH, it must involve the mapping method of the actual address of FLASH in DSP. The address space of TMS320VC5410 is shown in Figure 2, including data space and program space. The specific mapping method is determined by some registers inside the DSP. It uses a page extension mechanism and can address up to 8192Kb of program space. Assuming that the starting address 0x0000 of FLASH coincides with the starting address 0x0000 of DSP, then only the part of the address in FLASH corresponding to the external space of DSP is visible to DSP. For example, when the microprocessor mode (MP=1) and OVLY=1 are used in this solution, the address range of FLASH visible in the program space on page 0 of the DSP is 0x8000~0xFFFF. Before erasing or reading or writing FLASH, the corresponding command word sequence must be executed first, that is, the specified instruction code must be written at the specified FLASH address. The entire FLASH address space does not correspond one-to-one with the FSP address space, so address remapping needs to be considered. Now take writing to FLASH as an example. When address remapping is not considered, the command word sequence is as follows: Flash Write(0x5555L,0x00AA);//1st cycle Flash Write(0x2AAAL,0x0055);//2nd cycle Flash Write(0x5555L,0x00A0);//Program command Flash Write(myaddress,mydata);//put mydata into myaddress It can be seen from Figure 2 that when MP=1 and OVLY=1, FLASH addresses 0x5555L and 0x2AAAL are located outside the external space in the DSP and are invisible. In this way, when the DSP executes the above statement, it does not perform corresponding operations on the FLASH at all. As a result, even if the FLASH address myaddress is visible to the DSP, the data writing function cannot be realized. A careful analysis of the command word order of FLASH shows that the address bits that really work in the first three command word sequences are A0~A14, while the high address bits A15~A17 can be any value. So consider adding an offset of 0x8000 so that the remapped FLASH address is visible in the DSP. The modified code is as follows: #define OFFSET 0x8000 Flash Write ((0x5555L+OFFSET),0x00AA);//1st cycle Flash Write((0x2AAAL+OFFSET),0x0055);//2nd cycle Flash Write((0x5555L +OFFSET),0x00A0);//Program command Flash Write((myaddress,mydata);//put mydata into myaddress In this way, the external FLASH can be written in the DSP, provided that the FLASH address myaddress is in the DSP It can be seen that erasing and reading operations also require similar address remapping according to Figure 2, which will not be described one by one.

　　2.3 Description of erasing and reading and writing processes

　　Before the DSP writes data to FLASH, the block where the data is located must be deleted and then rewritten. The corresponding command word sequence must be executed before erasing and writing operations, while read operations can be performed directly. Moreover, the data part to be written should be the boot program segment and the user code should be the compiled and connected target code, and should be in HEX format that can be recognized by FLASH.

　　3. Boot loading model design

　　3.1 Bootloading principle

　　Before powering up, the DSP is set to microprocessor mode (MP=1). After power-on, the DSP first executes the jump command at the beginning of the interrupt vector table at 0xFF80, turns to the boot program segment at 0xF800, and implements the code migration function. After completion, jump to the starting address of the transplanted user program segment again and execute it.

　　3.2 Logical function block

　　The boot loading system includes four parts: boot program segment, user program segment, interrupt vector table and connection command file. The boot program segment is responsible for loading the user program segment and interrupt vector table to the target address. The user program segment is the core code that implements user system functions. The interrupt vector table includes the jump processing after power-on and the entry of the interrupt service program, and the connection command file. It is to allocate the location of each program segment in the DSP address space.

　　3.3 Specific code implementation

　　The boot program segment (load.asm) is as follows: .def load_start .sect "load_prg" load_start: ssbx intm; turn off interrupt rsbx sxm; set the sign extension mode to 0 ld #0,dp; define the data page pointer to 0 nop nop nop ld #0ff80h,a ; Migrate the interrupt vector table, 0xff80 is the old starting address of the interrupt vector table stm #VECT_NEW,ar1 ; VECT_NEW represents the new starting address of the interrupt vector table rpt #(VECT_LEN-1) ; VECT_LEN represents the interrupt vector table Length reada *ar1+ nop ld #MAIN_OLD,a; Transplant the user program segment, MAIN_OLD represents the old starting address of the user program segment stm #MAIN_NEW,ar1; MAIN_NEW represents the new starting address of the user program segment rpt #(MAIN_LEN-1); MAIN_LEN represents the length of the user program segment reada *ar1+ endboot: orm #020h,@1dh; Set OVLY=1 so that the internal RAM is mapped to both DSP data and program space ld #MAIN_NEW,a bacc a; The program pointer points to the user program segment The starting address of the .end user program segment (main.asm) is as follows: .def main_start .sect "main_prg" main_start: USER_PRG ;Add the user program segment here.end The interrupt vector table (vect.asm) is as follows: .mmregs .ref main_start .ref load_start .def reset .def nmi .sect ".vectors" reset: bd load_start ; After power on, jump to the starting address of the self-start program segment stm #200,sp nmi:rete ; This table only contains NMI Interrupt entry, you can also add other interruption entries similarly nop nop nop .end The configuration of the connection command file (boot.cmd) is as follows: vect.obj main.obj load.obj -o boot.out SECTIONS { main_prg: load=MAIN_OLD,run =MAIN_NEW vectors: load=0ff80h,run=VECT_NEW load_prg: load=0f800h }

　　4 Write the target code

　　After the above boot program is compiled and connected by CCS, the generated target file boot.out is in the COFF format that the DSP can recognize. However, FLASH does not support this mode, so it cannot be written directly into FLASH. CCS comes with a variety of HEX type conversion programs, such as the common Intel format. However, different HEX types have different formats and head and tail overheads. For example, in addition to data, the Intel format also has various information such as start character, number of bytes, starting address, type, and check digits, etc., and is not pure data. Represented in HEX format. After understanding the file structure of the Intel format, you can extract the HEX format of the code that needs to be written into FLASH and have the corresponding address, which corresponds to the mydata and myaddress mentioned above. Then you can use the above method to use DSP to write the code for each part of the boot system into FLASH before running offline.

　　 5 Simple test examples

　　Using the above method, the system can be booted and loaded offline, and a uniform pulse waveform can be output from the XF port of the DSP. To directly modify the user program section, you can replace USER_PRG in the user program section with the following code. loop:rsbx xf nop ssbx xf nop b loop After compilation, connection, format conversion and writing to FLASH, the system can actually run offline. After powering on for a period of time, the uniform pulse waveform of the XF port can be measured through an oscilloscope, proving that the boot loader is successful.