FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! 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.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [February 2017 Threads]
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:
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;
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.