I am trying to run the SPI code on an NRF52382 based custom board. I am using the NRF 52 DK, Keil uVision 5.0 , SDK 15.2.
I cannot set and clear the SPI relevant pins on my custom board as gpios. The pins I am using are:
SPI_SS_PIN = P0.6SPI_MISO_PIN = P0.8SPI_MOSI_PIN = P0.9SPI_SCK_PIN = P0.7
and the schematic showing these pins is:
I was successfully able to toggle all four pins above, (as well as the RESET P0.21) as GPIOs after I did following:
1. went to sdk_config.h and changed NRF_LOG_BACKEND_UART_TX_PIN to pin 5 instead of 6
2. went to OPTIONS FOR TARGET -> C/C++ -> Preprocessor Symbols -> Define and added " CONFIG_NFCT_PINS_AS_GPIOS" after nrf52382.... and removed the line " CONFIG_GPIO_AS_PINRESET"
But as soon as I run the SPI example code in SDK15 I am unable to toggle these pins and use them as gpios. Especially the SPI_SS_PIN which is pin 6, as soon as I run the SPI code this pin fixes to high value and will not clear/go low.
My thinking is there something wrong with the way the SPI example configures the spi relevant pins?
https://devzone.nordicsemi.com/f/nordic-q-a/18546/gpio-not-set-or-clear-with-spi-code this guy seemed to have had the same problem running SPI and with the CS pin...
Update : I am using SPI instance 0. I am trying to run a single transfer without using DRDY... Following settings:
spi_config.frequency = NRF_DRV_SPI_FREQ_4M; spi_config.mode = NRF_DRV_SPI_MODE_1; spi_config.irq_priority = APP_IRQ_PRIORITY_HIGHEST;
Depends perhaps on when you are doing a set/clear test; try setting the SPI_SS_PIN pin to NRF_DRV_SPI_PIN_NOT_USED before initialising the spi, and see if that allows manually set/clear of the /CS pin. Note in this case a manual configuration of the pin to Output must be made as the SPI driver is no longer controlling the pin. The reason for doing this is to ensure nothing else is interfering with the pin; the spi driver does not control the /CS pin with hardware spi but instead runs a set or clear instruction encapsulating the hardware spi transmission. That means the user can just as easily do the set/clear before and after the spi transfer, or allow the handler to do it as in your case.
Other devices have hardware control over the /CS pin (similar to SCK, MOSI and MISO), but not the nRF52832.
Also you are probably aware, but if you are testing on a DK then pin 6 is connected in hardware ..
Updated: Now I am configuring the CS pin after I initialize the SPI and it seems to work because the pin goes down to 0.7 V from the earlier Vdd HIGH 3.3V. However, even though the voltage value reduced I do not think this means the SPI_SS_PIN is LOW because the LOW value on my board is typically in millivolts.
I am thinking the 0.7V for the CS pin is a floating value. And I do not get why I cannot clear the SPI_SS_PIN? Could this be because the SPI_SS_PIN needs to have a falling edge (and not clear 0) for the SPI peripheral device to be connected?
Just possible your spi device requires a harder active-low drive, though I doubt it. You can test this by increasing the low drive power, if you haven't already.
I assume nothing else connects to the /CS pin ..
As for the falling edge vs. 0, no the /CS pin is only required to be low while the clock and data are active, when high clock and data are ignored. If possible I would disconnect the /CS pin at the spi slave device and see what voltage it goes to; with the /CS disconnected you can short MOSI and MISO together and do a loop-back test to verify data transmitted is actually received back at the spi handler. You mention /DRDY; is this an AFE?