# timer issue **URL:** \ **Category:** Kernel\ **Created:** [May 19, 2015, 11:37pm UTC](https://forums.freertos.org/t/timer-issue/2951 "2015-05-19T23:37:13Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [May 19, 2015, 11:37pm UTC](https://forums.freertos.org/t/timer-issue/2951/1 "2015-05-19T23:37:13Z")
**[williamjsell](https://sourceforge.net/u/williamjsell/)** wrote on [Tuesday, May 19, 2015](https://sourceforge.net/p/freertos/discussion/382005/thread/8513b95f/#47fa): Target: LCP177x\_8x RTOS version: 8.0.0 IDE: Rowley Crossworks for ARM We have a debounce algorithm for a membrane switch, which relies on the setting and resetting of a timer in RTOS, based on button edge interrupts. This works great for a while, then the system appears to hang up after many repeated button presses. I traced the reason to this line in timers.c: static void prvProcessReceivedCommands( void ) { DaemonTaskMessage\_t xMessage; Timer\_t \*pxTimer; BaseType\_t xTimerListsWereSwitched, xResult; TickType\_t xTimeNow; ``` while( xQueueReceive( xTimerQueue, &xMessage, tmrNO_DELAY ) != pdFAIL ) ``` where suddenly I get a return status from the xTimerStopFromISR or xTimerStartFromISR indicating that the queue is full. I put a printf debug after the xQueueReceive and recreated the problem, and indeed this no longer was processing the messages from the timers. So the queue fills, the kernel seems quite happy, but we cannot navigate from the current screen as the buttons are frozen…any ideas what is stopping this from working? ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [May 20, 2015, 10:26am UTC](https://forums.freertos.org/t/timer-issue/2951/2 "2015-05-20T10:26:33Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Wednesday, May 20, 2015](https://sourceforge.net/p/freertos/discussion/382005/thread/8513b95f/#df83): So if I understand correctly, the code you show is the loop which drains the timer command queue, the queue is full, but the timer task is no longer draining the queue. If the timer task is not in the correct state then it could be an interrupt priority issue. Do you have configASSERT() defined? In later versions of FreeRTOS (not sure about V8.0.0) that will automatically catch interrupt priority mis-configurations. I would recommend updating your FreeRTOS version anyway as V8 had an issue with the event groups “set bits from ISR” function [http://www.freertos.org/History.txt](http://www.freertos.org/History.txt). Regards. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [May 20, 2015, 3:58pm UTC](https://forums.freertos.org/t/timer-issue/2951/3 "2015-05-20T15:58:47Z")
**[williamjsell](https://sourceforge.net/u/williamjsell/)** wrote on [Wednesday, May 20, 2015](https://sourceforge.net/p/freertos/discussion/382005/thread/8513b95f/#7f0f): Yes, the problem is as you describe. Let me upgrade to the latest RTOS version first and see if this helps. How do you turn on the assertions (#define configASSERT in the FreeRTOSConfig.h file)? ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [May 20, 2015, 4:06pm UTC](https://forums.freertos.org/t/timer-issue/2951/4 "2015-05-20T16:06:36Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Wednesday, May 20, 2015](https://sourceforge.net/p/freertos/discussion/382005/thread/8513b95f/#7f0f/eee9): Yes - define it in FreeRTOSConfig.h, normal assert semantics. In its most basic form you can: ``` #define configASSERT( ( x ) ) if( ( x ) == 0 ){ portDISABLE_INTERRUPTS(); for(;;); } ``` to just bring the system to a stop on the offending line. [http://www.freertos.org/a00110.html#configASSERT](http://www.freertos.org/a00110.html#configASSERT) Regards. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [May 20, 2015, 5:16pm UTC](https://forums.freertos.org/t/timer-issue/2951/5 "2015-05-20T17:16:30Z")
**[williamjsell](https://sourceforge.net/u/williamjsell/)** wrote on [Wednesday, May 20, 2015](https://sourceforge.net/p/freertos/discussion/382005/thread/8513b95f/#4f55): OK, making some progress, the assert was very helpful. What I am seeing when the button is pressed is a trap in vPortValidateInterruptPriority(); the assert fails here: configASSERT( ucCurrentPriority \>= ucMaxSysCallPriority ); my confusion is the button is set to 0 priority, but the ucMaxSysCallPriority is set to 40. I thought (based on the doco at [http://www.freertos.org/RTOS-Cortex-M3-M4.html](http://www.freertos.org/RTOS-Cortex-M3-M4.html) and the LPC1788 UM, the max priority levels for an interrupt is 32. Still trying to understand how this all works… ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [May 20, 2015, 10:05pm UTC](https://forums.freertos.org/t/timer-issue/2951/6 "2015-05-20T22:05:02Z")
**[williamjsell](https://sourceforge.net/u/williamjsell/)** wrote on [Wednesday, May 20, 2015](https://sourceforge.net/p/freertos/discussion/382005/thread/8513b95f/#f012): ok, problem solved and embarrassingly I had set all other system interrupt priorities correctly, but forgot the GPIO irq. Just required this line: NVIC\_SetPriority(GPIO\_IRQn, configGPIO\_INTERRUPT\_PRIORITY); where the configGPIO\_INTERRUPT\_PRIORITY is greater than the configMAX\_SYSCALL\_INTERRUPT\_PRIORITY value…