APP Timer and While loop in BLE

RE: APP Timer and While loop in BLE

Einar Thorsrud — Wed, 21 Sep 2016 11:16:32 GMT

The app_timer uses RTC1 for all your timers, and always uses APP_LOW priority level. You should not configure RTC1 separately when using the app_timer. Also note that the SoftDevice uses RTC0, so you cannot use that from your application. My gut feeling is that you should clean-up your application, make sure not do unnecessary blocking stuff etc, rather than trying to fix too much with priorities. Do as little as possible in interrupt routines, only what must be done fast, and do the rest in main context. Use timers for waiting, not loops checking a timer value etc...

RE: APP Timer and While loop in BLE

Siva — Wed, 21 Sep 2016 11:04:41 GMT

Hi Einar, Thanks for your advise. I am also thinking to use another "App timer" with low priority such that I will use it to call "Peace_Mask-Active()" event once every few seconds(It doesn't has to be very accurate).

I didn't find a correct syntax to change priorities for App timer can you advice on this please. Also want to know which RTCs has been used while using multiple app timer functions.

RE: APP Timer and While loop in BLE

Einar Thorsrud — Wed, 21 Sep 2016 06:22:06 GMT

Do you really need to do so much in an interrupt context? And do you really need those loops waiting for a long time? It tends to give you a complex application where it is difficult to handle what is waiting for what (as you are seeing). Moreover, the CPU will be running for much of the time, causing an unnecessarily high current consumption.

There are other issues with your code as well. In your Peace_Mask_Active(), where you have for example this loop:

		while(true)
		{
			if(Current_Time_Sec > (Measured_Treatment_Time+20))
			{
				break;
			}
		}

you are waiting for Current_Time_Sec to change, which is updated in another event handler (in interrupt context). Even if you make sure that the Current_Time_Sec is updated in an event handler with higher priority (which is a must), it still won't help you unless you disable optimization, as the variable is not volatile and the compiler cannot easily know that it can change. Therefore, with normal optimization, the above loop would be optimized to something like this:

		while(true)
		{
		}

...which will continue to do nothing forever. (As long as you are just incrementing and waiting for it to become larger than a limit, making the variable volatile should be sufficient in this case. In other cases you would have to do more in order to make the operation atomic, using for example the CRITICAL_REGION_ENTER() and CRITICAL_REGION_EXIT() macros supplied with the SDK.)

RE: APP Timer and While loop in BLE

Siva — Tue, 20 Sep 2016 12:06:03 GMT

I have tried changing "APP_IRQ_PRIORITY_LOW" to "APP_IRQ_PRIORITY_HIGH" on RTC1 in nrf_drv_config.h file but it didn't work as it still got stuck in while loop.

RE: APP Timer and While loop in BLE

Siva — Tue, 20 Sep 2016 10:07:22 GMT

I found how to set IRQ priorities for Protocols now.

RE: APP Timer and While loop in BLE

Siva — Tue, 20 Sep 2016 09:35:02 GMT

Can you advice on how to change interrupt priorities for timer,ble, gpio, protocols(I2C,SPI,Uart,etc).

I have attached my code. At line 1067 where our problem actually starts.

We use "rtc_config()" to read touch value, I have noticed that it doesn't read data when it enters into the loop for the first time I have to call this function again by button press in order to read the data. It is recursive(I have to call the event twice to read the touch data). Any Advice?
In lines 1078,1091 where I started using while loop to check time.

You are correct if I can set the priorities right this should work. In our application ble,timer needs to be highest priority followed by I2C and then while/main loops.

RE: APP Timer and While loop in BLE

Einar Thorsrud — Tue, 20 Sep 2016 05:50:36 GMT

In what interrupt priority do you check the timer value in a loop? If it is running in the same or higher priority than the application timer, your timeout event handler will never be called as it must wait for the other (same or higher priority) interrupt handler / event handler to finish first.