GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Friends, I am working on STM32F4 and using FreeRTOS. When I enable the EXTI1 interrupt and there are interrupts coming on this pin, I see that the FreeRTOS timers start expiring sooner than the scheduled time. When there are no interrupts coming every timer is on time. It is when interrupts come that is when I see freeRTOS going into this state. I have already confirmed that I have: configASSERT is define, NVICPriorityGroupConfig( NVICPriorityGroup_4 ); is defined and everything said here: https://www.freertos.org/RTOS-Cortex-M3-M4.html is taken care of. What could it be?

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

When you say timers, do you mean software timers (as in FreeRTOS’s software timer feature), or do you mean just block times are expiring too soon in general. It is hard to see what correlation there could be. I think if all software timers are expiring early, or all block times are expiring early, then it must be that the tick interrupt is executing more often than it should – or at least the increment tick function is executing more often than it should. That could be because the clock driving the hardware sped up, or for some other software reason.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Thank you for responding. Yes all software timers expires sooner. I was guessing the same i.e., the tick timer is expiring too soon when interrupts kick in. What are “block times”? Timers are defined as anybody would:
TimerHandlet pulsecountertimer = xTimerCreate((const char *) “pulsecountertimer”, 5000, pdTRUE, (void*) 0, pulseharvesttimercallback); if (pulsecountertimer != NULL) { xTimerStart(pulsecountertimer, 0); // Start the Timer } else { printf(“Could not start Pulse Counter Timern”); return; }

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

By block time I mean any timeout specified in a call such as vTaskDelay() or xQueueReceive(). Do block times also expire too soon? For example, if you call vTaskDelay( pdMSTOTICKS( 500 ) ) does it expire every 500ms, or are only software timers effected. Software timers are stored with a pre-calculated expire time – there is no single place in a data structure that could get corrupted that would cause them all to expire too soon – unless the tick count value itself was somehow corrupt or incrementing too quickly. How are you ascertaining that the timers are expiring too early? Are you 100% sure that is the symptom you are observing? Have you otherwise validated that the tick interrupt is executing at the frequency you expect both before and after this issue occurs?

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

I am 100% sure that the timers are expiring. I tested it via: a) Printing the timestamp in task that is woken up by the Timer (by releasing the semaphore). b) Using a stop clock (Visual observation). c) Toggling a GPIO low and high very time the timer expires and observing the GPIO Toggle on the oscilloscope. The time delta betweent he GPIO pulses gives very accurate representation of what is happening. Once the interrupts stop, timers go back to normal. I have not observed vTaskDelay though. That is what I will do next and post here.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Yes, it impacts vTaskDelay(..) as well.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Well without knowing more or being able to experiment myself it sounds like something is messing with the timing that the tick is occurring – did you try toggling an LED or something from the tick hook so you can see the frequency it is executing at?

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Thanks a lot for taking time to respond. I will try that and post the results as I debug it.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

This is what I have discovered until now. Task A during it’s execution creates another task B and when Task A is done with what was needed from Task B, it deletes the task B. To delete the task it updates a global variable (lets call it terminatenow). Task B is looping on terminatenow and as soon as Task A sets the variable terminate_now to 1, Task B calls vTaskDelete(NULL); to kill itself. **As soon that happens, the timers start going haywire. ** If Task A kills Task B by directly calling vTaskDelete(Handletotask_B), everything is fine! Why?

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Trying to replicate now.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

I’ve not been able to replicate this using the code below, so would be grateful if you can send me your example so I can see exactly what your code is doing in the hope that I can set up a similar case ehre. Please take out everything that is not necessary to show the issue – hopefully you can strip it back ot just the Task A and Task B mentioned in your previous post. Also please let me know the compiler, compiler version, FreeRTOS version, and any other information pertinent to replicating your system. You can zip the project up and send it to r dot barry at FreeRTOS dot org.
static void prvQueueReceiveTask( void *pvParameters )
{
    /* Prevent the compiler warning about the unused parameter. */
    ( void ) pvParameters;

    for( ;; )
    {
        /* Create the other task, checking it is created successfully. */
        configASSERT( xTaskCreate( prvQueueSendTask,
                      "TX",
                      configMINIMAL_STACK_SIZE,
                      NULL, mainQUEUE_SEND_TASK_PRIORITY,
                      NULL ) );

        /* Let it run a bit. */
        vTaskDelay( 4 );
        /* Tell it to delete itself. */
        xDeleteNow = pdTRUE;
        /* Let it delete itself. */
        vTaskDelay( 4 );

        configASSERT( xDeleteNow == pdFALSE );
    }
}
/*-----------------------------------------------------------*/

