cancel
Showing results for 
Search instead for 
Did you mean: 

osDelay returns too early

KAgga.1
Associate III

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

13 REPLIES 13
SofLit
ST Employee

Hello,

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

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.
Sarra.S
ST Employee

Hello @KAgga.1 

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

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Uwe Bonnes
Principal III

Also check your clock setup.

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. 

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

Hello,

Better to select TIM2 for HAL and systick for FreeRTOS

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

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

Pavel A.
Evangelist III

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
Associate III

Hello @Pavel A. @SofLit @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