Freertos v10 context switch issue

Kernel
1

wess wrote on Wednesday, May 09, 2018:

Hi

I am trying to implement freertos in kinetis board, I was able to start the scheduler and switch between my two tasks (with svc call ) however when entering systick handler to increment the tick and switch between the two tasks when required through the Pendsv interrupt handler the switch is not executed and then the code get stuck

Below the basic two tasks

Void task1(void)
{
VTaskdelay( 50 );
}
Void task1(void)
{
VTaskdelay( 5 );
}

The interesting thing is whenever I don’t use taskdelay only task1 is executed after starting the scheduler but task2 never called then.

Is there any idea about what is going on?

Many thanks

2

rtel wrote on Thursday, May 10, 2018:

I am trying to implement freertos in kinetis board, I was able to start
the scheduler and switch between my two tasks (with svc call )

Unless you are using the MPU port, the SVC interrupt is only used to
start the scheduler. After that all context switches use the PendSV
interrupt.

Below the basic two tasks

Void task1(void)
{
VTaskdelay( 50 );
}
Void task1(void)
{
VTaskdelay( 5 );
}

Tasks must either run forever, or delete themselves, so the following
task implementations are valid, although the second one will only run once:

void task1( void )
{
for( ;; )
{
vTaskDelay( 5 );
}
}

void task2( void )
{
vTaskDelay( 5 );
vTaskDelete( NULL );
}

Some links that might help:

3

wess wrote on Tuesday, May 15, 2018:

Hi
Thank you for your support is working now in cortex m7 based platform

However whenever I make a reset while the tasks are running to jump again to reset handler in start-up file I get a hardfault when starting again the execution after this reset and by tracking the source of the problem I found that an unaligned access caused by STM instruction.

So I am wondering if the running tasks could cause an overwrite of same sram address causing this kind of problem?

And in general a reset while tasks are running in freertos is it safe or there are some points must be taken into consideration

Many thanks in advance.

4

rtel wrote on Tuesday, May 15, 2018:

How are you resetting the device? If it is a hard reset then the MCU
should return to its reset state. FreeRTOS cannot influence that.

5

wess wrote on Wednesday, May 16, 2018:

7IYes it is, after reset the program counter start to fetch from address 0×4 and main start pointer of cortex m7 is loaded with value stored in address 0x00 and this is what I got however the program itself is located in sram adress 0x20000000 so therefore I was suspecting that tasks running under freertos could overwrite some sram address knowing that I am using heap_2 for allocation memory to tasks.

Other point the tasks are using the process stack pointer (psp) so I am wondering the initial value loaded to PSP when the scheduler start where it is assigned and loaded in freertos?

Many thanks

6

wess wrote on Monday, May 21, 2018:

I will answer

The problem is after reset and jumping to reset handler while tasks are running with freertos the PSP stack pointer is not initialized in start-up and PSP stack pointer is used by running tasks as recommended by arm in such cases( using thread mode and PSP stack pointer to execute freertos tasks ) but after reset , reset handler will be executed in thread mode using PSP stack pointer and not MSP and PSP will hold the last value while tasks are running
Solution switch to handler mode with MSP then initializing PSP to reset value so it could be possible restarting properly the whole program.