dsp bootloader c5000

灞波儿奔

dsp bootloader c5000 [Copy link]

Bootload problem. When I was learning 51 before, as long as the program was written and compiled, I could use the burner to burn the *.hex file directly into the microcontroller for operation. However, the DSP does not have FLASH RAM inside. It must load the external program into the internal RAM during reset before it can run. This is a bit like the architecture of a PC. The boot loader in a PC consists of the BIOS (which is essentially a firmware program) and the OS Boot Loader (such as LILO and GRUB, etc.) located in the hard disk MBR. After completing hardware detection and resource allocation, the BIOS reads the Boot Loader in the hard disk MBR into the system's RAM, and then hands over control to the OS Boot Loader. The main running task of the Boot Loader is to read the kernel image from the hard disk into the RAM, and then jump to the kernel entry point to run, that is, to start the operating system. At the beginning, I was very anxious about this bootload. The simulated program could not run offline. It was better to look at TI's DSP datasheet honestly. After some twists and turns, I finally got it done! For this reason, I want to share my debugging experience with you. On the one hand, it is to prevent beginners from taking detours, and on the other hand, it is to throw out a brick to attract jade and hope that experts can correct me^_^. Simply put, the bootloader is a small program before the user program runs. Through this small program, the hardware device is initialized, the memory space mapping map is established, and the user program is finally called. This small program is actually solidified in the internal ROM of the DSP chip TMS320VC33. There are source codes and function flow charts in the TMS320C3X datasheet. We only need to know its function flow. From the flow chart, we can know that when the DSP is powered on and reset, as long as the DSP chip pin 'MCBL/MP' is high, TMS320VC33 will automatically execute the bootloader program solidified in the internal ROM, and then determine the loading start address of the user program according to the external interrupt pins 'INT3~INT0'. Pin level storage space INT0 0 0x001000 INT1 0 0x400000 INT2 0 0xfff000 INT3 0 Serial port In my system application, I store the program in the external FLASH chip 39VF040. Its starting address in the system is: 0X400000, so as long as the external interrupt pin 'INT1' is low when the DSP is reset, the bootloader program starts to read the user program in the external FLASH chip 39VF040 and load it into the DSP internal RAM. After loading, it automatically jumps to the entry address of the user program and starts running the user program. From the flowchart of the bootloader, we can also know that there are certain format requirements when the bootloader loads the user program, that is, the format requirements of the data structure stored in the user's external FLASH program space are as follows: WORD 0: User external FLASH chip data width, such as 8, 16, 32 bits, etc. WORD 1: Control word, used to write the bus control register of TMS320VC33 WORD 2: Data block size WORD 3: The target address of the current uploaded data block to be loaded into the DSP internal RAM WORD 4~N: User program content The user's program is divided into multiple data blocks (because the target file generated by the DSP development software is in COFF format). Each data block starts with a program header, and each contains two contents: 1. The current data block size, that is, the amount of data in 32-bit format. 2. The starting address of the current data block stored in the DSP internal RAM. After the program header comes the user's program content. At this point the key to the problem comes out: How to generate such a program block? What format should the program content be in, *.hex, *.bin, *.out? This was also the most troublesome problem for me at the beginning. After using TI's DSP development software Code Composer to create a project file, the first thing to do is to write a *.cmd command file. There are two command files: one is the link command file, and the other is the boot table format generation command file. The function of the link command file is to allocate the storage location of each program segment in the DSP's internal RAM. The link command file must be the same as the project file name. For example, the link command file online.cmd of the project online.mak is as follows: -c //ROM initialization -o online.out //Generate online.out executable file -m online.map //Generate online.map image file online.obj //Link target file -l rts30.lib //Link in TMS320C3X runtime support library MEMORY { VECS: org=0x809fc1 len=0x3f //Define the starting address of the vector and the length of the space RAM0: org=0x809800 len=0x7c1 //Define the starting address of the stack and the length of the space RAM2: org=0x800000 len=0x8000 //Define user program data space } SECTIONS { "vectors": load=VECS //Arrange the interrupt vector block in the VECS space .text: load=RAM2 //Arrange program code, constants, variables and other data blocks in RAM2 space .cinit: load=RAM2 .const: load=RAM2 .bss: load=RAM2 .stack: load=RAM0 //Arrange the stack block in RAM0 space } After the link command file is created, the development software will automatically select the memory address for the COFF format data block output by the link command file when assembling and linking the user program to generate the target file. The command file is generated in the boot table format. The file name can be arbitrary, for example, it can be named hex.cmd. First of all, we mentioned that the bootloader program of TMS320VC33 has a certain format for loading user programs. The command file generated by the boot table format is to convert the user's target file into a format that meets the requirements. For example: hex.cmd online.out //Target file to be converted -map hex.map //Generate image file -boot //Generate loader -p_w_picpath //Output file removes address image -i //Create INTEL hexadecimal file output -memwidth 8 //Data width of user program memory -cg 10e8h //Bus control word -e 00803f86h //The execution address after the program is loaded is the address of _c_int00, which can be viewed in the online.map file*/ ROMS //ROM mapping range, and user program address space in external FLASH { FLASH1: org=0,len=10000h,romwidth=8,files={online1.hex} FLASH2: org=10000h,len=10000h,romwidth=8,files={online2.hex} } After writing the format conversion command file, use the 'cd' command in the WINDOWS command prompt tool to enter the directory where the user program target file is located, and then run hex30 hex.cmd to generate two hex format files online1.hex and online2.hex according to the requirements of the format command file hex.cmd. Among them, hex30 is the program that comes with the DSP development software. Because Intel format contains various information such as start character, number of bytes, start address, type and check bit in addition to data, it is not a pure HEX format representation of data. So it cannot be burned directly into the FLASH chip. Run the hexbin program in the command prompt and convert online1.hex and online2.hex into online1.bin and online2.bin respectively, and you can get the burning file in pure data format. OK, just burn the two files into the FLASH chip and restart the system, OK! Finally, it can run offline