SPI Slave Chip select as an Interrupt

[raju]

Hi, I am planning to interface nRF51822 SPI( Slave ) port with another microcontroller. to achieve proper SPI synchronization , whenever nRF is ready to transmit data on SPI bus, it makes a GPIO output high ( Interrupt to microcontroller name it as INTERRUPT2CONTROLLER ) . once SPI Master (Microcontroller) ready to read the data by initiating SPI Chipselect, I want to disable or make it low same INTERRUPT2CONTROLLER Gpio pin.

I would like to know ,is it possible to configure a gpio pin as interrupt and spi slave chip select? I will be very much thankful, if share an example code to configure GPIO pin an interrupt. Thanking you very much. Regards, Raju

[Vince]

Hi Raju,

IMHO the answer is yes, it is possible, but not at the same time. The easiest way is probably to use an external pull-up resistor on the INTERRUPT2CONTROLLER line and drive it both side as open-drain. If your master uC doesn't provide this functionality, you can drive it low when you want it low and configure the pin as high-Z input when you want it high; the pull-up resistor will do the rest. Just take care never to drive that line high, as it could result in high current flow and even IO driver destruction.

So, the following (untested) code should configure the pin as an active-high interrupt signal output, and drive it low (provided CS_PIN is properly defined):

// disable SPI
NRF_SPIS1->ENABLE &= ~(SPIS_ENABLE_ENABLE_Enabled << SPIS_ENABLE_ENABLE_Pos);

// set CS_PIN as low-driven output
nrf_gpio_pin_clear(CS_PIN);
nrf_gpio_cfg_output(CS_PIN);

When your nFR device is ready to transmit, a call to spi_slave_init should cleanly restart the SPI port and configure CS_PIN back to input, making the line go high again.

[edit (answering Raju's comment)]

According to nRF51 reference manual chapters 13 (GPIO) and 26 (SPIS), enabling SPIS will override GPIO pins configuration, denying the use of CS as general purpose output. Anyway, you wanted the slave to hold the line low as long as there is no data to send, isn't it? So here are some workarounds I can think of right now, as I assume using a dedicated IRQ line is not an option:

WA1: accept compromise

Is it really necessary to have an IRQ? Can't you just buffer data on slave side and poll it with the master? And if it is about power consumption, can't you delay master-to-slave transaction until the slave has data to send?

WA2: the dirty way

Only disable the SPIS when you need to draw an IRQ. You will need to make the interrupt active on falling edge. This will most probably result in data collision, but statistics and a good handshake protocol could save you...

WA3: if the nRF is the only slave device on the SPI bus

Use SCK or MOSI to trigger the SPIS reactivation.

WA4: the hairy one

Send an 'illegal' SPI pattern you are sure the master will never send otherwise to trigger the SPIS reactivation, e.g. a pulse burst on MOSI while SCK stands still.

[/edit]

Please comment :)

Best regards,

Vince

[raju]

Hi Vince, Thank you very much for your reply. here there are 2 types of communications possible.

1. when every nRF SPI Slave is ready with the data, sends an interrupt to Microcontroller ( By making INTERRUPT2CONTROLLER high) as a response Master initiates SPI transfer. ( can say SPI Master read operation )
2. Master itself want to send the data nRF ( Master SPI Write Operation)

second scenario can occur at any time.( Slave should be ready always to receive the data) in this case how can I manage. is it possible that SPI slave CS pin can be used as CS and Interrupt at the same time? Thanking you very much. Regards, Rama Raju