spi_interrupt not ocuurs

[pramithkv]

I am using spi_master.c for spi communication with nRF51822EK.

And i had sent and recieved data packet successfully for 1st time with spi_master_send_recv(). When i sending 2nd packet of data it writes the initial bytes(1st 2 bytes),enables spi interrupt also, but m not getting spi interrupt.

I am using sdk6 and sd7. SPI interrupt priority---3

[jor]

hi pramithkv,

i have a similar problem. I made a custom board and am communicating to another chip via SPI, sending 4 bytes at a time. The first 2 bytes are sent out just fine, but the next 2 are always 0. After consulting the nrf51822 product specification and reference manual, it seems that the SPI buffer needs to be reloaded (since buffer can hold just 2 bytes), for which i think an interrupt needs to occur. I am not using the original "spi_master_example" but rather "ble_app_hrs" example which i modified to include SPI communication. From the answers and comments posted on this link devzone.nordicsemi.com/.../ it seems like there is an issue with the timer. Indded, not initializing application timer in the "ble_app_hrs" example resulted in all 4 bytes being sent out on SPI. I didn't manage to figure out exactly how to correctly use the SPI, but for now seems like you might want to check the interrupt/timer initialization.

[Stefan Birnir Sverrisson]

Hi

Yes you are correct, the SPI peripheral only holds 2 bytes and can not hold more data. When the SPI has transmitted one of those bytes, it will give a READY event, which you can use to load an additional byte to the SPI->TXD register.

You should however make use of the spi_master.c driver which does all this work for you that is mentioned above. The spi_master_example uses the spi_master.c, so you could do similar things in your code to send multiple bytes over SPI. You simply initialize the SPI driver, then you start sending data.

In the SPI driver, you send your data, then you get a callback when the SPI transaction (call to spi_send_recv function) is finished. If you want to send more data over the SPI, you should make sure the former SPI transaction is complete. Ensure this with setting a "spi_finished" flag in your spi callback function and then call spi_send_recv function from main context. This is described on this thread.

Update 10.2.2015 You have two options for priority of the SPI callback

APP_IRQ_PRIORITY_LOW
  - The SPI interrupt has the same priority as the softdevice callbacks.
  - The SPI interrupt needs to wait for any softdevice callback handler to finish execution.
  - You can call softdevice functions from the SPI interrupt handler, i.e. sd_* functions.
APP_IRQ_PRIORITY_HIGH
  - The SPI interrupt has higher priority than softdevice callbacks
  - The SPI interrupt will preempt execution of any softdevice callback
  - You can not call softdevice functions from the SPI interrupt handler, i.e. sd_* functions

I suspect it should work if you choose APP_IRQ_PRIORITY_LOW priority for the SPI interrupt if you also make sure that you do not call the spi_send_recv function before you get the callback that the former SPI transaction is complete.

[jor]

Does it make any difference if SPI is used as describes in the "spi_master_example" when SoftDevice is enabled? I included SPI communication into the "ble_app_hrs" and I found out that including "spi_config.SPI_PriorityIRQ = APP_IRQ_PRIORITY_HIGH;" into the code works as expected and all bytes are sent correctly, while not modifying the SPI code results in behavior i described above.