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] [December 2016 Threads]
Hi,
I have a program which uses a one-shot software timer as part of a password-protection scheme. Locked functions can be accessed for a few minutes after a valid password is entered, and using a locked function extends the lockout.
To put it another way:
* Entering the password starts the timer
* Every locked function resets it
* "Logging out" stops the timer
* Locked functions check whether the timer is running before they allow access. If it isn't, a request is made for the password.
This looks good on paper, but I'm having issues with software timers.
If I allow the software timer to time out (wait a few minutes), things work as expected: xTimerIsTimerActive() reports that the timer is running until it times out, then it reports that it has stopped.
If I call xTimerStop against the timer, then xTimerIsTimerActive reports the timer has not stopped.
I was under the impression (from the API documentation) that xTimerStop returned the timer to the Dormant state, and xTimerIsActive returned pdFALSE in this case?
In fact, if I wait a little longer, the timer continues to run until it times out, and the callback function is called.
So it seems as though xTimerStop isn't actually doing anything, at least in FreeRTOS 8.2.3. I've also downloaded 9.0.0 and it seems to be the same.
I've looked at the code, and prvProcessReceivedCommands seems to expect "something else" to remove the timer from the active timers list and/or stop it (as evidenced by the comment "The timer has already been removed from the active list. There is nothing to do here."), but I can't find anything else which removes the timer from the active list.
Thanks,
Phil.
This scenario is tested in the timerdemo.c source file, and is passing.
The timer is removed from the list a few lines above the comment you
refer to:
if( xMessage.xMessageID >= ( BaseType_t ) 0 )
{
/* The messages uses the xTimerParameters member to work on a
software timer. */
pxTimer = xMessage.u.xTimerParameters.pxTimer;
if( listIS_CONTAINED_WITHIN( NULL, &( pxTimer->xTimerListItem ) )
== pdFALSE )
{
/* The timer is in a list, remove it. */
( void ) uxListRemove( &( pxTimer->xTimerListItem ) );
}
Is the priority of the timer service task lower than the priority of the
task that is stopping the timer and then checking to see if the timer is
still running? If so then the task that stops the timer will not have
executed yet - hence the timer will still be running.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.