Multiple timers and scheduler

[Arepa]

Hello Devs,

I am using app_timer to create multiple timers to read different sensors

Currently, I have 5 timers created using app_timer_create, each timer has their own callback, inside each callback I call app_sched_event_put() to run the specific function for each sensor in the main context, in theory, it should be working fine, but some times after initialize my code it gets stucks, I noticed it happens when two or more timers have the same interval (e.g trigger every 3 seconds)

I have more callbacks as the code below fo each sensor, actually, they have the same code the only difference is the value for "type"r:

void timerCallbackForTemperature(void *p_context) 
{ 

uint8_t type = 1; //temperature 
app_sched_event_put(&type, sizeof(type), Event); 

}

The app_sched_event_put always returns nrf_success / 0, but some times it does not fire the callback for the scheduler callback and it is when my code hangs.

I believe two timers callback are happening at the same time and it hangs my code, or idk if it is something pure related to the scheduler

note:

SDK13 and nRF52

issue related: https://devzone.nordicsemi.com/f/nordic-q-a/11412/calling-app_sched_event_put-inside-interrupt

[Einar Thorsrud]

Hi,

Are all you calls to app_sched_event_put() done from app_timer timeout handlers? If so all calls are called with the same interrupt priority, so there will not be any interrupts that could cause problems in case there was a race condition there. You could think it might be an issue if poping the queue (calling app_sched_execute() and that is interrupted by app_sched_event_put(), but I do not see anything suspicious in the implementation of these. So, as far as I can see, as long as app_sched_event_put() returns NRF_SUCCESS, the event should be processed eventually when you call app_sched_execute().

How have you concluded that the problem is within the scheduler? Could the cause be that your main loop does not call app_sched_execute() enough times? For instance, if you call app_sched_execute() once and then go to the system on sleep waiting for an event, you will no process the queue often enough if the two simultaneous app timer events are processed in the same interrupt instance (meaning that the main loop does not run in between).

[Arepa]

Hi Einar,

Yes, my calls to app_sched_event_put() are done from an app_timer timeout handler. at first, I was thinking it was about the frequents timers callbacks could stop or cancel an app_sched_event_put() (which always returns NRF_SUCCESS)

I am not 100% sure the issue is a scheduler related, but this suspicious to me that the program hangs after an NRF_SUCCESS at app_sched_event_put() and it is not firing the scheduler event, it does not happens every time, but I noticed this behavior when turning on my nRF52 DK.

I believe in average I have 1 or 2 calls to app_sched_execute() per second, it gives could give enough time/cycles to call app_sched_excute() in the main loop function which is basicly app_sched_execute() and the power_manage()

[Einar Thorsrud]

I see. I don't have any other explanation, though. Could you test my theory by for instance calling app_sched_execute() twice in your main loop?

If that does not work it would be interesting to test on my side if you can upload a project demonstrating this issue that runs on a DK.