nRFSDK: Symbol collisions when trying to read bootloader version from the app?

[charles_fi]

nRF52840, nRFSDK v17.0.1, S140 v7.2.0

We'd like our application to be able to read the bootloader version from the app. I've found the module nrf_dfu_settings.h, and it looks like the way to do it is to call `nrf_dfu_settings_init()` and then read the global variable `s_dfu_settings` without modifying it.

But, when I add nrf_dfu_settings.c to our application build, I also need to add nrf_dfu_flash.c to the application build, because nrf_dfu_settings calls nrf_dfu_flash functions. I don't mind doing this, but then I get a link collision on the NRF_FSTORAGE_DEF, which is already defined in fds.c, which we're using in our application:

arm-none-eabi/bin/ld: nRF528xx/obj/nrf5_sdk/fi_fds/fi_fds_fc3_f3/fds.o:fds.c:68: multiple definition of `m_fs';
nRF528xx/obj/nrf5_sdk/libnrfsdk_fc3_f3/nrf_dfu_flash.o:nrf5_sdk/17.0.2/components/libraries/bootloader/dfu/nrf_dfu_flash.c:57: first defined here

This is in nrf_dfu_flash.c:

fds.c:

If we're just reading, we can probably just read the page ourselves manually, but we also eventually want to enable DFU from within the app, and for that it looks like we may need to write to the settings page as well.

What's the intended way to do in-app DFU and use FDS together, using the nRF SDK?

Thanks,

Charles

[Einar Thorsrud]

Hi Charles,

The DFU settings is used by the bootloader (and that is the only place where nrf_dfu_settings_init() should be called from). As you only want to read data from the bootloader settings page I would not start trying to use the bootloader library which was not intended ofr this. Instead, you can just read the data directly for the static location it is in.

You could either just get the address and dereference a pointer to it directly (I would do this), but this would then fail in the highly unlikely case that there is ever an update where the bootloader settings format changes. An alternative could be to look at the implementation of nrf_dfu_settings.c where you can see how the m_dfu_settings_buffer is placed at the correct location. And then you can treat that as a pointer to nrf_dfu_settings_t instance, and read the bootloader_version from there.

For in-app DFU the situation becomes a bit different, and then you need to write to the settings page. The issue you faced here is related to using the same name in two different modules that were never intended to be used in the same binary. Generally though, implementing DFU suppor tin the application should not conflict with FDS, and you can have multiple fstorage instances in a single binary.

[charles_fi]

Great, thanks for the clear and quick response, Einar!