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)

[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.