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

SPI Master pin set and clear

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.6
SPI_MISO_PIN = P0.8
SPI_MOSI_PIN = P0.9
SPI_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...

Thank you! 

Parents
  • 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 ..

  • 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?

Reply
  • 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?

Children
  • NRF_LOG_INFO descends through layers of macros, Nordic might help with that as I don't use it. This definition is also in that project for pin 6:

    // <o> NRF_LOG_BACKEND_UART_TX_PIN - UART TX pin
    #ifndef NRF_LOG_BACKEND_UART_TX_PIN
    #define NRF_LOG_BACKEND_UART_TX_PIN 6
    

  • Hi again
    If I am changing my UART _TX pin from P0.6 to another pin in my sdk_config.h file and pca10040.h file (are these two the only files where I need to make this change in order to disable use of P6 as uart??) what would be a suitable pin number to change it to? I was changing uart_tx from 6 to 5 but that gives me a FATAL ERROR with my putty terminal (so I'm guessing the uart has problems working after). 
    I need both SPI and UART functionality (i.e. I need to use NRF_LOG_INFO). 

    Here is the pin layout of my custom board. 

    Thanks again. 

  • Any of the pins you mention should work, there is no preferred pin. If you have a fatal error it is probably from app_error_fault_handler() which can be the default handler in app_error_weak.c or a handler of the same name you have supplied. In either case put a breakpoint on the first code line of that handler and enable Stack Trace in the IDE debugger so you can see where the error came from. You can do that in any of the usual IDEs (IAR, SES, Keil ..) and see the sucessive code lines which caused the error; Then place a breakpoint on any of the suspect lines and restart-execute again to see what data was causing the error.

    I see you have analogue inputs; if the SAADC is enabled I suggest commenting out that code in case one of those pins is also set as an adc function. With no pins showing up in a search (try search " 6") it is possible that there is some board hardware issue. A return to the bare-bones example with only the pin 6 changed might be the next step if any of the above doesn't help ..

Related