BSS fill with data_alignment

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

BSS fill with data_alignment

ソリューションへジャンプ
1,934件の閲覧回数
leccy
Contributor III


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.

ラベル(1)
0 件の賞賛
返信
1 解決策
1,736件の閲覧回数
BlackNight
NXP Employee
NXP Employee

Hi Alex,

I don't think the GNU linker in CodeWarrior handles this differently. The GNU linker is going through the linker script file in a linear way, and does not try to fill up things or distribute variables into different memory areas (I whish the GNU ld could do this, this is a long time wish from many users).

Anyway, the thing is that you should allocate the USB buffer at the beginning of a section (which is already aligned to the 512 byte boundary. That way the linker has not to add *fill* bytes. See https://mcuoneclipse.com/2014/07/11/switching-arm-gnu-tool-chain-and-libraries-in-kinetis-design-stu...

I hope this helps,

Erich

元の投稿で解決策を見る

0 件の賞賛
返信
3 返答(返信)
1,737件の閲覧回数
BlackNight
NXP Employee
NXP Employee

Hi Alex,

I don't think the GNU linker in CodeWarrior handles this differently. The GNU linker is going through the linker script file in a linear way, and does not try to fill up things or distribute variables into different memory areas (I whish the GNU ld could do this, this is a long time wish from many users).

Anyway, the thing is that you should allocate the USB buffer at the beginning of a section (which is already aligned to the 512 byte boundary. That way the linker has not to add *fill* bytes. See https://mcuoneclipse.com/2014/07/11/switching-arm-gnu-tool-chain-and-libraries-in-kinetis-design-stu...

I hope this helps,

Erich

0 件の賞賛
返信
1,736件の閲覧回数
leccy
Contributor III

Thanks Erich

Already done that from my same question on yr blog.

BTW, I was using the CW tool-chain on the CW project, not the GNU.

0 件の賞賛
返信
1,736件の閲覧回数
BlackNight
NXP Employee
NXP Employee

Hi Alex,

ok, then it makes sense: the non-GNU ARM toolchain used a custom linker implementation, and that linker was able to fill gaps in the memory map.

Erich

0 件の賞賛
返信