nRF52 SPI loops when waiting for NRF_SPI_EVENT_READY after initialisation

[DerPMO]

So I switched from Bluemod+S (nRF51822) to Bluemod+S42 (nRF52832) on my custom board and am trying to adapt my existing code to work on the newer model. Apart from various obvious and some not so obvious changes I managed to figure out myself, I'm now stuck on the initialization of the SPI:

void hal_spi_init()
{
	nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG; 
	spi_config.ss_pin   = NRF_DRV_SPI_PIN_NOT_USED; //slave select is handled seperatly
	spi_config.miso_pin = SPI_MISO_PIN; //defined in  custom_board.h
	spi_config.mosi_pin = SPI_MOSI_PIN; //defined in  custom_board.h
	spi_config.sck_pin  = SPI_SCK_PIN; //defined in  custom_board.h
	uint32_t err_code = nrf_drv_spi_init(&spi, &spi_config, NULL);
	APP_ERROR_CHECK(err_code); //without setting an event handler, the transfer function just waits until the transmission is finished
}

which works without any error. Subsequently I'm trying to send data to the slave, but the nrf_drv_spi_transfer function loops indefinitely at while (!nrf_spi_event_check(p_spi, NRF_SPI_EVENT_READY)) {} in spi_xfer.

It did (still does) work on my old setup with the nRF51822 and I don't understand whats different now.

I already found similar questions here and here but those didn't help me.

I'm using S132 & SDK 12.3.0 (S130 & SDK 12.3.0 on the old setup)

[MartinBL]

I'm not able to reproduce this.

1. Have you tried the simple SPI example in the SDK, just to rule out bad wiring and slave?
2. Are you calling nrf_drv_spi_transfer() from within an interrupt context with higher priority than the SPI interrupts? Could it be an interrupt priority issue?

[DerPMO]

1. I could rule out that it is a problem with the Hardware, the SPI example works!
2. No, but I'm closer to the actual problem.

I was able to find out that this problem ONLY occurs after the softdevice (S132) is enabled. So I added everything necessary to start the SD to the spi example, and could replicate this behaviour, although only on my custom board.

Since I have the SPI on different pins than the nRF52DK, this is probably part of the problem: I'm using the ports as they are defined for the Bluemod+S42 module: GPIO2 -> MOSI (translates to 9) GPIO5 -> MISO (translates to 0) GPIO8 -> CLK (translates to 1)

So the softdevices is probably expecting/doing something else on these pins, although I'm not sure how the wiring from Bluemod -> nRF actually looks.

Also it did work with the Bluemod+S (nRF51822 & S130), I don't think they changed the PINs between this versions.

[DerPMO]

And you can replicate the problem on a nRF52DK by adding the softdevice to the spi example and changing the SPI pins:

nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG;
spi_config.ss_pin   = NRF_DRV_SPI_PIN_NOT_USED;
spi_config.miso_pin = 0;
spi_config.mosi_pin = 9;
spi_config.sck_pin  = 1;
APP_ERROR_CHECK(nrf_drv_spi_init(&spi, &spi_config, NULL));

[MartinBL]

Are you able to try to disconnect the slave from the SPI pins? I have tried to reproduce the issue and I'm seeing some similar issues too. However, it seems to be caused by the slave I use since the SPI works when I disconnect it.

Note that P0.00 is one of the two pins used for the Low Frequency crystal, but looking in your module's datasheet it doesn't seem to have one and it shouldn't be a problem. I have tried pin 0 on an nRF52 (without disconnecting the external crystal actually) and it seems to work.

[DerPMO]

Problem found: The Bluemod+S and the Bluemod+S42 are Pin-compatible ONLY regarding their own firmware when you use an external MCU. But internally, the pins have been rearranged, so the configuration for the spi in my own firmware was simply wrong.