Split code for PICs. Creating the Object Files. Creating the Symbol-Only Object File. Creating the Absolute Object File for the Fixed Code, страница 3

(Although this option places intcode and powerup at internal locations, there should be nothing placed within either of these two psects by the external code.) Now, remove internal memory object files and replace them with the external memory object files. (The files removed were fixed.obj, callgrph.obj - replaced by r_main.obj and r_ext.obj) The symbol-only fixed code object file is added to the list (f_sym.obj). The modified run-time module is to replace the run-time object, hence, the reference to picrt714.obj is replaced with the extrt.obj file.

Finally, the psect isr10, which contains the external interrupt,  needs to be positioned at the absolute address of 4200h. The following is added to the linker command.

-pisr10=4200h

This is then linked to produce the absolute object file for the external memory.

HLINK < replace.lnk

0.1.6 Creating HEX Files

The OBJTOHEX application is used to create HEX files from the absolute object files. The conversions are as follows.

For the internal code,

OBJTOHEX -I -16,2 f_abs.obj fixed.hex

For the external code

OBTOHEX -I -16,2 replace.obj replace.hex

2.5.2.10 Creating COD Files for Debugging

The COD files are used for debugging on some emulators/simulators, e.g. MPLAB. The CROMWELL utility is used.

CROMWELL -F -M -P17C756 fixed.hex f_abs.sym replace.hex replace.sym -ocod

This produces a fixed.cod file only. For this example, the MPLAB IDE was used to run the code. As the HEX files must be loaded into memory, it is recommended that a copy of the fixed.cod file is made

Split code for PICs

in the name of replace.cod so that it does not matter which HEX file is loaded first, as the COD files exist for both HEX files.

0.1.7 Checking Results

Check the following by viewing the map files.

a)  Ensure that the addresses of all the fixed code are in internal memory and that the addresses of RAMsymbols defined by the fixed code are within the RAM space allocated.

The PIC17C756’s internal memory is from 0h - 3FFFh and from the CODE class listing, all the code is within that range. (In our example, the code is listed in locations 00h-16h, 1EF1h-2011h.

b) Ensure that the addresses all the replaceable code are in external memory and the addresses of RAMsymbols are in the space allocated.

Viewing replace.map shows that the code is placed from address 4000h onwards, which is the external memory location. Note that all the psects linked into the ROMDATA class (e.g. cstrings and idata_n psects) are placed at address 10000h. Although we specified that the linker place these objects in the ROM space 8000h-BFFFh (-AROMDATA=8000h-BFFFh). This is due to the fact that the compiler can place two data bytes in each ROM word location. The address used to refer to ROM data (as opposed to code) is a byte address that is twice the corresponding word address.

c)  Ensure that auto and parameters areas for each function are not at the same address, e.g. ?_ext_main is at 0064h and ?a_ext_main is at 0067h. If a function does not have parameters then these addresses will be the same.

d) Ensure that functions that are active at the same time and have auto or parameter areas do not overlap. e.g. The ext_main() routine calls the functions multiply() and strcat() (in addition to others). The auto and parameter addresses for ext_main() and multiply() do not overlap, nor do the addresses for ext_main() and strcat(). However, note that ?_multiply and ?_strcat are the same since multiply() never calls strcat() and vice versa.

e)  Ensure that the values assigned to the entry routine and external ISRs are as specified.

Looking through the replace.map file, the _start and _ext_isr10 routines are at 4100h and 4200h respectively.

f)  Ensure that symbols that are shared are have the same value in the map file for both the fixed andreplaceable code.

In our example, this would be the function dosomething(). The symbol _dosomething is at 005C in the f_abs.map file as is in the replace.map file. The same can be said about the library calls to strlen(), strlen(), inc() and twice().

PIC Tutorials    

g) Note in replace.map that some symbols in the Symbol table are defined in a psect called (abs). This indicates that the symbol already had a value assigned to it when linking was performed. Essentially this means that the symbol was defined in the fixed code and was present in the symbol-only object file that was linked with the replaceable code. Check to ensure that routines or symbols that should be referenced in the replaceable code are not using any similar definitions in the fixed code.