Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

vPortStartFirstTask need basepri=0 on stm32?

Posted by Owen on December 8, 2011
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 .

RE: vPortStartFirstTask need basepri=0 on stm32?

Posted by Richard on December 8, 2011
“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.

RE: vPortStartFirstTask need basepri=0 on stm32?

Posted by Owen on December 8, 2011
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

RE: vPortStartFirstTask need basepri=0 on stm32?

Posted by Girish S on December 28, 2011
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, [r0]
ldr r0, [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


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists