Repurposing NFC Pins for SPI Issues

[Josh Grob]

Hello,

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.

Josh

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

NFCpins_reassigned.png

using_pins_22_23.png

[RK]

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 file to make sure the NFC code is included, single step it to ensure it's being run.

[Dave_couling]

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

CFLAGS += -DCONFIG_NFCT_PINS_AS_GPIOS #to free up NFC

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

[RK]

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.

[Josh Grob]

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.

[RK]

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.