static void prvQueueSendTask( void *pvParameters )
{
    ( void ) pvParameters;

    for( ;; )
    {
        if( xDeleteNow != pdFALSE )
        {
            xDeleteNow = pdFALSE;
            vTaskDelete( NULL );
        }
    }
}
/*-----------------------------------------------------------*/

static void prvQueueSendTimerCallback( TimerHandle_t xTimerHandle )
{
    /* Print from the timer callback so the frequency can be seen. */
    ulTimers = 0;
    printf( "%d, ", (int)xPortGetFreeHeapSize() );
}
/*-----------------------------------------------------------*/

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

(ignore the names of the tasks in the code I posted – I just adapted an existing ‘hello world’ style project I had)

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Thanks I will post my code. Please note that the timers get messed up only when there are continuous interrupts occurring on the GPIOs. Otherwise everything appears to be normal. As soon as interrupts stop, timers get back to normal. Also if interrupts are not enabled on the GPIO, there are no issues. Even when GPIO interrupt is enabled, there is no issue as long as interrupt is not triggered. I have Anemometer connected to the GPIO so I can easily spin it to generated a series of pulses causing interrupts on the GPIO to reproduce the issue.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

It definitely appears to be linked to deleting a task from another task. No matter how I delete the task vTaskDelete(NULL) or vTaskDelete(task_handle), it ends up messing the timers when interrupts starts coming right after deletion. If I don’t kill the task (let it running) no issues or if I Delete the task but don’t have interrupts coming, no issues either.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Are you any closer to being able to send me a cut-down project?

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Richard, I removed a lot of code to do some more debugging and here is where I am. More confused. Here is the code ~~~ int initsynctaskfreeRTOS(void) { synctask_semaphore = xSemaphoreCreateBinary();
      if (synctask_semaphore == NULL) {
          printf("Synctask Semaphore couldn't be created.n");
          return pdFALSE;
      }

      xSemaphoreTake(sync_freq_mutex, portMAX_DELAY);
      xSyncSoftwareTimer = xTimerCreate((const char *) "SyncTimer",
                                        (sync_frequency * 60000),
                                        pdTRUE,   
                                        (void*) 0,
                                        vSyncTimerCallback);
      xSemaphoreGive(sync_freq_mutex);

     if (xSyncSoftwareTimer == NULL) {
         return pdFALSE;
     }

     int ret = xTaskCreate(synctask_thread,
                           "synctask_thread",
                           configMINIMAL_STACK_SIZE,
                           NULL,
                           &synctask_handle);

     if (ret != pdTRUE) {
         printf("Cannot create synctask_threadn");
         return pdFALSE;
     }

     return ret;
 }

 void vSyncTimerCallback(TimerHandle_t xTimer)
 {
     xSemaphoreGive(synctask_semaphore);
 }

 void synctask_thread(void *thread_id)
 {
     synctask_active = true;

     if (othertask_isActive()) {
          PP_PRINTF("setting var to kill task..n");
          // This func call should cause the othertask
          // to kill itself..
         othertask_setvar(1);
     }

     xTimerStart(xSyncSoftwareTimer, 0);
     while (1) {
             xSemaphoreTake(synctask_semaphore, portMAX_DELAY);
            // Do some stuff here
     }
 }
~~~ If I call the following two together, All timers start expiring before the scheduled time as soon as the interrupts start showing up at the GPIO. Faster the interrupts, sooner the timers would expire..
       othertask_setvar(1);   <-- Kill the task
       xSemaphoreTake(synctask_semaphore, portMAX_DELAY); <- wait on semaphore
If I call only one of these two everything is fine..

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Is initsynctaskfreeRTOS() called before the scheduler is started? If so, then don’t try blocking on a semaphore because there is nothing else that can run and you couldn’t block anyway (as the scheduler is not running and no tasks are running yet). I’m not sure why you would take then give the semaphore around the call to xTimerCreate() anyway. Can you please also post the code for the “other task” (the one that kills itself), including the code that creates the task so I can see its priority, etc. – and also show the code for the ISR. Thanks.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

