Ready interrupt in SPI RAW master (Serialization)

RE: Ready interrupt in SPI RAW master (Serialization)

Ole Bauck — Fri, 27 May 2016 13:49:55 GMT

Sorry for the late answer. It does not make sense that you are not going into the GPIOTE_IRQHandler before after the SPI transaction is done. The SPI driver is set up in non-blocking mode with priority level APP_PRIORITY_LOW, so between each byte it should go to another interrupt or to main context. If GPIOTE interrupt is APP_PRIORITY_HIGH the SPI should not run before the GPIOTE interrupt if a GPIOTE interrupt is pending, which it should be from the moment READY signal change level.

Have you figured out what was wrong? I cannot help you with no further information.

RE: Ready interrupt in SPI RAW master (Serialization)

yc38 — Tue, 12 Apr 2016 15:09:44 GMT

I agree with your remarks and effectively, SWI3 interrupt (use in SPI RAW driver) have higher priority level than GPIOTE. I already changed GPIOTE_CONFIG_IRQ_PRIORITY to HIGH.

But I would like to understand why using the default code provided by Nordic seems to cause a different operation from what is presented in SDK documentation?

I'm sorry about your questions but I can't give you much more info because it's confidential (professional project). I can just tell you that, for the purposes of application, nRF51 must manage the BLE and acts as the master while the 2nd microcontroller is seen as a peripheral (slave). Use SPI RAW master on nRF51 would be very convenient for exchanges coordination between the two microcontrollers.

RE: Ready interrupt in SPI RAW master (Serialization)

Ole Bauck — Thu, 31 Mar 2016 12:20:59 GMT

Looks like the GPIOTE interrupt is delayed. Both GPIOTE and SPI use interrupt level APP_IRQ_PRIORITY_LOW. You may be doing something in another interrupt (event handler) that is delaying the GPIOTE interrupt? Try changing GPIOTE_CONFIG_IRQ_PRIORITY in nrf_drv_config.h to APP_PRIORITY_HIGH.

Using nRF as master and another MCU as slave (connectivity chip) is not exactly what the serialization is meant for, it should be the other way around. What is the other MCU and how is the SoftDevice (for connectivity) implemented there. This is not related to your problem, I am just curious.