(solved, need feedback) Can't figure out how to link gzll_nrf51_gcc.a with s130

[akohlsmith]

I'm trying to use the gazell library with the s130 softdevice (s210 only works on nrf51422).

Without changing anything, I can't find the gazell header files. That's an easy fix:

LIBRARY_PATHS += $(SDK_INCLUDE_PATH)proprietary_rf/gzll

now the application compiles, but cannot link. Specifically:

_build/main.o: In function `main':
main.c:(.text.startup.main+0x70): undefined reference to `nrf_gzll_init'
main.c:(.text.startup.main+0x76): undefined reference to `nrf_gzll_set_base_address_0'
main.c:(.text.startup.main+0x7a): undefined reference to `nrf_gzll_enable'
collect2: error: ld returned 1 exit status

I believe this is because neither gzll_nrf51_gcc.a nor gzll_nrf51_sd_resources_gcc.a are being linked in.

nm -a shows nrf_gzll_init is within the former static library:

$ arm-none-eabi-nm -a nrf5x-base/sdk/nrf5_sdk_12.2.0/components/proprietary_rf/gzll/gcc/gzll_nrf51_gcc.a  | grep nrf_gzll_init
00000658 T nrf_gzll_init

I've momentarily hacked in the following:

LDFLAGS += -L $(SDK_PATH)components/proprietary_rf/gzll/gcc -l:gzll_nrf51_gcc.a

I'm now running into an issue I don't know how to resolve:

$ make V=1
BUILD OPTIONS:
  SoftDevice  s130
  SDK         12
  nRF         nrf51422
  RAM         16 kB
  FLASH       256 kB
  Board       BOARD_NULL

arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -march=armv6-m -L ../../nrf5x-base/make/../make/ld -T ../../nrf5x-base/make/../make/ld/gcc_nrf51_s130_2.0.1_16_256.ld -Wl,--gc-sections -Wl,-Map=_build/gzl_s130.Map -L ../../nrf5x-base/make/../sdk/nrf5_sdk_12.2.0/components/proprietary_rf/gzll/gcc -l:gzll_nrf51_gcc.a _build/startup_nrf51.os _build/system_nrf51.o _build/main.o _build/softdevice_handler.o _build/app_util_platform.o _build/app_error_weak.o _build/app_timer.o _build/app_error.o _build/nrf_drv_common.o _build/nrf_drv_clock.o _build/led.o  -o _build/gzl_s130.elf
_build/main.o: In function `main':
main.c:(.text.startup.main+0x70): undefined reference to `nrf_gzll_init'
main.c:(.text.startup.main+0x76): undefined reference to `nrf_gzll_set_base_address_0'
main.c:(.text.startup.main+0x7a): undefined reference to `nrf_gzll_enable'
collect2: error: ld returned 1 exit status

It's finding the library (if I change the path or the name of the library, it rightfully complains) but it does not seem to be linking it in.

Any suggestions?

[akohlsmith]

I'm an idiot.

It's important to specify the library after the object files.

arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -march=armv6-m -L ../../nrf5x-base/make/../make/ld -T ../../nrf5x-base/make/../make/ld/gcc_nrf51_s130_2.0.1_16_256.ld -Wl,--gc-sections -Wl,-Map=_build/gzl_s130.Map _build/startup_nrf51.os _build/system_nrf51.o _build/main.o _build/softdevice_handler.o _build/app_util_platform.o _build/app_error_weak.o _build/app_timer.o _build/app_error.o _build/nrf_drv_common.o _build/nrf_drv_clock.o _build/led.o  ../../nrf5x-base/make/../sdk/nrf5_sdk_12.2.0/components/proprietary_rf/gzll/gcc/gzll_nrf51_sd_resources_gcc.a -o _build/gzl_s130.elf

Works fine.

Now my question (so I can send another PR) -- How should I structure this in the nrf5x-base Makefile? I don't see an existing method to specify libraries. Currently I have resolved this by creating a $(LIBS) variable and using it during the linker phase:

LIBS += $(SDK_PATH)components/proprietary_rf/gzll/gcc/gzll_nrf51_sd_resources_gcc.a

and then lower in the Makefile, when generating the $(HEX) target:

$(HEX): $(OBJS) $(OBJS_AS)
        $(PRINT_LD)
        $(Q)$(LD) $(LDFLAGS) $(OBJS_AS) $(OBJS) $(LIBS) -o $(ELF)

How would you prefer to see this for a more generic solution?

Finally, how would you recommend a cleaner/neater way to specify that the user wants to use Gazell or Enhanced ShockBurst in the application Makefile so the nrf5x-base Makefile can link in the library? I was thinking to have a USE_GZLL=1 or USE_ESB=1 and look for that.

[brghena]

Sorry I didn't get you feedback in a very timely manner, but I think the PR looks great.

Now that #29 is pulled, does that solve this issue?

[akohlsmith]

yes, works here with #29 pulled in. Thanks!