A bug appears when trying to restart a periodic timer already running using osTimerStart, with a different period :
The new period is taken in account for one period and period go back to the previous value set by the first osTimerStart call. This is due to 'load' member of timer not re-initialized when timer is detected already running.
Here is the patch for this bug :
static osStatus_t svcRtxTimerStart (osTimerId_t timer_id, uint32_t ticks) { os_timer_t *timer = osRtxTimerId(timer_id);
// Check parameters if ((timer == NULL) || (timer->id != osRtxIdTimer) || (ticks == 0U)) { EvrRtxTimerError(timer, (int32_t)osErrorParameter); //lint -e{904} "Return statement before end of function" [MISRA Note 1] return osErrorParameter; }
if (timer->state == osRtxTimerRunning) { TimerRemove(timer);// 09/03/22 Bug fixed timer->load = ticks; } else { if (osRtxInfo.timer.tick == NULL) {
...
Remark : if RTX source code is not integrated in the project, a call to osTimerStop must be done before calling osTimerStart with a new period value.
Confirmed by Keil Engineering the problem should be fixed now with the latest patch on the GitHub develop branch.
Note: As a work-around solution, to get the new timer period correctly applied, first stop the timer with osTimerStop before calling osTimerStart with the new period.
Thank you, this is what I did before to directly modify osTimerStart code. This turnaround works fine for people who don't integrate the RTX source code to their projects.