Microchip Technology XC8 Standard Compiler (Workstation) SW006021-1 SW006021-1 ユーザーズマニュアル
製品コード
SW006021-1
How To’s
2012 Microchip Technology Inc.
DS52053B-page 57
The contents of the HEX file for the bootloader can be merged with the code of the
application by adding the HEX file as a project file, either on the command line, or in
MPLAB IDE. This results in a single HEX file that contains the bootloader and applica-
tion code in the one image. HEX files are merged by the HEXMATE application, see
Section 8.6 “HEXMATE”. Check for warnings from this application about overlap,
which may indicate that memory is in use by both bootloader and the downloadable
application.
application by adding the HEX file as a project file, either on the command line, or in
MPLAB IDE. This results in a single HEX file that contains the bootloader and applica-
tion code in the one image. HEX files are merged by the HEXMATE application, see
Section 8.6 “HEXMATE”. Check for warnings from this application about overlap,
which may indicate that memory is in use by both bootloader and the downloadable
application.
3.5.3
What Do I Need to Do When Compiling to Use a Debugger?
You can use debuggers, such as ICD3 or REALICE, to debug code built with the XC8
compiler. These debuggers use some of the data and program memory of the device
for its own use, so it is important that your code does not also use these resources.
compiler. These debuggers use some of the data and program memory of the device
for its own use, so it is important that your code does not also use these resources.
There is a command-line option, see Section 4.8.23 “--DEBUGGER: Select Debug-
ger Type”, that can be used to tell the compiler which debugger is to be used. The com-
piler can then reserve the memory used by the debugger so that your code will not be
located in these locations.
ger Type”, that can be used to tell the compiler which debugger is to be used. The com-
piler can then reserve the memory used by the debugger so that your code will not be
located in these locations.
In the MPLAB X IDE, the appropriate debugger option is specified if you perform a
debug build. It will not be specified if you perform a regular Build Project or Clean and
Build.
debug build. It will not be specified if you perform a regular Build Project or Clean and
Build.
In MPLAB IDE v8, it is recommended that you select Auto from the Debugger in the
Linker tab of the Build Options dialog. This way, the debugger indicated to the compiler
will be the same as that selected for the project. This option always has an effect.
Select no debugger for a release build.
Linker tab of the Build Options dialog. This way, the debugger indicated to the compiler
will be the same as that selected for the project. This option always has an effect.
Select no debugger for a release build.
Since some device memory is being used up by the debugger, there is less available
for your program and it is possible that your code or data may no longer fit in the device
when a debugger is selected.
for your program and it is possible that your code or data may no longer fit in the device
when a debugger is selected.
Note that which specific memory locations used by the debuggers is an attribute of
MPLAB IDE, not the device. If you move a project to a new version of the IDE, the
resources required may change. For this reason, you should not manually reserve
memory for the debugger, or make any assumptions in your code as to what memory
is used. A summary of the debugger requirements is available in the MPLAB IDE help
files.
MPLAB IDE, not the device. If you move a project to a new version of the IDE, the
resources required may change. For this reason, you should not manually reserve
memory for the debugger, or make any assumptions in your code as to what memory
is used. A summary of the debugger requirements is available in the MPLAB IDE help
files.
To verify that the resources reserved by the compiler match those required by the
debugger, do the following. Compile your code with and without the debugger selected
and keep a copy of the map file produced for both builds. Compare the linker options
in the map files and look for changes in the -A options, see Section 7.2.1 “-Aclass
=low-high,...”. For example, the memory defined for the CODE class with no debugger
might be specified by this option:
debugger, do the following. Compile your code with and without the debugger selected
and keep a copy of the map file produced for both builds. Compare the linker options
in the map files and look for changes in the -A options, see Section 7.2.1 “-Aclass
=low-high,...”. For example, the memory defined for the CODE class with no debugger
might be specified by this option:
-ACODE=00h-0FFh,0100h-07FFh,0800h-0FFFhx3
and with the ICD3 selected as the debugger, it becomes:
-ACODE=00h-0FFh,0100h-07FFh,0800h-0FFFhx2,01800h-01EFFh
This shows that a memory range from 1F00 to 1FFF has been removed by the compiler
and cannot be used by your program. See also Section 3.6.16 “Why are some
objects positioned into memory that I reserved?”.
and cannot be used by your program. See also Section 3.6.16 “Why are some
objects positioned into memory that I reserved?”.
3.5.4
How Can I Have Code Executed Straight After Reset?
A special hook has been provided so you can easily add special "powerup" assembly
code which will be linked to the Reset vector, see Section 5.10.2 “The Powerup Rou-
tine”. This code will be executed before the runtime startup code is executed, which in
turn is executed before the main function, see Section 5.10 “Main, Runtime Startup
and Reset”.
code which will be linked to the Reset vector, see Section 5.10.2 “The Powerup Rou-
tine”. This code will be executed before the runtime startup code is executed, which in
turn is executed before the main function, see Section 5.10 “Main, Runtime Startup
and Reset”.