This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

undefined reference to `nrfx_spim_xfer' but enabled in sdk_config.h, etc.

I started with the peripherals/spi example, and am now trying to update to the recommended nfrx drivers. I can get the spi working fine, but I can not get the linking to work properly without doing really strange thingssdk_config.h. I have attached my sdk_config.h file.

1) I have all the enables set n sdk_config.h:

#define NRFX_SPIM_ENABLED 1

#define NRFX_SPIM3_ENABLED 1

#define NRFX_SPIM_EXTENDED_ENABLED 1

#define NRFX_SPIM_MISO_PULL_CFG 1

2) In main.c I have:

#include "nrfx_spim.h"

3) In nRF_Drivers, I have

nrfx_spim.c

When I build, the linking fails:

undefined reference to `nrfx_spim_xfer'

undefined reference to `nrfx_spim_init'

In main.c, when I context click on 'nrfx_spim_xfer' and choose go to definition, the file nrfx_spim.h is opened at the wrong location (the struct definition for nrfx_spim_xfer_desc_t). I can see nrfx_spim_xfer() and nrfx_spim_init() in the file and they are not greyed out. I can also context switch to the declarations from main.c and I am taken to the correct locations in nrfx_spim.h.

4) Under Project>Common>Code>Preprocessor>User_include_Directories and double clicking (yech! is this ever convoluted), I can see:

../../../../../../external/fprintf

../../../../../../external/segger_rtt

../../../../../../integration/nrfx

../../../../../../integration/nrfx/legacy

../../../../../../modules/nrfx

../../../../../../modules/nrfx/drivers/include

../../../../../../modules/nrfx/hal

../../../../../../modules/nrfx/mdk

../config

as required, yet when I try to compile I get the link errors. I also tried replacing my sdk_config.h with the sdk_config.h from nrfx_spim and the compile still failed (opening nrfx_spim and compiling does not fail, but it uses cdx with no info on how to modify it to get rid of cdx). Also, it's not a matter of just getting my project to link, it's a matter of how to use libraries and linking in SES as I have to make many additional changes in the future.

I'm assuming there is something I've missed, but I've searched all the posts in devzone that are related, and I can't find out what needs to be done and/or how to understand what is necessary in the setup.

Is it recommended to get not use SES and set up a gnu flow with Makefiles?

  • From where did you hear that it was recommended to use the nrfx drivers? Have you seen the note on this page?

    "The migration process is not required and often results in exactly the same functionality. Consider migration only if you want to take advantage of the new features offered by nrfx."

    If you're going to switch to the nrfx drivers I would recommend you to think thoroughly about why you're doing so, since for all intent and purposes the legacy drivers does the job (as far as I'm aware of). In addition, all the samples are written using the legacy drivers and you may save a lot of time and effort to stick with the legacy API.

    Best regards,

    Simon

  • On the same page as the note you directed me to it states:

    For new applications, consider to use the new nrfx API.

    This is in coflict with the statement you quoted; for someone new, it is hard to know which statement to follow. For the SPI, it appears there is one example for the old drivers and one example for the new drivers, but unfortunately with dcx. There are no examples for using the SPI with two slave devices, but there is one devzone article on how to switch the pin when using hardware chip select. There is no examples on using manual chip select with the GPIOs which seems the safer way to go.

    And my application is a new application. In addition, I was seeing errors when the spi clock frequency was low (they went away at higher clock frequencies - this is really counterintuitive but might be due to the hardware chip select being too close in time to the clock edge), so I thought that using rx_delay available in the extended configuration for spi4 of the new driver might help me track this down as this type of error can be dangerous in the field.

    So we have the old drivers and two new drivers (one with Easy Dma and one without) and it appears they conflict with one another in sdk_config.h especially when the Wizard is used (and one doesn't see what is happening). I find tracking down all the conditional #includes across multiple files to be very complicated; maybe it's my inexperience. I am curious if this is just me or if others have similar issues? I think I've read almost every article in devzone regarding the SPI's and it doesn't really help on this issue.

  • If you want to use the NRFX API/definitions, you could try out the solution provided by Sherief in this thread

    Best regards,

    Simon

  • I have a previously developed (non BLE) application where I used nRFX_SPIM as I followed the same advice:

    For new applications, consider to use the new nrfx API.

    I now needed to amend to add in BLE functionality and I've hit the exact same problem when I used the BLE UART app peripheral example as my template.

    I thought to reply to this post to bump up the issue again because from what I've read on the forum this issue has been raised on a number occasions, starting with SDK version 15.x and we are now on SDK version 17.02.

    It appears that nothing much has changed...but I could very easily have missed something.

    So Nordic Semi, what is happening with the migration. Are developers still expected to manually fix this legacy integration issue - which costs us developers much time and is effort wasted as we are repeating what someone else has probably already solved.

    For other developers, what lessons have been learned when encountering this issue and then fixing. I will be interested to learn... or is the suggested solution by "Sherief" the only way to do it.

    PS (UPDATE): I just followed Sherief's build setting suggestion and it did not work. Now stuck with a fatal runtime error once I got it to compile (after more manual code hacks).

Related