Is it safe to use Win32 API GetTickCount() from withing FreeRTOS tasks on Win32 port?

I want to have unified function which will return millisecond-precision tick count, during both before the start of scheduler, and after starting. The simple GetTickCount() is an ideal fit. But there are recommendations not to use any WinAPI from within FreeRTOS tasks. On the other hand, it seems to work, and I can hardly imagine scenario when simple GetTickCount() could interfere with FreeRTOS scheduler port functioning. Can anyone more experienced say for sure, is it 100% safe to use this function from the context of FreeRTOS tasks and simulated interrupts?

Hello Vitaly,

In a portable FreeRTOS application, xTaskGetTickCount() should be used to get time measured in ticks since the scheduler has started. This should be used for timeouts, sleep durations, etc, inside a FreeRTOS task.

/* Time in milliseconds since the FreeRTOS scheduler has started */
TickType_t now = pdTICKS_TO_MS( xTaskGetTickCount() );

/* a complementary macro exists to convert milliseconds into ticks
 * As long as the 
TickType_t nowTicks = pdMS_TO_TICKS( now );

/* The FromISR variant should be used inside interrupts */
TickType_t nowISR = pdTICKS_TO_MS( xTaskGetTickCountFromISR() );

Any timestamps derived from another source won’t be synchronous with the FreeRTOS tick due to imprecision and/or clock drift (either by the source or the simulation). So, that timestamp won’t be useful for sleeping and timeouts.
If timestamps are needed during initialization, then maybe that initialization should be a part of a main task so that FreeRTOS tick counts are available.

Thank you for reply. Portability is achievied in my case by using HAL_GetTick() from MCU HAL with dedicated timer ISR in MCU build, and desire to use GetTickCount() Win32 API in simulator build. I’ve read about xTaskGetTickCount(), but win32 GetTickCount() would be more convinient since it provides flat monotonously increasing values without additional complications in the difference between execution modes before and after starting of the scheduler, which is more close to MCU HAL_GetTick() with dedicated ISR for increasing counter value. If it is hard to say whether or not it is 100% safe in this context, I can switch to xTaskGetTickCount(), with reworking the code that uses timestamps before starting of the scheduler.

The reason you do not want to call any OS API from a FreeRTOS task is to ensure that a FreeRTOS task does not block outside the knowledge of the FreeRTOS scheduler. Because we cannot be sure whether or not GetTickCount() ever blocks, it would be best to switch to xTaskGetTickCount.

Thank you for thorough clarifications, I’ll rework my code.

UPD: for all who is interested: I reworked this function to just read xTickCount variable from tasks.c when scheduler has been started. Although GetTickCount() does not seem to introduce any unnecessary blocking, in other place in the code, I used GetFileType() function, and this was likely a culprit for periodic program freezes. So advice not to use any OS API is valuable.