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


STM32F2/4 vs. vPortValidateInterruptPriority

Posted by Werner Almesberger on July 22, 2013
portable/GCC/ARM_CM3/port.c:vPortValidateInterruptPriority requires that SCB_AIRCR.PRIGROUP be zero. It assumes that zero means that all the bits are used for group/preemption priority and none for a subpriority.

On STM32F2/4, only the values 3 through 7 are documented for PRIGROUP, with 3 meaning that there are no subpriority bits. I tried setting PRIGROUP to zero in an attempt to please vPortValidateInterruptPriority, but this causes great confusion in interrupt handling (I still get some interrupts, but others fire just once, never to be seen again).

Setting PRIGROUP to 3 and adapting the test in vPortValidateInterruptPriority accordingly makes things work as expected.

I suppose this has something to do with the STM32 only having four priority bits. Perhaps the correct value for PRIGRP should be calculated as (configPRIO_BITS == 8 ? 0 : 7-configPRIO_BITS) ?

The check for 8 is necessary because - according to Table 4.18 on http://infocenter.arm.com/help/topic/com.arm.doc.dui0552a/Cihehdge.html - even 0 still leaves one subpriority bit, so on a core that actually implemented all 8 bits, the calculation would wrap around 0.

I've seen this on an STM32F207 (CM3) and it seems that the same should also apply to STM32F4xxx (CM4F), and possibly others.

- Werner

RE: STM32F2/4 vs. vPortValidateInterruptPriority

Posted by Richard on July 22, 2013
Thanks for your report. I can replicate this on an STM32 and will investigate further. The function was tested on Cortex-M parts from three different manufacturers (two with 4 priority bits, one with three priority bits), but not unfortunately the STM32, so it might be STM32 specific.

I will report back here when I have more information.


RE: STM32F2/4 vs. vPortValidateInterruptPriority

Posted by Richard on July 22, 2013
This looks like it might be related to a persistent incompatibility between the ST peripheral driver library and generic Cortex-M code.

The binary point (priority group) bits are actually defaulted to zero when the Cortex-M powers up, so on all implementations of the Cortex-M 0 is a valid number as that is Cortex-M specific, not STM32 specific. Zero is a generic value that will work on all chips, and is normally never changed during the lifetime of an application. vPortValidateInterruptPriority() checks that the value is zero. However....

Due to the implementation of the STM32 peripheral library we have always had to provide specific instruction to STM32 users (note numerous support request answers and the bold red text on FreeRTOS.org web pages specific to Cortex-M) to ensure they call NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 ) before starting the scheduler. This is an extra step necessary for STM32 applications only. That call changes the binary point setting, and causes vPortValidateInterruptPriority() to trigger a failure, but is necessary in order to use other STM32 peripheral driver functions. A colleague of mine has just pointed out/reminded me as to why this is.

If you look at the implementation of the function NVIC_Init() library function you will see the following code:

    tmppriority = (0x700 - ((SCB->AIRCR) & (uint32_t)0x700))>> 0x08;
tmppre = (0x4 - tmppriority);

Now assume you pass the priority in as 15 when the binary point register is 0. tmppriority will then be calculated as:

tmppriority = (0x700 - 0) >> 8;
= 7;

On the next line the 4 is hard coded, resulting in tmppre being calculated as:
tmppre = 4 - 7;

... which is negative (actually as this is unsigned maths it is a huge positive), and you have a problem.

The question now is, what to do about this? We can't have a portable layer that is specific to the STM32, nor can we force users of all other chips to set a binary point value. I suspect we will have to issue a maintenance release that implements
vPortValidateInterruptPriority() to check for either 0 or an acceptable value given the number of implemented priority bits. That will naturally add some overhead.

I appreciate you pointed this out so quickly.


RE: STM32F2/4 vs. vPortValidateInterruptPriority

Posted by Werner Almesberger on July 22, 2013
Thanks for the amazingly quick analysis ! It is indeed unfortunate that this ST quirk produces a regression in FreeRTOS.

I think that allowing all values that produce the desired behaviour would be the best choice. With a decent compiler, a test for PRIGROUP >= (configPRIO_BITS == 8 ? 0 : 7-configPRIO_BITS) should have negligible overhead (if any) compared to the current check, since all the calculations are with constants anyway.

- Werner

RE: STM32F2/4 vs. vPortValidateInterruptPriority

Posted by Richard on July 22, 2013
I have updated the code to perform a "less than or equal to a maximum permissible value" check in place of the "equals zero" check. I have tested this on the STM32 first this time :o)

Currently I have it in GCC only. Which compiler are you using? If you are using GCC I can send you the file to try. If you are using a different compiler then I will update the port layer for that compiler next so you can try it.

If you want to try it then send an email to the email address on the Real Time Engineers Contact page so I have your address. Please don't post your email address to this forum.


RE: STM32F2/4 vs. vPortValidateInterruptPriority

Posted by Werner Almesberger on July 22, 2013
Yes, I use GCC. I sent a mail to the info address (there's no openly visible e-mail address on the contact page). BTW, my e-mail address isn't exactly a secret, so getting an extra serving of spam wouldn't be a concern :)

- Werner

RE: STM32F2/4 vs. vPortValidateInterruptPriority

Posted by Franz on July 23, 2013

I assume this problem is also occuring with my setup: I am using an STM32F4, since the latest FreeRTOS 7.5.0 I get stuck with vPortValidateInterruptPriority(). The priority settings are right, as the documentation of FreeRTOS instructs it: (PRIORITY_GROUP to 4 and all my ISRs which use FreeRTOS API calls have a priority lower than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY = 5). In my case the USART2 Priority is set to 9.

Can you please post your solution here, so that I can try it, or are the chages too much to post it here? I am also using GCC.

Kind regards,

RE: STM32F2/4 vs. vPortValidateInterruptPriority

Posted by Franz on July 24, 2013
Is there any chance to get an answer on this?

thanks in advance, regards

RE: STM32F2/4 vs. vPortValidateInterruptPriority

Posted by Richard on July 24, 2013
Sorry - I missed your email. The solution is already provided in the FreeRTOS V7.5.2 maintenance release available from Sourceforge.


RE: STM32F2/4 vs. vPortValidateInterruptPriority

Posted by Franz on July 24, 2013
Thanks! I will try it!


[ 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