xSemaphoreTake(syncfreqmutex, portMAXDELAY); This mutex is taken because the variable ‘syncfrequency’ may be in use in some other task. initsynctaskfreeRTOS is not called before the scheduler is started. The main function creates a Task called inittask as: ~~~ int main(void) { uint8_t ret; HALInit(); SEGGERRTTInit(); ret = xTaskCreate(inittask,
“inittask”, 4 * configMINIMALSTACKSIZE, NULL, 1, NULL); if (ret == pdTRUE) { printf(“Starting scheduler!n”); vTaskStartScheduler(); // should never return } else { printf(“System Error!n”); } for (;;) {} } ~~~ inittask would then call initsynctaskfreeRTOS to create the synctaskthread and initother_task to create the other task. Other Task creation and execution looks like: ~~~ int othertaskisActive(void) { return othertask_running; } void othertasksetvar(bool var) { if (var) { waitvar = true; } else { waitvar = false; } } void othertask(void *p) { while (!waitvar) { vTaskDelay(5); } printf(“Other task Killing itselfn”); vTaskDelete(0); } int initothertask(void) { othertaskrunning = true; if (xTaskCreate(othertask, “othertask”, configMINIMALSTACKSIZE, NULL, 1, &othertaskhandle) != pdTRUE) { PP_ERROR(“Cannot create other taskn”); return pdFALSE; } return pdTRUE; } ~~~

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Interrupt handler is: void interrupt_handler(void) { if (__HAL_GPIO_EXTI_GET_IT(GPIO_PIN_1) != RESET) { __HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_1); if (HAL_GPIO_ReadPin(GPIOD, GPIO_PIN_1) == GPIO_PIN_SET) { rising_edges++; } else { falling_edges++; } } } Interrupt is configured as: ~~~ HALNVICDisableIRQ(EXTI1_IRQn); GPIOInitTypeDef gpio; gpio.Pin = GPIOPIN1; gpio.Mode = GPIOMODEITRISINGFALLING; gpio.Pull = GPIOPULLUP; gpio.Speed = GPIOSPEEDFAST; HALGPIOInit(GPIOD, &gpio); HALNVICSetPriority(EXTI1IRQn, configLIBRARYLOWESTINTERRUPTPRIORITY,1); HALNVICEnableIRQ(EXTI1_IRQn); ~~~

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Plot thickens. Only this other task, if deleted causes trouble. I delete other tasks and no issues. Not only this, if I create another task while creating this ‘other task’, no issues. This “othertask” is the first task created by inittask when the device boots. ~~~ synctask_ R 1 1769 11 inittask R 1 1564 1 IDLE R 0 485 2 Tmr Svc B 2 972 3 othertas B 1 406 4<— Killing this task from synctask, trouble! changesy B 3 981 10 button B 1 467 9 ~~~ Now I create another task named dummytask along with other_task and there is no issues killing this task from synctask.. Interrupts don’t cause any issues anymore! ~~~ inittask R 1 1714 1 synctask_ R 1 1758 12 datalogge R 1 460 13 IDLE R 0 485 2 dummytask B 1 477 4 <–Magically fixes problem while doing nothing! Tmr Svc B 2 972 3 othertas B 1 405 5 <—Killing this ok since I have dummytask! changesy B 3 981 11 button B 1 467 10 ~~~

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Maybe a long shot, but what happens if you take out the calls to printf()? Fist just from ‘other task’, which may get deleted before all the output has been output (depending on how printf() is implemented), and second removing printf() from all tasks.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Disabling all Prints from all over the code didn’t help. I am using Segger RTT for prints. So I disabled it all together. It seems there is something special about deleting that first ever task. If I kill that dummy task as well (along with other_task), I see the problem again. So it seems one of those tasks created in the beginning must stay in the task list.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

I think RTT is just the output method. Did you actually comment out the calls to printf()? Otherwise it will make little difference to the libraries being called by printf(), and the stack used by printf(), in order to prepare the string that will be output.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

In the printf function, I just returned without calling any functions thus effectively bypassing any calls to the functions. Individually commenting out each print statment would be a lot of statements to comment out… Something like: ~~~ int p_printf(const char *format, …) {
return 0;

if (xSemaphoreTake(printf_mutex, 3000) == pdFALSE) {
    return -1;
}

va_list args;
va_start(args, format);
int loglen = vsnprintf(LOG_BUFFER, LOG_BUFFER_SIZE, format, args);
va_end(args);

int ret = SEGGER_RTT_Write(0, LOG_BUFFER, loglen);
xSemaphoreGive(printf_mutex);
return ret;
} ~~~ Also removed Segger initialization.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

If I kill the dummytask as well, I start seeing the problem again. Also the dummy task must be running for it to fix the issue..

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

So here is what I have concluded till now. **If dummy taks isblocked for more than twice the expiry time of the fastest timer, the GPIO interrupts will cause all timers to start expiring sooner than the scheduled expiry. **

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

That seems to be good info. I can try and replicate but don’t have the interrupt executing as you do. Do I have this write: 1) Create an app with multiple tasks and a timer. 2) Make sure the tasks are blocking for more than twice the timer’s expire time. 3) Have one of the tasks delete itself and watch what happens to the timer expiry time.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Yes. That would work but interrupts coming on a GPIO is what triggers the issues. No interrupts = No issue.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

