CMD command file in CCS

The professional name of CMD is the linker configuration file, which stores the configuration information of the linker. We call it a command file for short. The key is the use of memory and seory pseudocommands, which is often confusing, system problems are often related to their improper use. I will focus on them. CCS is a development environment inherited from DSP software in the DOS system. The command file of CCS has been extended for a long time and has become very concise (I do not know whether the Ti documentation has detailed cmd configuration instructions ). I learned cmd from something in DOS, so I also started with cmd in DOS:

1. Composition of the command file

The start part of the command file is the name of each target file to be linked, so that the linker can link the target file to a file based on the target file name. The next step is the operation command of the linker, these commands are used to configure the linker, followed by the related statements of memory and sections, which must be capitalized. Memory, used to configure the target memory, and sections used to specify the storage location of the segment. Link. cmd, a command file in the typical DOS environment, is used as an example:

File. OBJ // sub-target file name 1

File2.obj // The child object name 2

File3.obj // Object Name 3

-O Prog. Out // connector Operation Command, used to specify the output file

-M Prog. m // specifies the map file

Memory

{Omitted}

Sections

{Omitted}

Otherlink. cmd

This command file link. the otherlink to be called by CMD. CMD and other command files, the file name should be placed in the last line of this command file, because if the header is opened, the linker will not return to this command file from other command files called.

2 memory pseudocommands

Memory is used to establish the model of the target memory. The sections command can arrange the location of each segment based on this model. The MEMORY command can define various types of memory and capacity of the target system. The memory syntax is as follows:

Memory

{

Page 0: name1 [(ATTR)]: Origin = constant, length = constant

Name1n [(ATTR)]: Origin = constant, length = constant

Page 1: name2 [(ATTR)]: Origin = constant, length = constant

Name2n [(ATTR)]: Origin = constant, length = constant

Page N: Namen [(ATTR)]: Origin = constant, length = constant

Namenn [(ATTR)]: Origin = constant, length = constant

}

The page keyword marks an independent bucket. The maximum value of page number N is 255. In actual applications, it is generally divided into two pages: Page 0 program memory and page 1 data storage.

Name: the name of the storage interval, which must not exceed 8 characters. The same name can appear on different pages (it is best not to use it without obfuscation). The same name cannot exist in a page.

Attribute identifier of ATTR. "R" indicates readable; "W" indicates that the range can be loaded with executable code; "I" indicates that the memory can be initialized and no attribute code is written, it indicates that the storage interval has the preceding four attributes. Basically, we choose this method.

Origin: omitted.

Length: omitted.

The following is a simple 2407 statement that I often use for your reference. The program from 0x060 is to avoid encryption bits and not to be more reliable from 0x0044, in this example, only the first page with the same name can be written, which is omitted later, but it should be at least safe:

Memory

{

Page 0: VECs: Origin = 0x0000, length 0x40

Page 0: prog: Origin = 0x0060, length 0x6000

Page 1: B0: Origin = 0x200, length 0x100

Page 1: B1: Origin = 0x300, length 0x100

Page 1: Data: Origin = 0x0860, length 0x0780

}

3 sections pseudocommand
The syntax of the sections command is as follows:
Sections
{
. Text: {all. text input segments} load = load Address Run = run address
. Data: {all. Data Input segments} load = load Address Run = run address
. BSS: {all. BSS input segment names} load = load Address Run = run address
. Other: {all. Other input segment names} load = load Address Run = run address
}
The description of each output segment starts with the segment name, the following describes how to organize input segments and allocate storage parameters to segments:
Take the attribute statement of the. Text Segment as an example. The "{all. text input segment names}" section describes the. Text Segment of the connector output segment which consists of the Child target file segments. The example is as follows:

Sections
{
. Text: {file1.obj (. Text) file2 (. Text) file3 (. Text, cinit)} omitted
}

Specify the output segment. Text to be linked to. Text of file1.obj and. Text of file2, as well as. Text and. cinit of file3. In the CCS sections, only one "{}" with no content in the middle is written to indicate the corresponding segments of all target files.
Next, the "load = load Address Run = run address" linker assigns two addresses to each output segment in the target storage: one is the load address and the other is the run address. Generally, the two addresses are the same. You can think that the output segment has only one address. In this case, you can leave the statement "run = run address". However, you sometimes need to separate the two addresses, for example, you can load the program to flash and put it in RAM for high-speed running. This uses the separate configuration of the running address and loading address, as shown in the following example:
. Const: {omitted} load = prog run = 0x0800
Constants are loaded in the program storage area and configured to be called in Ram.
Note the following statements about "load = load address": first, the "LOAD" keyword can be omitted. "=" can be written as ">", and "load address" can be: the address value, the name of the storage interval, and the page keyword. do not be surprised with statements such as text :{}> 0x0080. In "run = run address", "=" can be used with ">", and no other simplified statement can be used. Do not use it indiscriminately.

4. Case studies in CCS
The command files in the CCS seem to have been simplified a lot, and the statements have been simplified a lot. First, you do not need to specify the target file of the input linker. The CCS will automatically process the command files by default, the configuration commands of the linker are different from those of the DOS environment. For more information, see the Ti documentation! The following is an example in Liu Heping shu. Let's see if you can understand it accurately! If you don't understand it, continue to discuss it in this post! My qq605507276!
-Stack 40
/*-------------------------------------------------------------------------*/
/* Command file-bucket f2407 */
/*-------------------------------------------------------------------------*/
Memory
{
Page 0: VECs: Origin = 0 h, length = 40 h/* program reset */
Pvecs: Origin = 40 h, length = 70 h/* peripheral module interrupt vector */
Prog: Origin = 0b0h, length = 7f50h/* in Flash */
Page 1: MMRs: Origin = 0 h, length = 05fh/* MMRs */
B2: Origin = 0060 H, length = 020 H/* daram B2 block */
B0: Origin = 0200 H, length = 100 h/* daram B0 block */
B1: Origin = 0300 H, length = 100 h/* daram B1 block */
SARAM: Origin = 0800 H, length = 0800 H/* Saram block */
Ext: Origin = 8000 h, length = 8000 h/* external memory */
}
/*-------------------------------------------------------------------------*/
/* Sections allocation */
/*-------------------------------------------------------------------------*/
Sections
{
. Reset: {}> VECs page 0/* reset interrupt vector table */
. Vectors: {}> VECs page 0/* interrupt vector table */
. Pvecs: {}> pvecs page 0/* peripheral module interrupt vector table */
. Text: {}> prog page 0/* Code */
. Cinit: {}> prog page 0
. BSS: {}> Saram page 1/* block B2 */
. Const: {}> Saram page 1/* block B2 */
. STACK: {}> B1 page 1/* stack-40 units */