System stuck randomly on start

Kernel
1

Highlight on Usage

  • I am using FreeRTOS Kernel V10.0.1 in my system with NXP S32K14x series SOC.

Problem in Detail

  • Whenever system stuck, All the general purpose register set to 0xdeadbeef.
  • This happens on system start only and its totally random, No steps to reproduce.
  • The question is, Whatever we had written in task “BswTask0” for 1.5 second delay, It’s correct way or not?

Analysis in Detail

  • System goes into critical state.
  • OS set timeout of that task as 1500ms.
  • System come out from the critical mode.
  • System receive first tick and didn’t execute “BswTask0” for 1.5 second.
  • Once system tick(xTickCount) goes beyond 1500ms, It start further execution.

Attaching a sample code and FreeRTOS configuration file for reference.

2

There is nothing attached to your post. I’ve increased your forum privilege level so you should be able to attach something now.

3

FreeRTOSConfig.h (18.4 KB)
main.c (4.6 KB)

Here it is, Sorry I totally forgot to attach them.

4

This code…

static void BswTask0( void *pvParameters )
{
	taskENTER_CRITICAL();
	vTaskDelay(1500);
	taskEXIT_CRITICAL();
	
	// Code continue...
}

…is not going to work because vTaskDelay() will not return if interrupts are disabled. If it does return, then your interrupt priorities or configuration are incorrect.

5

Also in your main.c

is incorrect but fortunately useless since it seems you’re using the FreeRTOS default SysTick implementation which configures it to the LOWEST interrupt priority.
This ensures no/minimal impact of the OS internals to the application.

6

And beside the remarks here above: if you enable configASSERT, you will get warnings about almost any type of misconfiguration.

Like recently, I called a blocking function while the scheduler was temporarily suspended. That assert saved me a lot of time.

The blocking function was called in a simple logging function, not exactly suspected code :slight_smile:

7

Thanks rtel for looking into the issue.
I checked in detail and I came to know that, API: vTaskDelay will set timeout for that particular task and also set the “xNextTaskUnblockTime” in OS variable.

When we come out from the critical section, Tick interrupt hit and system go for tick increment where it schedule the idle task and after 1500ms, It start execution of next lines of “BswTask0” task.

I haven’t seen any line in “vTaskDelay”, Where it will wait until the timeout.

8

Exactly Hartmut Schaefer. It should be lowest. Thanks for highlighting this.
I cross verified in system register and found that, This line is useless because default priority is zero and its been override from RTOS.

9

Yes Hein Tibosch, Definitely it will help to found suspected area of code. We will plan for that.

10

When you call vTaskDelay(1500), your task is placed on the delayed task list and then a yield is performed. At that point your task will not be scheduled again until the delay time is over. The yield is here. The yield occurs inside vTaskDelay(). Your task “waits” inside vTaskDelay() to be scheduled again, and vTaskDelay() won’t return until the delay ends.

As Richard said, you must not call vTaskDelay() from inside a critical section. The tick ISR cannot execute inside a critical section, meaning that time stands still inside a critical section. Your delay would never end.

11

Thanks everyone, Finally I found the root cause.
After detailed analysis, We came to know that, Problem was in boot loader and system got stuck in application startup.

void deint_peripheral()
{
	SPI_MasterDeinit(&BmsFlashSPIInstance);
	DISABLE_INTERRUPTS();
	S32_SysTick->CSR = 0;
}

This is the deinitialization sequence in boot loader which we are performing before jumping on to the application.
What was happening that, Disable interrupt had done its job and before we DE initialize system tick, Tick interrupt was generated in back end which was creating issue while enabling the global interrupt in startup sequence of application where it jump on SysTick_Handler and OS is not yet initialize.

Thanks again everyone for looking into this matter.

12

Thank you for taking time to report back.