Is it possible to run into a race condition when calling HAL_GetTick()?

[a411E]

I am designing an application with a control loop of 1 ms, and I would like to use HAL_GetTick() as the way of clocking this loop. This is a safety critical system, and I would like to know if one will run into a race condition by calling this function.

[After Forever]

Judging by your question you are a beginner in STM32 development, why are you designing "a safety critical system"?

[a411E]

Yup, I am brand spanking new at this. I am designing controls for some fast moving industrial machinery, and I am evaluating stm32 for the job. I thought the HAL could speed up my development without me having to get too close to the bare metal. How does one usually do such a job with stm32?

[Ozone]

And including maintainance, I am of the strong opinion that "safety critical system" and Cube/HAL do not play well together. I dare to say, not at all.

Doing software for safety critical applications myself (construction machinery).

[a411E]

That's good to know, O3. How are you using STM32 for your safety critical applications? Are you using the LL APIs? Is there a book you can recommend?

[Ozone]

No, neither.

This has other reasons - my company has used a lot of Fujitsu/Cypress MCUs in the past, and continues to do so.

For some projects, Cortex M3/M4 controllers comparable to the F3/F4 series are in use.

We have different platforms (not only ARM), but we always use a RTOS (OSEK, FreeRTOS, SafeRTOS). None of this RTOSs is "compatible" with the resource grab that Cube presumes to do. Time management and timer interrupts are under control of said RTOS.

We use the Cypress libs for peripheral functions. With Cube, the LL_ code would be the equivalent in size and coverage.

And since we get our software certified, we do lib updates VERY rarely. Usually only with a new ECU generation.

> Is there a book you can recommend?

I wouldn't call myself an expert in this field. But different branches (automotive, railway, cranes, etc.) have different safety requirements and different safety standards. Your colleagues should be able to recommend you one that covers your standards.

[Piranha]

The HAL_GetTick() function itself is thread-safe, because it only reads one word size (32-bit) variable and on a Cortex-M that is an atomic operation. But that doesn't stop You from making race conditions possible with Your code.

But really control loop should be clocked from a dedicated hardware timer.

[Tesla DeLorean]

The real issue is that in most cases the ticker is incremented by a software interrupt, and the systemic use of interrupts/callbacks with little care for priorities or dead-locks.

Ideally the tick count should be read from something like TIM2->CNT and accommodations made for non-1ms ticking (timeouts, and related), and not via scaling the 32-bit CNT value.