osDelay returns too early

[KAgga.1]

Hello There,

I'm working on an app utilizing STM32H7A3 with CMSIS-OS2.
I'm facing a problem with osDelay(). Most of the time it returns too early than the actual delay. While HAL_Delay() always works fine.

I have debugged osDelay(3500) with oscilloscope. It's giving a delay of 141ms.
The before and after ticks were also 5537 and 5678 respectively.
Freertos tick rate is 1000Hz.

I have also tried setting the delay between 500 and 3500. But the actual one comes out to be 100-200ms.
Any help is appreciated.

Regards,

Keshav Aggarwal

[mƎALLEm]

Hello,

Are you reproducing the behavior with a very simple code? just toggling a LED for example?

[Sarra.S]

Hello @KAgga.1 

Also, are you using systick? and did you try to use another timer as RTOS clock? 

[Uwe Bonnes]

Also check your clock setup.

[KAgga.1]

Thanks for replying!
I'm not able to reproduce the issue. I'm working in a multi-threaded environment.
Some time it works and some time doesn't.
Is there any way to debug the behaviour of osDelay. 

[KAgga.1]

Thanks for your reply!
I'm not using systick. Using TIM2 as a clock source.

[mƎALLEm]

Hello,

Better to select TIM2 for HAL and systick for FreeRTOS

[KAgga.1]

Hello!
Clock setup seems to be ok.
I'm also attaching .ioc file if you want to have a look.

[Pavel A.]

> I'm not able to reproduce the issue.
> Some time it works and some time doesn't.
Then it may be a memory corruption or something nasty like that. Check the stacks of the tasks and the main (interrupt) stack, enable stack checking in runtime. Do not use problematic things like allocations and stdio in the test, or anything else that requires locks & "concurrency support".

[KAgga.1]

Hello @Pavel A. @mƎALLEm @Uwe Bonnes @Sarra.S 
Finally I'm able to reproduce the issue. Let me explain.
1. Consider 2 tasks Task1 and Task2. Priority of Task1>Task2
2. The execution starts with Task2. When osDelay(3500) is called up, execution goes to Task1.
3. Now, at some point Task1 performs some critical job during which intervention of Task2 isn't allowed. So, I called osThreadSuspend(Task2) for that. After the job is done and upon calling osThreadResume(Task2), execution switches back to Task2. Now osDelay(3500) returns without waiting for actual ticks.

It seems osThreadSuspend/osThreadResume is conflicting with osDelay. Take the reference of below pseudo code.

void ISR()
{
  post_sem(1);
}

void task1()
{
  while(1)
  {
    sem_wait(1);
    osThreadSuspendTask2();
    //do critical processing
    ...
    //critical processing done
    osThreadResumeTask2();
  }
}

void task2()
{
  //initialization
  ...
  while(1)
  {
    ...
    osDelay(3500);
    ...
  }
}

Regards,

Keshav Aggarwal