AnsweredAssumed Answered

BSS fill with data_alignment

Question asked by Alex Tait on Jul 12, 2016
Latest reply on Jul 12, 2016 by Erich Styger


I have recently ported USB MSD boot-loader AN4379 from CW 10.4 to KDS.

 

With some adaptations, we have been running the boot-loader on several products for a couple of years.

 

On KDS, however, I cannot get the project to compile without a linker error.  It shows an over-spill of 840 bytes in RAM.

 

Looking at the .map file, I see there is a *fill* section in BSS of 0x1e4 bytes (484):

.bss            0x1fff0400     0x1b40 load address 0x00008600

                0x1fff0400                __START_BSS = .

                0x1fff0400                PROVIDE (__bss_start__, __START_BSS)

*(.bss)

.bss           0x1fff0400       0x1c c:/freescale/kds_3.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/5.4.1/armv7e-m/crtbegin.o

*(.bss*)

*fill*         0x1fff041c      0x1e4

.bss.g_Mem     0x1fff0600      0x400 ./Sources/USB/driver/usb_dci_kinetis.o

.bss.g_bdtmap  0x1fff0a00        0x4 ./Sources/USB/driver/usb_dci_kinetis.o

                0x1fff0a00                g_bdtmap

 

The global g_Mem must be aligned to a 512 byte boundary since it is filled by the DMA:

#if defined(__GNUC__)

__attribute__((__aligned__(512)))

#elif defined(__IAR_SYSTEMS_ICC__)

#pragma data_alignment = 512

#endif

static uint_8 g_Mem[BYTES_1024];

 

Any ideas why the linker does not place any other variables in the BSS region up to g_Mem?

The CW10.4 compilation does this.

Outcomes