Migration to SD functions

RE: Migration to SD functions

Ck — Thu, 04 Sep 2014 06:35:34 GMT

OK I was not sure about behaviour when IRQ will occure in this time sequence: while(flag_ms == 0) , IRQ Handler process , sd_app_evt_wait(). Meaning when IRQ occurs after flag was checked and before sd_app_evt_wait() is called again, not when it was already called.

RE: Migration to SD functions

Nikita — Wed, 03 Sep 2014 15:32:09 GMT

You don't need __SEV() with sd_app_evt_wait(), read its description:

If an application interrupt has happened since the last time sd_app_evt_wait was called this function will return immediately and not go to sleep. This is to avoid race conditions that can occur when a flag is updated in the interrupt handler and processed in the main loop.

BTW sd_app_evt_wait() automatically go to sleep mode until event will occure?

Yes.

RE: Migration to SD functions

Ck — Wed, 03 Sep 2014 14:20:49 GMT

Sample code for that:

void RTC1_IRQHandler(void)	/*lint !e765 !e714 */
{  
	/* Every 1ms */
	if (NRF_RTC1->EVENTS_COMPARE[0] != 0)
  {
		NRF_RTC1->EVENTS_COMPARE[0] = 0;
		NRF_RTC1->TASKS_CLEAR = 1;  // Clear Counter		    
				    
    flag_ms = 1;
    /* to avoid race condition */
		__SEV(); /*lint !e718 !e746 */  // it's in assembler
  }
}


volatile u8 flag_ms=0;

for(;;){
  while(flag_ms == 0) V_hw_WFE(); 
  flag_ms=0;
}



void V_hw_WFE(void)
{
	#ifdef NO_SD
		__WFE();
	#else     
		(void)sd_app_evt_wait();	
	#endif
}

BTW sd_app_evt_wait() automatically go to sleep mode until event will occure?

RE: Migration to SD functions

Nikita — Wed, 03 Sep 2014 13:59:26 GMT

Don't quite understood the problem, can you give an example?

RE: Migration to SD functions

Ck — Wed, 03 Sep 2014 13:40:30 GMT

Great. Now I'm not sure only with __SEV(); Can I use this instruction withih SD enabled? I'm using this in IRQ handler after event_flag is set to avoid race condition.

RE: Migration to SD functions

Nikita — Wed, 03 Sep 2014 13:26:46 GMT

Yes, for example, you want to send some data through UART and you send first byte by writing

NRF_UART0->TXD = data[0];

and then go to low-power mode with sd_app_evt_wait() then you will return from sd_app_evt_wait() when UART will send data and generate TXDRDY event so you can handle it like this:

// Enter main loop.
for (;;)
{
    if (NRF_UART0->EVENTS_TXDRDY == 1)
    {
        NRF_UART0->EVENTS_TXDRDY = 0;
        NRF_UART0->TXD = data[next_byte]; 
        ...
    }
    sd_app_evt_wait();
}

RE: Migration to SD functions

Ck — Wed, 03 Sep 2014 13:05:21 GMT

I search for enum NRF_SOC_EVTS and that means that by sd_app_evt_wait() system go sleep and wake up at ANY generated event or interrupt, but sd_evt_get(p_evt_id) can get only those events in enum NRF_SOC_EVTS, right? So for non SD events I still can use own flags set in appropriate IRQ handler to know that particular event has occured.

RE: Migration to SD functions

Ck — Wed, 03 Sep 2014 11:16:27 GMT

Great, that document explains that very clear.

RE: Migration to SD functions

Nikita — Wed, 03 Sep 2014 08:09:54 GMT

The comment is only about SD_EVT_IRQn.

You can read about it in nRF51 SDK_v6.0.0.43681\Nordic\Documentation\Introduction_to_the_S110_SoftDevice_v1.0.pdf "3 Handling events"

RE: Migration to SD functions

Ck — Wed, 03 Sep 2014 07:40:20 GMT

Thanks for reply.
Now I'm confused with another thing. From SD examples i see this SD setup:

uint32_t err_code = sd_softdevice_enable(NRF_CLOCK_LFCLKSRC_XTAL_50_PPM, 
                                             softdevice_assert_callback);
    APP_ERROR_CHECK(err_code);

    // Configure application-specific interrupts. Set application IRQ to lowest priority and enable 
    // application IRQ (triggered from ANT protocol stack).
    err_code = sd_nvic_SetPriority(SD_EVT_IRQn, NRF_APP_PRIORITY_LOW); 
    APP_ERROR_CHECK(err_code);
    err_code = sd_nvic_EnableIRQ(SD_EVT_IRQn);      
    APP_ERROR_CHECK(err_code);

What is SD_EVT_IRQn?
It's not regular peripheral IRQ, I suppose it's some kind of callback used by SD stack? But from comment it seems like it should set priority of my IRQ in app globally to lowest priority, so I don't need to set individually priority by sd_nvic_SetPriority() ?

RE: Migration to SD functions

RK — Tue, 02 Sep 2014 23:07:56 GMT

If you are absolutely using only the interrupts, resources and priority levels (important) that you are allowed to use then in reality you can get away with using the NVIC_* calls, it ends up being the same thing. The sd_ calls just check the parameters and hardfault you if you, even accidentally, do something incorrect.

I have mine #defined so I can switch between the two of them after going through dev testing if I want, it's a bit quicker calling the NVIC ones directly as you don't have to go through a SVC call. By the time I get to that point I'm pretty sure I'm doing the right thing.

RE: Migration to SD functions

Nikita — Tue, 02 Sep 2014 18:48:58 GMT

but I'm using IRQ handlers for non restrictred or blocked peripherals (I hope at least this is OK)

Yes, it's ok, you only need to use sd_nvic_* instead of NVIC_*.

BTW sd_app_evt_wait() is waiting for event or irq, what about if I want strictly wait for irq as it is done by __WFI()?

There is no way to do it, softdevice has only this one function for both irq and events together. Softdevice handles both irq and events and after softdevice handles them first then softdevice will send software interrupt to the application.

RE: Migration to SD functions

Ck — Tue, 02 Sep 2014 18:03:40 GMT

I'm not using any peripheral used by SD, but I'm using IRQ handlers for non restrictred or blocked peripherals (I hope at least this is OK), various power modes and HF clock start/stop (so here I have to use alternate SD funcs). BTW sd_app_evt_wait() is waiting for event or irq, what about if I want strictly wait for irq as it is done by __WFI()?

RE: Migration to SD functions

Nikita — Tue, 02 Sep 2014 16:17:57 GMT

You can see in S110_SoftDevice_Specification_v1 3.pdf there is a list of peripherals used by softdevice in "Table 23 Peripheral protection and usage by SoftDevice".

Any direct access to the protected resources while softdevice is enabled will generate hard fault by softdevice, so you must use softdevice calls to access to this resources.