本文主要向大家介绍了Flash基础入门之Snow TI DSP --- FLASH Programming，通过具体的内容向大家展现，希望对大家学习Flash基础入门有所帮助。

The application software modifications needed for execution from on-chip flash memory.

Requirements for both DSP/BIOS and non-BIOS projects are presented.

The on-chip flash usually eliminates the need for external non-volatile memory and a host processor from which to bootload.

1. CMD File & Code Start

TI CCS project has two linker command files:

(1) Header linker command file (PAGE 1), which is required to link the peripheral structures to the proper locations within the memory map. e.g., "F2807x_Headers_nonBIOS.cmd". The peripheral header file contains linker MEMORY and SECTIONS declarations for linking the peripheral register structures.

(2) Memory linker command file (PAGE 0 & PAGE 1), which defines the memory block start/length for the F28x7x. e.g., "28075_FLASH_lnk.cmd". It is also called the user linker command file. In non-DSP/BIOS applications, the user linker command file will be where most memory is defined, and where the linking of most sections is specified. 

Note-1: PAGE 0 will be used to organize program sections. PAGE 1 will be used to organize data sections.

Note-2: Memory blocks are uniform in both PAGE 0 and PAGE 1. That is the same memory region should not be defined for both PAGE 0 and PAGE 1. Doing so will result in corruption of program and/or data. 

Note-3: Contiguous SARAM memory blocks or flash sectors can be combined if required to create a larger memory block.

Note-4: CCS supports to have more than one linker command file in a project. In general, the order of the linker command files is unimportant since during a project build, CCS evaluates the MEMORY section of every linker command file before evaluating the SECTIONS section of any linker command file. This ensures that all memories are defined before linking any sections to those memories. (However, advanced users may need manual control over the order of linker command file evaluation in some rare situations. This can be specified within CCS v5 on the Project -> Properties menu, then select the CCS Build category, Link Oder tab).

Note-5: Two basic section types exist: initialized, and uninitialized. Initialized sections must contain valid values at device power-up. For example, code and constants are found in initialized sections. When designing a stand-alone embedded system with the F28xxx DSP (e.g., no emulator or debugger in use, no host processor present to perform bootloading), all initialized sections must be linked to non-volatile memory (e.g., on-chip flash). An uninitialized section does not contain valid values at device power-up. For example, variables are found in uninitialized sections. Code will write values to the variable locations during code execution. Therefore, uninitialized sections must be linked to volatile memory (e.g., RAM).

Note-6.1: It is important that the large memory model be used with the C-compiler (as opposed to the small memory model). Small memory model requires certain initialized sections to be linked to non-volatile memory in the lower 64Kw of addressable space. However, no flash memory is present in this region on any F28xxx devices, and this will likely be true for future F28xxx devices as well. Therefore, large memory model should be used.

Note-6.2: For CCS v5 projects, the large memory model checkbox is found on the Project -> Properties menu, then select Build -> C2000 Compiler -> Basic Options category. It is selected by default for all newly created CCS projects.

Note-6.3: For non-DSP/BIOS projects, one should include the large memory model C-compiler runtime support library into their code project. For the fixed-point devices, this is library rts2800_ml.lib (as opposed to rts2800.lib, which is for the small memory model). For the floating-point devices, this is file rts2800_fpu32.lib for plain C code, or rts2800_fpu32_eh.lib for C++ code (there are no small memory model libraries for the floating-point devices).

Note-6.4: For DSP/BIOS projects, DSP/BIOS will take care of including the required library. The user should not include any runtime support library in a DSP/BIOS project.

Note-7: When running a program from flash, all initialized sections must be linked to non-volatile memory, whereas all uninitialized sections must be linked to volatile memory. Any user created initialized section should be linked to flash (e.g., those sections created using the CODE_SECTION compiler pragma), whereas any user created uninitialized sections should be linked to RAM (e.g., those sections created using the DATA_SECTION compiler pragma).

Note-8: The .reset section contains nothing more than a 32-bit interrupt vector that points to the C-compiler boot function in the runtime support library (the _c_int00 routine). It is almost never used. Instead, the user typically creates their own branch instruction to point to the starting point of the code. When not in use, the .reset section should be omitted from the code build by a DSECT modifier in the linker command file.

Note-9.1: The Peripheral Interrupt Expansion (PIE) module manages interrupt requests on F28xxx devices. At power-up, all interrupt vectors must be located in non-volatile memory (i.e., flash), but copied to the PIEVECT RAM as part of the device initialization procedure in your code. The PIEVECT RAM is a specific block of RAM, which on F28xxx devices covered in this report is a 256x16 block starting at address 0x000D00 in data space.

Note-9.2: Several approaches exist for linking the interrupt vectors to flash and then copying them to the PIEVECT RAM at runtime. One approach is to create a constant C-structure of function pointers that contains all 128 32-bit vectors. If using the peripheral header file structures, such a structure, called PieVectTableInit, has already been created in the corresponding file DSP28xxx_PieVect.c. Since this structure is declared using the const type qualifier, it will be placed in the .econst section by the compiler. One simply needs to copy this structure to the PIEVECT RAM at runtime.

Note-9.3: The C-compiler runtime support library contains a memory copy function called memcpy() that can be used to perform the copy task. memcpy((void *)0x000D00, &PieVectTableInit, 256);

Note-9.4: The above example uses a hard coded address for the start of the PIE RAM, specifically 0x000D00. If this is objectionable (as hard coded addresses are not good programming practice), one can use a DATA_SECTION pragma to create an uninitialized dummy variable, and link this variable to the PIE RAM. The name of the dummy variable can then be used in place of the hard coded address. For example, when using any of the 28xxx device peripheral structures, an uninitialized structure called PieVectTable is created and linked over the PIEVECT RAM. The memcpy() instruction in the previous example can be replaced by: memcpy(&PieVectTable, &PieVectTableInit, 256);

Note-9.5: Lastly, on some devices, specifically the "Piccolo" devices, the first three 32-bit PIE vector locations are used for bootmode selection when the debugger is in use. Therefore, the code should be modified to avoid overwriting these locations.

以上就介绍了Flash的相关知识，希望对Flash有兴趣的朋友有所帮助。了解更多内容，请关注职坐标常用软件Flash频道！