Repurposing NFC Pins for SPI Issues

grobber15 gravatar image

asked 2017-06-19 20:08:28 +0100

updated 2017-06-19 20:12:26 +0100


I am seeing something strange wrt to reassigning the NFC pins (9,10) on my Rigado BMD-300-EVAL using nRF SDK12.1 and gcc to build. I have two SPI based sensors on separate pins using two SPI interfaces (SPI0 and SPI1) for SPI1 we decided to use pins (10,9,11,7) for SCK, MOSI, MISO, and SS respectively. I followed the forums and discovered that setting the CONFIG_NFCT_PINS_AS_GPIOS C and ASM flag in my makefile should do the trick of freeing up those pins. However, after I do so I noticed that the CLK and MOSI pins are pegged high (as opposed to low like what happens in SPI0), and the CLK doesn't pulse when the SS goes active low. See attached logic analyzer image "NFCpins_reassigned.png". When I switch the SCK and MOSI to other pins such as 22, 23 SPI1 functions as normal and I see low SCK and MOSI and communication over the wire. See "using_pins_22_23.png". I wondering if anyone has seen this behavior before and can give guidance? We have made an architectural decision to use pins 9,10 for this SPI bus, and do not have the option to switch pins or combine to SPI0 at this point.

As workarounds I tried to force the pins 9,10 low using GPIOTE, before init of the SPI1 but that didn't have an effect, and the pins still remained high with no communication. Here is the code I used for that:

err_code = nrf_drv_gpiote_init(); //first make sure pins 9 and 10 are low nrf_drv_gpiote_out_config_t config = GPIOTE_CONFIG_OUT_SIMPLE(0); err_code = nrf_drv_gpiote_out_init(SPI1_SCK_PIN, &config); err_code = nrf_drv_gpiote_out_init(SPI1_MOSI_PIN, &config);

Lastly, I tried setting the SPI mode (NRF_DRV_SPI_MODE_0-3) to each of the four settings, and there is no change in behavior (no clk pulse nor communication).

Thanks for the time, and any help is greatly appreciated.


P.S - SPI0 functions perfectly in any SPI1 configuration so I don't think there is a contention issue between the two.



edit retag flag offensive close delete report spam


So the obvious guess would be that you haven't actually reconfigured the pins to GPIOs, because they are still acting as NFC pins. If that's the case, nothing you do in the GPIO module nor SPI module is going to make any difference at all.

So halt in the debugger and go look at the correct UICR register and see if the correct bits are set. That's in the NFCPINS register 0x20c, so at 0x1000120c (your debugger should have a register map for all this to make things much easier). If the least significant bit isn't clear, you're in NFC mode. (see the documentation on NFCPINS for the bit assignments).

If that's the case, go look at the startup code for whatever SDK you're building with ( mine is at components/toolchain/system_nrf52.c) check the define, check the preprocessor output of compiling that ...(more)

RK ( 2017-06-19 23:33:40 +0100 )editconvert to answer

Its an issue with the impedance on those pins. Add this line to the Makefile file to fix it:


This defines these pins in the system_nrf52.c file for general use.

Dave_couling ( 2017-06-20 01:14:56 +0100 )editconvert to answer

he already said he did that, although I suggested he check it's actually happening. And that define doesn't change the impedence on the pins, it stops them being used by default as NFC pins (which are driven) and returns them to the GPIO system for us.

RK ( 2017-06-20 01:17:49 +0100 )editconvert to answer

Thanks for the reply RK, and I will report back my findings shortly. One thing I also notice is that when I comment out the CONFIG_NFCT_PINS_AS_GPIOS flag in my makefile I get different behavior then when it is included. When it isn't included the transfer calls hangs (never returns) and my SS line is now pegged low. Thus, the define in my system_nrf52.c is getting called. Thanks again for the comment.

Josh Grob ( 2017-06-20 02:08:24 +0100 )editconvert to answer

I just looked at the docs again to be sure and the only oddity about those pins is slightly higher capacitance (which makes them slightly a worse choice for high speed serial comms) but once the NFC mode is turned off (and the chip reset) they're normal GPIO pins.

Another test you could try is setting them into GPIO mode and then just driving them to different levels, without enabling the SPI module, to be sure they are acting as GPIOs.

RK ( 2017-06-20 02:56:04 +0100 )editconvert to answer

Thank you RK, and a comment you made on another post led me to the answer. In this post you mentioned that the 0ohm resistors needed to be removed on the nRF DK, and I realized that I hadn't checked the schematic on the BMD-300-EVAL board lately. Turn out you need to solder the J09, J10 jumper. After I did that I saw the clock pulses and communication.

Now here is the oddity, when the SPI1 frequency is at 4M I get different hex values then expected. When I knock it down to 1M I get the values I expect as shown in "using_pins_22_23.png" above. At this point I am happy I can see the correct communication, and will investigate the clock frequency separately. Thank you again RK for the timely help!

Josh Grob ( 2017-06-20 04:22:34 +0100 )editconvert to answer

that might be the capacitance issue I mention above, at 4MHz that can make a difference, at 1, much less so.

RK ( 2017-06-20 04:24:56 +0100 )editconvert to answer