HEX file larger than memory

[dusek_martin]

Hi,

I built release configuration of MKL25Z4 freedom_bootloader in NXP_Kinetis_Bootloader_2_0_0. The only change I did was modification of linker script:

MEMORY
{
m_interrupts (RX) : ORIGIN = 0x00000000, LENGTH = 0x00000100
m_bootloader_config (RX) : ORIGIN = 0x000003C0, LENGTH = 0x00000040
m_flash_config (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
m_text (RX) : ORIGIN = 0x00000410, LENGTH = 0x00007BF0
m_data (RW) : ORIGIN = 0x1FFFF000, LENGTH = 0x00004000
}

I enabled hex file creation and print of program size after build.

I got:

text data bss dec hex filename
30788 2288 6336 39412 99f4 freedom_bootloader.elf

The hex file ends with:

:108ED0000000000000000000000000000000000092
:108EE0000000000000000000000000000000000082
:108EF0000000000000000000000000000000000072
:108F00000000000000000000000000000000000061
:108F10000000000000000000000000000000000051
:0400000300000541B3
:00000001FF

You can see that there is 0x8000 (0x8ED0 etc) region occupied with some data in the hex file even though the program should end on 0x7FFF address as defined in linker script.

Can you please advise how to fix this? I don't want KDS to generate larger images that what fits regions defined in my .ld file.

[dusek_martin]

I think, there is something bad with:

  __DATA_ROM = .; /* Symbol is used by startup for data initialization */

and 

.data : AT(__DATA_ROM)
{
. = ALIGN(4);
__DATA_RAM = .;
__data_start__ = .;
*(.data)
*(.data*)
KEEP(*(.jcr*))
. = ALIGN(4);
__data_end__ = .;
} > m_data

sections in linker file.

I think this section is "floating" outside memory definitions. And if it is true, this is really badly designed linker file. Please help me fix that, I can't edit linker file.

[dusek_martin]

I rewrote linker script, data section to:

.data :
{
. = ALIGN(4);
__DATA_RAM = .;
__data_start__ = .;
*(.data)
*(.data*)
KEEP(*(.jcr*))
. = ALIGN(4);
__data_end__ = .;
} > m_data AT > m_text

It seems it works as expected - initilization data now goes to m_text (to flash memory), so flash memory overflow is now detected.

I noticed, that NXP uses these bad linker scripts everywhere. I have even several apps based on them. Fortunately, my program code has never been so large that initialization data wouldn't fit rest of the flash memory.

But if program code size is large enough, initialization data are silently truncated with these linker scripts. Can anyone explain how it is possible that these dangerous linker scripts are used??? Maybe I just don't understand something...

[ErichStyger]

That's strange. Did you add some kind of address offset?

I would consult the linker map file how things are allocated, or what gets placed beyond 0x8000.

[dusek_martin]

Hi Erich, thank you for your suggestion.

I can see this in .map file:

.debug_str 0x0000869e 0x2a6 C:\Users\Martin\AppData\Local\Temp\ccDVk63k.ltrans10.ltrans.o
0x19f8 (size before relaxing)

But I'm not sure what is its purpose.

Can you please advise, what can be wrong? Here are hex, map. ld and elf files of my project: https://drive.google.com/open?id=1bQKXg78OsG1jh0pkCeEM4b1XRxvj1IL0