I am doing more debugging so if I find anything else I will post.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

One thing to note that may help. If a timer is due to expire every 10ms, and it is blocked from running for 30ms, then it will execute 3 times in quick succession to ‘catch up’ with where it should have been. That can make it look like all of a sudden it is running too quickly – whereas in reality, once it is caught up with itself, it will return to its proper frequency. I don’t think that is what is happening in this case, so just something to be aware of.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Let me rephrase what I see: There has to be atleast one task in the Running state. If all tasks are blocked, GPIO interrupts will cause timers to start expiring before the scheduled time I removed the dummy task I created and I put a loop at the end of the inittask so that the init task never ends. This fixes the problem because now I have at least one task (inittask) which is in Runnign state while all others are in blocked state. This is what changed at the end of the inittask: ~~~ // vTaskDelete(NULL); <— Commented this so this task doesn’t end while (1) { <— Kept it running for ever vTaskDelay(10); } } /end of inittask/ ~~~ I am testing it now to make sure it stands the test of time.. I will let it run for a while.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Interesting. So if it exectues three times in a succession, all the logic around it will execute three times as well. That would be a disaster for some applications. Also, will a GPIO interrupt cause the timer to be blocked for the duration of the ISR execution causing the above behavior?

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Interesting. So if it exectues three times in a succession, all the logic around it will execute three times as well. That would be a disaster for some applications.
Likewise it would be a disaster for some applications if it is supposed to execute three times within a given period and in fact it only executes once. Or if it missed its deadline by a single tick, so opted not to execute. Executing exactly the required number of times seems the best option.
Also, will a GPIO interrupt cause the timer to be blocked?
Only if the interrupt too a verrrrry long time to execute, or if the interrupt was not cleared properly so was continuously being re-entered. It looks like your interrupt is being cleared – assuming the code in your post is correct – though.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Also, if you want non-catchup operation, just set the timer not to repeat and retrigger it as part of the timer callback.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

There is ALWAYS a task in the ready to run state, as the Idle task that is automatically created will never block (and if you enable the idle hook, you must not block in it). Your inittask above isn’t in the ‘Running’ state for most of its time, as it is blocked with vTaskDelay(). A task that deletes itself will have its final clean up defered to being done in the idle task.
Some thoughts that pop up: Are you using the idle hook? Are you using tickless idle? Having a task aways ready to wake up soon can block going into tickless idle, and if tickless idle isn’t setup right, it could throw off your time base.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Richard, You got it. Thanks for the response. I am using tickless idle and that was the culprit. I changed the configUSETICKLESSIDLE to 0 and problem goes away. I am using idle hook too and I suspected that earlier. It uses ‘Wait for Interrupt’ in it. I commented it out but that didn’t help.. ~~~ void vApplicationIdleHook(void) { asm(“WFI”); } ~~~ What is this supposed to mean? Can’t use GPIO interrupts along with Tick less Idle? I am using default port implentation of the tick less idle.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

WFI stopps the processor until an interrupt comes. This can save power. It shouldn’t normally cause issues, as if you are in the idle task, there isn’t anything else to do, but wait for some interrupt. The possible issue with tickless idle is that something isn’t configured right. In tickless idle, if the kernal sees that nothing will be needed to be done for awhile, it reconfigures the system to stop interrupting every tick, but to go to sleep for a longer period of time, until an interrupt occurs or that long period of time expires. If it gets woken up by an interrupt, it then needs to figure out approximately how much time has expired by looking at the timer it setup and then advance time by that much. This process is NOT exact, and there can be some time slipage, and I think the tick hook may get called repeatedly (if you are using the tick hook, you may not want to use tickless idle). If you have some of the hardware configured differently than FreeRTOS is expecting, this time estimate could be off more signficantly.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

