Hi,
The last version is:
CodeWarrior Development Studio for Freescale 56800/E Digital Signal Controllers Version 8.2.3
Several examples are delivered under the installation.
We provided bootloader too.
Please have a look in the folder \Stationery\Processor_Expert_Examples\Bootloaders.
This can be accessed by the project Wizard too:
File ¦ NEW ¦ Processor Expert Examples Stationery ¦ Bootloaders
We recommend you to use it.
If this could not be an option for you, I can propose you another solution explaining the problem.
The bootloader downloaded was design for the previous version (before V8.x).
Abstract Linker error appears after switching from DSC8.0 to DSC 8.1.
Problem A same application worked fine on the DSC 8.0.
Now with the DSC 8.1, the linker generates some error.
Extract of type of errors:
Link Error : Symbol F_vector_addr referenced from address 0x000411CC in section .text of file ACPBootloader.c
is too far away for a R_56800E_WORD16 relocation, which has a range from 0 to 131070 bytes
Link Error : Symbol F_Pcode_start_addr referenced from address 0x00041506 in section .text of file ACPBootloader.c
is too far away for a R_56800E_WORD16 relocation, which has a range from 0 to 131070 bytes
Link Error : Symbol F_Pcode_end_addr referenced from address 0x00041512 in section .text of file ACPBootloader.c
is too far away for a R_56800E_WORD16 relocation, which has a range from 0 to 131070 bytes
Link failed.
Solution The problem is due to a compiler improvment.
In previous version the compiler generated 24 bits access when 16 bits was possible.
The DSC8.o generated "long" instruction to all structure's data fields which are below the first appearance of
the pointer, array or nested structure in large data model when "Globals live in lower memory" checkbox is checked.
With the DSC8.1 We were worked on removing this different behaviour of compiler in generating code for structure
fields at different offsets.
So this performance issue is addressed in the DSC8.1
Now the compiler always makes use of 16-bit access in "small data model" and "large data model + globals live in lower mem".
In your case, if you disable "globals live in lower mem" and it should link fine.
So disabling "globals live in lower mem" is one workaround that is unfortunately losing performance (size, speed).
Another possible solution is to write some simple assembly functions that return the addresses of the symbols with problem
and use those functions as interface with the C code.
This way the performance will not be affected by the "globals live in lower mem" option.
Regards
Pascal