vPortStartFirstTask need basepri=0 on stm32?

Hi all, In my FreeRTOS project, I have found that vPortStartFirstTask will either run or app-fault depending on the value of
configMAX_SYSCALL_INTERRUPT_PRIORITY. With configMAX_SYSCALL_INTERRUPT_PRIORITY=8 (on the STM32 scale of 0..15 where 0 is highest prio), the code runs; with configMAX_SYSCALL_INTERRUPT_PRIORITY=7, the code app-faults at “svc 0” in vPortStartFirstTask . There are 4 priority levels in use:
15: systick, pendsv
0: all other system interrupts
8: some NVIC interrupts
11: some other NVIC interrupts Here are two questions.
1. A CM3 question: I do not understand how there can be distinct behaviour with BASEPRI 7 versus BASEPRI 8. There is no interrupt at prio==7, and besides “success” in this case means successfully doing a ctx from vPortStartFirstTask .  What is  a possible mechanism here?
2. A FreeRTOS question: There are a few forum threads that tweak vPortStartFirstTask to solve CM3 issues. In one “cpsie i” was added to turn on global interrupts before “svc 0”.  But I notice that when I step to “svc 0” in vPortStartFirstTask , that the CPU register BASEPRI is non-zero. That is, vPortSetInterruptMask has been called but not cleared. Is this intentional, or should I modify vPortStartFirstTask  to clear the interrupt mask? Thanks for your suggestions. Regards, Owen Setup : FreeRTOS V7.0.2, STM32, IAR EWARM 5.30 .

vPortStartFirstTask need basepri=0 on stm32?

With configMAX_SYSCALL_INTERRUPT_PRIORITY=8 (on the STM32 scale of 0..15 where 0 is highest prio)
configMAX_SYSCALL_INTERRUPT_PRIORITY needs to be a raw priority value as it is written to the NVIC priority registers in the Cortex-M3 device, as documented in the ARM manuals.  The priorities of 0..15 are not real Cortex-M3 priorities, and are simplified priorities for use in some library calls (because the real priorities are so complex on Cortex-M devices). If you want a simplified priority of 8, then you need to set configMAX_SYSCALL_INTERRUPT_PRIORITY to 0x8n, where n can be any value, but by convention, and for future proofing in case future STM32 parts implement more priority bits, should be set to f.  Therefore, the priority you want is 0x8f.
the code app-faults at “svc 0” in vPortStartFirstTask
Presumably a hard fault because you are attempting a call to effectively a synchronous interrupt while simultaneously having that interrupt masked out. If you are using an STM32, also ensure you have *all* priority bits set as preemption priority, and none as sub-priority, that will make you life much simpler.
But I notice that when I step to “svc 0” in vPortStartFirstTask , that the CPU register BASEPRI is non-zero. That is, vPortSetInterruptMask has been called but not cleared. Is this intentional, or should I modify vPortStartFirstTask  to clear the interrupt mask?
That is intentional, and absolutely fine.  It prevents a systick while the scheduler is in an inconsistent state. Please also read the port specific configuration section of the documentation page for your port, and the “my application is not running, what could be wrong” FAQ. Regards.

vPortStartFirstTask need basepri=0 on stm32?

Mea culpa, in my first post I was speaking in terms of simplified priorities and failed to mention it. I had read the FAQ and followed it except for the part about CM3 subpriority. After removing all uses of sub-priority, my code works! Thank you Richard. Regarding sub-priority, I found no errors in my code on setting the priorities; I was able to verify them in the registers. The issues appeared to be that with NVIC configured to use sub-priorities, the SVCall seems to be masked somehow by BASEPRI even though the SVCall priority is visible as PRI_11 = 0x00 in the NVIC. Hmmm… All’s well that ends well. Thanks again. Owen

vPortStartFirstTask need basepri=0 on stm32?

We are using FreeRTOS (7.0) on STM3220-G Evaluation Board to test LwIP/PPP code.
When we create a Task, the task is scheduled well, but the local variables in the Callback function are corrupted.
In case we do not use task and directly invoke this callback function, there seems to be no issue.
The stack pointer while using FreeRTOS seems to be strange. We only have 2 tasks in the system, other one to just flash LEDs
configMAX_SYSCALL_INTERRUPT_PRIORITY = 191 vPortStartFirstTask
/* Use the NVIC offset register to locate the stack. */
ldr r0, =0xE000ED08
ldr r0,
ldr r0,
/* Set the msp back to the start of the stack. */
msr msp, r0
/* Call SVC to start the first task. */
cpsie i
svc 0