How to implement a simple non-blocking delay on nRF51822 with SoftDevice

RE: How to implement a simple non-blocking delay on nRF51822 with SoftDevice

diode — Fri, 25 Sep 2015 16:24:01 GMT

@Anders That makes sense. Thanks for your explanation!

RE: How to implement a simple non-blocking delay on nRF51822 with SoftDevice

Anders Strand — Fri, 25 Sep 2015 07:42:22 GMT

If the LED being set indicates success, i believe your code behaves exactly how it should be :) If you call app_sched_execute() before power_manage(), this happens: power_manage()->Timer event->app_sched_execute->lazy_wait_handler->power_manage(). It never escaped the while loop, it will sleep forever inside power manage. If you call it after: power_manage()->Timer event->app_sched_execute->lazy_wait_handler->While loop checking flag ->escape while loop. See the scheduler docs for some more info.

RE: How to implement a simple non-blocking delay on nRF51822 with SoftDevice

diode — Thu, 24 Sep 2015 16:38:07 GMT

@Anders Thanks for your suggestions. Changing the app scheduling to "false" works. For the second option, it only works when I call app_sched_execute() after power_manage() in the while loop containing "lazy_wait_flag". It doesn't work if app_sched_execute() is called before power_manage(). Why is that? Also, what are the pros and cons of disabling scheduling of app timers? I have some app timers and also app buttons which use app timers elsewhere in the code. I just wonder how they will affect the deterministicity of the delay.

RE: How to implement a simple non-blocking delay on nRF51822 with SoftDevice

Anders Strand — Thu, 24 Sep 2015 14:20:16 GMT

Hello. Your last parameter in APP_TIMER_APPSH_INIT is "True", which means that you intend to use the scheduler. However, the scheduler is not run in your while loop. Try setting the last parameter to "False", or run app_sched_execute() in the while loop.

Edit: About using the app_scheduler:

The main reason to use this module, is to execute some procedure from main context (low priority) instead of the interrupt context (higher priority). If your procedure is short and have real time timing requirements, you should execute it directly in the interrupt handler and not use the scheduler. If your procedure takes some time, and timing is not critical, the scheduler is a good way to ensure that you procedure does not interfere with more important tasks.

The documentation of the app_scheduler can be found here.

RE: How to implement a simple non-blocking delay on nRF51822 with SoftDevice

diode — Thu, 24 Sep 2015 01:59:31 GMT

If you mean something like "SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_RC_250_PPM_TEMP_4000MS_CALIBRATION, false);", I did it when initialization BLE stack. I also had other app timers in this code (which I didn't show above), and they were all working okay. I set a breakpoint in lazy_wait_handler(), and it was not reached. So I assumed for some reason ISR was not called and the lazy_wait_flag was not cleared properly.

RE: How to implement a simple non-blocking delay on nRF51822 with SoftDevice

RK — Thu, 24 Sep 2015 01:16:27 GMT

Do you start an LF clock source somewhere in the elided code? Have you put a breakpoint into the timer routine to check and see if it's being called or not to determine whether your timer code is wrong or your waiting code is wrong?