Link failed with latest gcc-arm-none-eabi-gcc(v5.2.1)

[fs34a]

Hello, Werner:
Sorry to trigger another issue to you. Now I followed the instructions in firmware/readme.md to build mk4.
On my win7, I installed latest tool-chains:
gcc-arm-none-eabi-5_2-2015q4-20151219-win32.exe
make-3.81.exe
coreutils-5.3.0.exe

Compile is OK but there is some conflicts in the linking session.
Please see my my console:

[CC] ch3_handler.c
[CC] channel_reversing.c
[CC] config.c
[CC] config_light_programs.c
[CC] config_lights.c
[CC] crt0.c
[CC] drive_mode.c
[CC] indicators.c
[CC] light_programs.c
[CC] lights.c
[CC] main.c
[CC] persistent_storage.c
[CC] preprocessor_output.c
[CC] servo_output.c
[CC] servo_reader.c
[CC] uart_reader.c
[CC] uart0.c
[CC] utils.c
[CC] winch.c
[LD] build/firmware.elf
c:/program files (x86)/gnu tools arm embedded/5.2 2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bi
n/ld.exe: section .init loaded at [00002c00,00002c03] overlaps section .data loaded at [00002c00,00002c3f]
collect2.exe: error: ld returned 1 exit status
make: *** [build/firmware.elf] Error 1

From my understanding, the latest gcc might change _init @crti.o.

See the firmware.map:
.init 0x00002c00 0x4
.init 0x00002c00 0x4 c:/program files (x86)/gnu tools arm embedded/5.2 2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/armv6-m/crti.o
0x00002c00 _init

.init will conflict with this .data segment:
.data 0x10000000 0x40 load address 0x00002c00
0x10000000 _data = .
(.data)
.data.throttle_threshold
0x10000000 0x2 build/./drive_mode.o
.data.old_light_switch_position.5100
0x10000002 0x1 build/./lights.o
fill 0x10000003 0x1
.data.last_found.5824
0x10000004 0x4 build/./main.o
.data.st.5839 0x10000008 0x2 build/./main.o
.data.th.5840 0x1000000a 0x2 build/./main.o
.data.channel 0x1000000c 0x30 build/./main.o
0x1000000c channel
.data.next_tx_index
0x1000003c 0x1 build/./preprocessor_output.o
0x10000040 . = ALIGN (0x4)
fill 0x1000003d 0x3
0x10000040 _edata = .

It looks cortex-m0+ belongs to armv6-m branch. So I did not have any idea about this issue.
I could not upload my firmware.map here for some network issue. If you need, need me know.
Could you please take a look? What I would like to do is evaluate how many SRAM this project needs.

Many thanks and Respect to this awesome project.

BR
Locke

[laneboysrc]

Hi Locke,

I've downloaded GCC 5.2 and was able to reproduce the problem. FYI: the project was developed with GCC 4.8.2

The issue is in the linker script. The linker drags in the C run-time from GCC, but the project comes with its own little run-time, hence the conflict. Excluding the GCC run-time fixes the problem.

With the updated light_controller.ld file the compilation succeeds on 5.2, but I haven't tested it to see whether it also works.

cheers, Werner

[fs34a]

Hello, Werner:
Thanks for your so efficient response. I will take a look. I have no board to test right now as well. Anyway this could be very helpful to understand your project. It is a classical lesson in embedded system.

Thanks! ;-)

Locke

[fs34a]

Hello, Werner:
Please remove redundancy "CPU_FLAGS" in the LD session @mk4, makefile, line 88.
LDFLAGS = $(CPU_FLAGS)
LDFLAGS += -Wl,-T,$(LINKER_SCRIPT) -Wl,-nostdlib -Wl,--warn-common
LDFLAGS += -Wl,--gc-sections -Wl,-Os
LDFLAGS += -Wl,-Map=$(TARGET_MAP) -Wl,--cref
#LDFLAGS += -mthumb -mcpu=cortex-m0plus -mlittle-endian

BR
Locke