I have the tick hook enabled by #define configUSE_TICK_HOOK 1 but the the function does nothing. ~~~ void vApplicationTickHook(void) { } ~~~ What else to look at?

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

/I am using tickless idle and that was the culprit. I changed the configUSETICKLESSIDLE to 0 and problem goes away./
I vital piece of information you omitted! ;o)

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

If you have some of the hardware configured differently than FreeRTOS is expecting, this time estimate could be off more signficantly.
What does FreeRTOS expect?

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

I want to use tickless idle to save power and at the same time I want to use the GPIO interrupts. Can I use both? Currently it seems if I enable tickless Idle, I can’t use GPIO interrupt as it causes the timers to go nuts.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Yes you can use both – tickless idle is meant to allow the CPU to sleep until either an interrupt or a timeout occurs. How have you implemented the tickless mode? Remind me which FreeRTOS version you are using.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Richard, I am using 8.2.3 version For tickless mode, I have just enabled configUSETICKLESSIDLE to 1 and configUSETICKHOOK to 1 and application tickhook function is doing nothing: ~~~ void vApplicationTickHook(void) { } ~~~

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

The STM32 port uses processor’s STOP (low power) mode. This code to put the device in STOP mode is called in vPortSuppressTicksAndSleep function. In this mode, RTC Wakeup timer is used to get out of the stop mode. This is the code that is causing all the trouble. If I keep Tickless Idle ON but disable STOP Mode, it works but then the device obviously wouldn’t go to low power mode.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

My guess is that the RTC_Wakeup timer is running at a different rate than what FreeRTOS thinks it is. That can cause all kind of havok when the processor wakes back up from the interrupt, as FreeRTOS may think more time has passed than really has.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

What rate does FreeRTOS thinks it is running? I mean what variable?

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

There is probably one of two issues here: 1) The version you are using is old and some original versions of tickless idle didn’t allow the simultaneous use of software timers. I’m not sure without checking the version history when that was changed, but it’s probably worth updating the FreeRTOS kernel files (including header files and port layer files) to the latest version in case that is your issue. 2) From your description it is clear you are not using the ‘generic’ tickless idle mode, which cannot enter a very deep sleep as it uses the SysTick timer, but a chip specific version, which is using a low power timer and entering a much deeper sleep mode. It could be the implementation is not re-calculating the time correctly when low power mode is exited because of an interrupt – and that is making it appear that time has moved on past where the timers should have expired, and that the timers are catching up with where they should have been if the time were correct.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

I am suspecting #2 i.e., STM32 port not returning correct ticks after getting out of sleep mode.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

The problem was in STM32 port code. For STM32 there is mode called STOP mode which is used in conjunction with TicklessDelay feature. When Stop mode is used to put device in sleep, vPortSuppressTicksAndSleep function (in file port.c) makes call to function xPortSTM32StopMode (in file freertos_stopmode.c). This function puts the device in stop mode and returns the amount of time it slept, after it wakes up. The existing code uses RTC Wakeup Interrupt to wake up the device and the interrupt timer is set to expire at the end of the duration for which the device is supposed to sleep (i.e., the argument to the functon xPortSTM32StopMode). This function always returns the same value (=value it was supposed to sleep). This works as long as only the Wakeup interrupt wakes it up. If GPIO interrupt wakes it up, it doesn’t re-calculate how long it slept. It just returns (the incorrect) value which it was supposed to return if Wakeup interrupt woke it up. That means it returns a value much larger thatn the time for which it actually slept. This further means the freeRTOS is provided incorrect info and the timers will now expire fast. Fix for this problem is to read the RTC minutes/seconds/SubSeconds register before and after the device goes to sleep and on wakeup and then calculate the elapsed time and return. This fixed it for me. Make sure to : 1. Change resolution of the subseconds register by changing the prediva and predivs registers 2. Disable shadow registers update 3. Read the subseconds register twice, compare and if it doesn’t match read again.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Thanks Richard Barry and Richard Damon for helping me out.

GPIO Interrupt on STM32F4 causes FreeRTOS timer go haywire

Thanks for reporting back.