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.
Hello Philippe, thanks for reporting this issue.
It is always possible to open a Support Ticket when exploring any such problems:
https://www2.keil.com/support/silver?P=&V=&S=
Our Engineering Team confirms that a patch will be available within the next few days.
Hello,
I wanted to create a ticket but the browser infinitely switches between :
https://account.arm.com/armb2c.onmicrosoft.com/B2C_1A_salesforce.susi/samlp/sso/login?and
https://services.arm.com/support/s/login/?
Hence, it was impossible to create a ticket. I've just tried again using the URL provided above, same result.
If needed, I can provided both full URLs.
Thank you - but there is no more a need to create a Support Ticket at this stage, as the Engineering Team already has been aware of that issue.
However, I was just testing the access at: https://www2.keil.com/support/silver?P=&V=&S= and that worked well for me.
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.