case tmrCOMMAND_CHANGE_PERIOD :
case tmrCOMMAND_CHANGE_PERIOD_FROM_ISR :
pxTimer->xTimerPeriodInTicks = xMessage.u.xTimerParameters.xMessageValue;
configASSERT( ( pxTimer->xTimerPeriodInTicks > 0 ) );
/* The new period does not really have a reference, and can
be longer or shorter than the old one. The command time is
therefore set to the current time, and as the period cannot
be zero the next expiry time can only be in the future,
meaning (unlike for the xTimerStart() case above) there is
no fail case that needs to be handled here. */
( void ) prvInsertTimerInActiveList( pxTimer, ( xTimeNow + pxTimer->xTimerPeriodInTicks ), xTimeNow, xTimeNow );
break;
Hit an assert in timer.c file (configASSERT( ( pxTimer->xTimerPeriodInTicks > 0 ) ))
Build information:
Visual C++ 2012, version 11.0.5, so the Visual C++ toolchain
FreeRTOS version is V9.0.0 (comes from here, download link at file menu)
I don’t know exactly what is the meaning of this assert.
Something I get on it and I don’t know why.
I use a timer callback function as I configure xTimerCreate().
Within this callback, I send information on a queue or I use a task notification to another task.
I’ve noticed that the problem seem to be related to the period value of the end user task (infinite wait, no wait at all or in between).
timer.c file:
Hit an assert in timer.c file (configASSERT( ( pxTimer->xTimerPeriodInTicks > 0 ) ))
This is telling you that there was an attempt to set the timeout of a software timer to 0, which is not a valid value.