OS Ticks missing FreeRTOS on STM32F4 (Used tracelyzer)

Kernel
1

developb wrote on Thursday, October 24, 2019:

Hi,
The attachment shows tracelyzer output for application with 2 tasks on FreeRTOS on STM32 F4 platform (configured using STM32Cube IDE selecting CMSIS V2).
It is evident that tick events are missing in between (ie tick events are not generated, ticks are incrementing properly, during which no context switch cannot happen), leading to unexpected behaviour in realtime.

I have configured TIM8 for Timer base source for SysTick; has this got something to do with the behaviour?
Is it possible that STM is going to low power mode which could cause this? In that case how do I fix/work this out?

Kindly guide.

2

developb wrote on Thursday, October 24, 2019:

I missed mentioning a fact that I commented interrupt handler callback for TIM8 (which I set for TICK interrupt in System Core settings in STM32CubeMX).

If I uncomment this it works.

3

rtel wrote on Thursday, October 24, 2019:

I can’t view the images at the moment, but can you give more detail on your second post. It sounds like you are saying that if you comment out the tim8 interrupt then it doesn’t work, but if you don’t comment it out then it does - and that tim8 is the tick interrupt. Am I interpreting that correctly?

4

developb wrote on Thursday, October 24, 2019:

Yes, exactly. I commented the auto generated code below:
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
if (htim->Instance == TIM8) {
HAL_IncTick();
}

I dont now understand, how were the context switches happening at all earlier, given the fact that uncommenting this function fixed the tick event generation issue and other issues similar to this (as if schedule() function is not getting called at all during the period when tick event is not observed in tracelyzer).

5

rtel wrote on Thursday, October 24, 2019:

This is ST code, not FreeRTOS code, but the ST tick code calls the FreeRTOS tick code, so it makes sense that commenting out the function stops ticks from happening. You can look at the implementation of HAL_tick() to see what it is doing.

6

aggarg-aws wrote on Tuesday, October 29, 2019:

Commenting the HAL_TIM_PeriodElapsedCallback essentially stops ST HAL tick from incrementing and is therefore not the right thing to do.

Thanks.

7

developb wrote on Wednesday, October 30, 2019:

The function code generated when increments a counter : uwTick += uwTickFreq.

My doubt is:
How did context switch occur at all earlier when I commented this autogenerated code? There should not be any context switch at all.

I am analyzing/reading freertos manual to understand, but I wanted to be in sync with the experts too in case am getting deviated in resolving/understanding the actual issue causing the tick events being missed in tracelyzer.

Thank you.

8

rtel wrote on Wednesday, October 30, 2019:

From what I’ve seen of the code generated by ST (remember this is not
our code, so I don’t know the answer for sure, so you could ask ST) the
interrupt handler calls the ST handler and, somewhere in that, call the
FreeRTOS tick handler as well.

9

aggarg-aws wrote on Thursday, October 31, 2019:

There are two timers here:

  1. TIM8 timer - It is being used by ST HAL. Look at the implementation of the following functions:
void HAL_IncTick(void);
void HAL_Delay(uint32_t Delay);
uint32_t HAL_GetTick(void);
void HAL_SuspendTick(void);
void HAL_ResumeTick(void);
  1. Systick - It is being used by FreeRTOS for generating regular tick interrupts(which result in context switch).

Disabling the callback for the first one would result in ST HAL not functioning correctly. Why the systick stops generating for some periods when TIM8 callback is disabled - it would require more investigation though, as I said earlier, it is not the right thing to do.

Thanks.

10

rtel wrote on Thursday, October 31, 2019:

I’m this case I don’t think the systick is being used. The ST tools allow you to set which timer to use to generate a tick. I can’t view it now but think the first post in the thread noted this.