RE: Using I2C, NUS, and Two Timer Interrupts - Reading Sensor from both Timer Interrupts

Stefan Birnir Sverrisson — Wed, 18 Mar 2015 11:49:10 GMT

Hi Mango922

When you use the softdevice together with a timer, you must explicitly set the priority of the TIMER interrupts, i.e.

 NRF_TIMER1->INTENSET = TIMER_INTENSET_COMPARE0_Enabled << TIMER_INTENSET_COMPARE0_Pos;   
 sd_nvic_SetPriority(TIMER1_IRQn, NRF_APP_PRIORITY_LOW);  
 sd_nvic_EnableIRQ(TIMER1_IRQn);

 NRF_TIMER2->INTENSET = TIMER_INTENSET_COMPARE0_Enabled << TIMER_INTENSET_COMPARE0_Pos;   
 sd_nvic_SetPriority(TIMER2_IRQn, NRF_APP_PRIORITY_LOW);  
 sd_nvic_EnableIRQ(TIMER2_IRQn);

If you want to synchronize the order of events for the two timers, I guess it would be better to use two compare registers of the same timer.

If you choose both timers with same priority, then they will not preempt each other, meaning that once one of them starts execution, the other one can not interrupt that execution, it will have to wait for the other one to complete. If however TIMER1 has higher priority than TIMER2, then TIMER1 interrupt can preempt exectuion of TIMER2 interrupt handler.

Defining NRF_APP_PRIORITY_LOW means ARM priority 3, see this thread
NRF_APP_PRIORITY_HIGH means ARM priority 1
Softdevice callbacks have ARM priority 3.
SVC calls (calling the softdevice with sd_*) have ARM priority 2
Internal softdevice operations have ARM priority 0.

From the above, e.g. the following can be concluded:

Any internal softdevice operation (BLE operation) will preempt any application operation.
Any peripheral interrupt with NRF_APP_PRIORITY_LOW or NRF_APP_PRIORITY_HIGH will block softdevice callbacks.
Any peripheral with priority set to NRF_APP_PRIORITY_HIGH will preempt any execution of peripheral with priority NRF_APP_PRIORITY_LOW
Interrupt handler of peripheral with priority NRF_APP_PRIORITY_LOW can call a SVC softdevice function (starting with sd_*), but interrupt handler of peripheral with priority NRF_APP_PRIORITY_HIGH can not.