Agree that FreeRTOS code should handle this special case better. Does your application fall into this case? Do you think this is the issue you’re experiencing when you use xTaskCatchUpTicks()?
Actually, I would say that one should not try to delete a resource that might still have another reference to it. So you shouldn’t delete a reloading timer if it is still active.
The thing that might be able to be solved is getting the STOP to work better and not let the timer restart the way it is.
The only way I could see for the delete to work in this sort of case would be if delete just marked timers for deletion, and only actually does it on an empty queue. But that would require keeping some form of list of timers marked for deletion.
I will increase timer prio and disable auto-timer deleting code make retest of issue and let you know about result
Seems like a reasonable resolution would be to update the API documentation to prohibit calls to xTimerDelete() for active auto-reload timers.
However, when I reviewed the code yesterday, I noticed that fixing the stop issue would come with a free fix for the delete issue. So maybe that’s the best way to proceed.
Thanks Jeff I will apply it to my project and let you know about results. But sending to front seems to be a good idea
Hi Lukasz, thanks for the comment on github. Did the github code (sending to front) fix this issue for you? Curious if you really were experiencing this odd case of deleting a backlogged auto-reload timer.
Hi Jeff, The issue seems to be fixed. We run test for 24h and no issue. Normally we have seen it after 8h to 16h of testing. Thank you for support
1 Like
Lukasz, the send-to-front fix led to a different, more direct fix you might want to adopt instead: PR 305.
Jeff, As I see your changes were merged to master. Do you know when new official freeRtos release is planned?
No, sorry I don’t. (Ignore these extra characters.)
The intent is for the next release to be within three weeks.