Other Parts Discussed in Thread: LM3S3748
We are in the process of trying of trying to get a new machine set up to build firmware for a Stellaris LM3S3748 microcontroller. All of the firmware thus far has been compiled with cl470 version 4.6.1 (newer versions seem to create output code that is too large and won't fit into our flash map).
We are using a custom linker command file that allows some code (MD5 checksum functions) to be shared between two applications on the device. At least one function in this library needs to be located at a fixed flash location: 0x0700. While another machine (set up as close as we can get) is able to specify the location of this function correctly, on the new machine the linker complains that it cannot find the matching section and dumps the function in the wrong place.
Here are the relevant parts of the linker command file:
#define MD5_START 0x00000700 /* 0x900 bytes maximum length (MD5 library) */
MEMORY
{
...
FLASH_MD5 (RX) : origin = MD5_START, length = 0x00000900
...
}
SECTIONS
{
...
md5 : > FLASH_MD5
{
md5.obj(.text:md5_get_interface)
md5.obj(.text:md5_compute_digest)
md5.obj(.text:md5_start_digest)
md5.obj(.text:md5_add_to_digest)
md5.obj(.text:md5_finish_digest)
md5.obj(.text)
md5.obj(.const)
}
...
}
We get the following warning:
"../Source/application/platform/lm3s3748/lm3s3748.cmd", line 56: warning: no
matching section
"../Source/application/platform/lm3s3748/lm3s3748.cmd", line 57: warning: no
matching section
"../Source/application/platform/lm3s3748/lm3s3748.cmd", line 58: warning: no
matching section
"../Source/application/platform/lm3s3748/lm3s3748.cmd", line 59: warning: no
matching section
"../Source/application/platform/lm3s3748/lm3s3748.cmd", line 60: warning: no
matching section
The line numbers correspond to the five lines that call out specific functions by name, starting with md5_get_interface.
These functions do exist and get placed by the linker (caught by the .text wildcard). Here is where they land in the map:
00000701 __md5_initialize
00000727 __md5_add_length_to_context
00000743 __md5_fill_incomplete_block
0000077d __md5_transform
00000dcd __md5_add_bytes
00000e5d md5_start_digest
00000e7d md5_get_interface
00000ec1 __md5_finalize
00000f49 md5_finish_digest
00000f5d md5_compute_digest
00000f8d md5_add_to_digest
Thus, all of the MD5 functions are being grouped together (from md5.obj) as expected. The only problem is that the order of the functions is completely wrong. If md5_get_interface could be placed at 0x0700 then the rest would not really matter, but the linker is not playing along. This works perfectly on a different machine with what we believe is the same version of the toolchain.
Any recommendations? Thank you.
