FreeRTOS Support Archive

The FreeRTOS support forum can be used for active support both from Amazon Web Services
and the community. In return for using our software for
free, we request you play fair and do your bit to help others! Sign up
to receive notifications of new support topics then help where you can.

This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.

xTimerCreate

Have a situation where xTimerCreate() with period 1 results in timer callback at twice the rate. Bump the period to 2 and I get the correct rate. I am wondering if setting the period to a single tick is legal?

xTimerCreate

It very consistently gives me twice the number of timer callbacks as it should for this condition only? So that would indicate either a bug or that it is not really a valid use if you want an accurate count?

xTimerCreate

xTimerCreate

Hmmm, my "pared down version" seems to be working correctly with (1/portTICKRATEMS) for the period? Maybe you should wait on your trial. I thought I removed all unrelated code. Perhaps not... I will repost one way or another...

xTimerCreate

OK, the problem turned out to be two instances of the timer causing double the number of callbacks. I had protected the timer creation with a mutex to prevent this, but apparently the timer callbacks run in the same task space as the task that creates the timer (If you can confirm this is the case would appreciate it). Since that task already owned the mutex it blew right by the protection. When the timer period was increased the callback was delayed and avoided the problem just by timing. I know this sounds convoluted, and I changed the implementation to avoid the issue altogether, but I am still interested in the task question above.

xTimerCreate

Thanks for taking the time to report back - although note that timer
callback functions execute in the context of the timer service task, not
the context of the task that created the timer (unless of course the
timer was created by the timer service task).

xTimerCreate

If that is the case I am at a loss as to how this happened. I will outline the order of operations and give you a bit of background...
- The class is singleton. The GetInstance() member function creates the instance and sets up the timer.
- The timer callback was a function independent of the class that used GetInstance()->Update() to inform the singleton class when the timer fired.
- The GetInstance() function incorporated a mutex to ensure that the timer setup would be called only once.
So what was happening was that GetInstance() called TimerSetup(). TimerSetup() created the timer with TimerCallback(). TimerCallback() fired immediately and called GetInstance()->Update() before the call to TimerSetup() returned. This second call to GetInstance() was ALSO calling TimerSetup() resulting in a second timer instance calling the same TimerCallback() (this is why I was receiving double the number of updates).
The mutex should have prevented that last call to GetInstance() from acquiring the mutex if as you say the callback is not running in the same context, thus avoiding a second call to TimerSetup()???? So the mutex must have failed in this scenario.
My solution (and a better implementation) was to convert the Update member to static and pass it to timer creation as the callback function. This bypasses the need to call GetInstance() for the second time from an external TimerCallback() function.

xTimerCreate

This should produce the problem. "Lost" my hardware temporarily, so could not test. But the attached code produced the problem before I changed the design; I just removed all extraneous code. I did compile it... hopefully this will make sense along with the previous description...