Hello Dialog
I am using the "app_easy_timer_modify()", and I had some issues getting the modified timer running after modification.
My issue occurred, when the current timeout collided with the call to app_easy_timer_modify().
I managed to fix the issue by changing the call_callback() function to this:
static void call_callback(const timer_hnd timer_id)
{
if APP_EASY_TIMER_HND_IS_VALID(timer_id)
{
如果(timer_callbacks [APP_EASY_TIMER_HND_TO_IDX(时间r_id)] != NULL)
{
timer_callback fn = timer_callbacks[APP_EASY_TIMER_HND_TO_IDX(timer_id)];
if (fn != timer_modified_handler)
{
timer_callbacks[APP_EASY_TIMER_HND_TO_IDX(timer_id)] = NULL;
modified_timer_callbacks[APP_EASY_TIMER_HND_TO_IDX(timer_id)] = NULL;
}
fn();
}
}
else
{
ASSERT_WARNING(0);
}
}
so now I test if the timeout is on a timer, which is currently being modified, and if yes, I do not delete / NULL to callback functions.
Firstly if they were set to NULL in this case, then the array index would be free for other timers to be created, which would be wrong, because the timer is being modified, and so the index is being reused. So creating a new timer in the same time tick, would cause issues.
Secondly if set to NULL, then the modification process in cancel_timer_handler() namly the line "else if (timer_callbacks[i] == timer_modified_handler)" would not work, and the modified timer would never restart with the new delay.
Could you please confirm my observations, and confirm my corrections?
Are my corrections ok?
or should I do something else to get this working?
Best Regards,
Ciano Frost
Hi ciano,
I assume that you are mentioning a case where the timer is about to elapse but the app_easy_timer_modify() has allready managed to change the callback into the dummy callback and so when the timer actually elapses it would execute the dummy callback instead of the actual callback ? Is that the case that you refer to ? I am not sure if something like this is possible since when the app_easy_timer_modify() runs it will clear the timer before changing the callback, so the dummy callback should never occur. If you are experiencing something like this then its a race condition, the fix looks that it covers a certain time that the issue is probable to occur but again i can't be sure if it will cover all the timing cases. I will issue a ticket on the SDK team for that, but as a request i would like you report if what you are experiencing can be replicated ? and if can be replicated can you please share the code in order to replicate this on our side ?
Thanks MT_dialog
Hello Dialog
Yes, I am able to replicate the timer issue.
and yes I could try to pick the code, which causes the issue to happen, so that you will have a small example, which reproduces the issue. Though I will need some time for that.
Best Regards,
Ciano
Hi Dialog,
Do you have any "none-public" place, where I can upload the code, which reproduces this issue?
Best Regards,
Ciano Frost
Hi ciano,
Please use this link in order to upload the filehttps://diasemi.egnyte.com/ul/def6jR26jd.
Thanks MT_dialog
Hi Dialog
Code which replicate the issue has been sent.
Best Regards,
Ciano Frost
Hello Dialog,
Have you been looking, at the code, which we sent you?
Best Regards,
Ciano Frost
Hi ciano,
I ve send the code that replicates the issue at the SDK team in order to check this out and fix any issue exists on the SDK, regarding your code i dont see any issue that could be caused by the mod that you placed in the call_callback. You will just execute the dummy callback with the old timer and a new timer with the modified value will be created and expire as it should using the previous callback. I suppose that you will be ok with that.
Thanks MT_dialog