SPI from BLE event

RE: SPI from BLE event

MartinBL — Tue, 21 Nov 2017 13:47:27 GMT

Q2. Something like this:

volatile bool start_spi_tx_flag = false; // Make sure to declare flag as 'volatile'

// In BLE event handler
void some_ble_event_handler(...)
{
	// [....]
	start_spi_tx_flag = true;
}

// In main 
int main(void)
{
	// [....]
	
	while(1) // Main while forever loop
	{
		// [....]	
		if(start_spi_tx_flag)
		{
			// Do SPI transfer and set start_spi_tx_flag = false when you are ready
		}		
	}
}

Q3. Please have a look at the scheduler library in the SDK.

RE: SPI from BLE event

schef — Tue, 21 Nov 2017 09:46:21 GMT

If i understand corectly solution nr. 2 would include a bool and a buffer[20]. When the write to the characteristic is finished i would check in main context if my bool is true and then write to the spi. I don't understand the implementation of the 3. solution.

RE: SPI from BLE event

MartinBL — Tue, 21 Nov 2017 07:35:39 GMT

It could it be caused by interrupt nesting, as @endnode suggests, or some interrupt priority issue.

You start an SPI transfer from within an interrupt context (the BLE event) and then wait for a transfer complete interrupt with while (!_xfer_done). However, what probably happens is that since the SPI interrupt has lower priority than the BLE event, the SPI interrupt will not be executed before your BLE event code is completed because it is queued behind the BLE event. Hence the flag _xfer_done is never set, and you effectively end up waiting forever in the while (!_xfer_done) loop.

Solutions are:

Raise the SPI priority to a level above the BLE event level (level 4), as you have already done by setting the level to 3. Then the SPI interrupt will not be queued behind the BLE event, but executed right away. Then the _xfer_done flag will be set letting your code move on from the while loop. This is relatively safe, but it is not good practice to have a while() loop inside an interrupt, so I would rather recommend one of the solutions below.
Set a flag in the BLE event handler and use that flag to trigger an SPI transfer from the main context.
Or use a scheduler and schedule an SPI transfer in the BLE event handler.

RE: SPI from BLE event

endnode — Fri, 17 Nov 2017 13:26:06 GMT

Good question. I personally do all as scheduled actions through scheduler later outside event call-backs (because these are typically done inside some interrupt handler and time to execute APP FW code is limited).

RE: SPI from BLE event

schef — Fri, 17 Nov 2017 13:04:27 GMT

I have put the #define SPI_DEFAULT_CONFIG_IRQ_PRIORITY 3 and now it works. It this safe?