osTimer callback parameter value is not argument passed at timer creation

[gavinb]

The documentation for the CMISIS osTimerCreate function is described thus:

Create a one-shot or periodic timer and associate it with a callback function argument.

It describes the argument parameter thus:

*argument* | argument to the timer call back function.

However in the CMSIS-FreeRTOS implementation for prvProcessExpiredTimer, the pxCallbackFunction is invoked by passing the timer handle pxTimer itself, instead of the argument (which is also known as the timerID):

https://github.com/ARM-software/CMSIS-FreeRTOS/blob/4694df7458df0574dee4aeb0fb8e1f021bd48d9e/Source/timers.c#L534

There is no portable way in CMSIS to access the argument given the timer handle. There is a pvTimerGetTimerID() function in FreeRTOS which serves this purpose (though having the caller invoke this would break the encapsulation).

It seems the fix would be for prvProcessExpiredTimer to use pvTimerGetTimerID() to retrieve the timerID/argument and pass this to the callback.

[VladimirUmek]

If you take a look at the implementation of function osTimerNew: https://github.com/ARM-software/CMSIS-FreeRTOS/blob/4694df7458df0574dee4aeb0fb8e1f021bd48d9e/CMSIS/RTOS2/FreeRTOS/Source/cmsis_os2.c#L834 you will see that a workaround is implemented almost exactly as suggested.

Since timer callback in FreeRTOS takes only one argument, the workaround was implemented to store user callback function and user argument into the intermediate buffer. Unfortunately heap has to be used to do this automatically: https://github.com/ARM-software/CMSIS-FreeRTOS/blob/4694df7458df0574dee4aeb0fb8e1f021bd48d9e/CMSIS/RTOS2/FreeRTOS/Source/cmsis_os2.c#L845

When timer expires, static timer callback function is called which resolves user specified callback and argument, see TimerCallback: https://github.com/ARM-software/CMSIS-FreeRTOS/blob/4694df7458df0574dee4aeb0fb8e1f021bd48d9e/CMSIS/RTOS2/FreeRTOS/Source/cmsis_os2.c#L824

[gavinb]

I see - that's great that the v2 implementation has the correct behaviour, as you describe.

I now realise that the version I'm using is the older v1, which is what STMicro ship in the current version of their CubeMX SDK. The version in the SDK we have is labelled 1.02, cmsis_os.c, though it is described as the API for FreeRTOS v9. I guess I should ask ST when they plan to upgrade the CMSIS wrapper to v2. Thanks, I'll pursue this with them.

[JulienDevillers]

Hello Gavin,

Did you get some answer from ST ?

Julien

[gavinb]

Hi Julien, unfortunately no response from ST. I asked for an update on the community site.

https://community.st.com/s/question/0D50X00009fGVXsSAO/when-will-cmsisfreertos-be-upgraded-to-v2

I checked the latest firmware package (v1.7.0 for the F1 series) and it appears unchanged. They don't seem in any hurry to upgrade. I'll let you know here if we get an update. Thanks!

[JulienDevillers]

Hi GavinThanks for your answer.I get an interesting answer that did the trick on stackoverflow :https://stackoverflow.com/a/54714374/4933822JulienLe 25 févr. 2019 02:13, Gavin Baker notifications@github.com a écrit :Hi Julien, unfortunately no response from ST. I asked for an update on the community site. https://community.st.com/s/question/0D50X00009fGVXsSAO/when-will-cmsisfreertos-be-upgraded-to-v2 I checked the latest firmware package (v1.7.0 for the F1 series) and it appears unchanged. They don't seem in any hurry to upgrade. I'll let you know here if we get an update. Thanks!

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.