Hello,
I have adapted my last project to the new RTOS2 RTX. It works fine but I think I found a bug : 'SVC_Initialize' function in 'rtx_kernel.c' uses the priority grouping configuration but priority grouping has not been initialized previously. Moreover, because AIRCR register reset value is 0xFA05.0000 after reset, i.e. no priority grouping defined, calls to 'NVC_Init' has no effect on interrupt priorities.
I fixed this problem adding a call to 'NVIC_PriorityGroupConfig' function in 'svcRtxKernelInitialize' function before the call to 'SVC_Initialize' function as below :
...
NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4); // Code added
// Initialize SVC and PendSV System Service Calls SVC_Initialize();
osRtxInfo.kernel.state = osRtxKernelReady;
EvrRtxKernelInitializeCompleted();
return osOK; }
You should not add code for setting Priority Grouping into “SVC_Initialize”. The function reads the current priority grouping which might have been configured by the user or the default value after reset (which is well defined).
User can configure priority grouping if needed (different from default value) before calling “osKernelInitialize.”
thank you for this quick answer. After a new analysis, it appear that the problem is not in the RTOS2 (sorry) but in the 'NVIC_Init' function. It is not part of the Keil code but I send information for help.
When priority grouping chosen is 'no bits for subpriority / all bits for group priority', the PRIGROUP bits of the AIRCR register must be 0b0xx (see §4.4.5 of ST PM0214 Programming manual).
After reset, the values of these bits in AIRCR are 0b000.
The same choice of 'no bits for subpriority' when calling 'NVIC_PriorityGroupConfig' is calling the function with the parameter 'NVIC_PriorityGroup_4' (value = 0x300, PRIGROUP = 0b011) that leads to the same result as the reset value of 0b000 because to two LSB are 'xx'.
the problem is that 'NVIC_Init' does not work fine when PRIGROUP bits values are 0b000.
See below the result obtain in both cases with NVIC_IRQChannelPreemptionPriority = 9.
void NVIC_Init(NVIC_InitTypeDef* NVIC_InitStruct) { uint8_t tmppriority = 0x00, tmppre = 0x00, tmpsub = 0x0F;
... /* Compute the Corresponding IRQ Priority --------------------------------*/ tmppriority = (0x700 - ((SCB->AIRCR) & (uint32_t)0x700))>> 0x08; // 0b011: tmppriority = 0x04, 0xb000: tmppriority = 0x07
tmppre = (0x4 - tmppriority); // 0b011: tmppre = 0x00, 0xb000: tmppre = 0xFD = > bug
tmpsub = tmpsub >> tmppriority; // 0b011: tmpsub = 0x00, 0xb000: tmpsub = 0x00
tmppriority = NVIC_InitStruct->NVIC_IRQChannelPreemptionPriority << tmppre; // 0b011: tmppriority = 0x09, 0xb000: tmppriority = 0x00
tmppriority |= (uint8_t)(NVIC_InitStruct->NVIC_IRQChannelSubPriority & tmpsub); // 0b011: tmppriority = 0x09, 0xb000: tmppriority = 0x00
tmppriority = tmppriority << 0x04; // 0b011: tmppriority = 0x90, 0xb000: tmppriority = 0x00
NVIC->IP[NVIC_InitStruct->NVIC_IRQChannel] = tmppriority;
Conclusion: when PRRIGROUP bits values = 0b000, NVIC->IP[xxx] are always set to 0, whatever the values transmitted to 'NVIC_Init'.
Proposed correction :
/* Compute the Corresponding IRQ Priority --------------------------------*/ tmppriority = (0x700 - ((SCB->AIRCR) & (uint32_t)0x700))>> 0x08;
// Bug fixed : if (tmppriority > 4) { tmppriority = 4; }
tmppre = (0x4 - tmppriority);
ALL of the functions you are referring to are written by ST. They are not part of the CMSIS standard for referencing the NVIC.
ST handles priority groups different then the "standard way". They defined the way they handle it before the standard existed (they had to handle it some way so they did). They kept this way after the standard was documented. The good thing is they don't prohibit you from using the standard while still allowing you to use the non-standard way.
NVIC_Init() is not part of the standard. This is an ST concept. In the design of the Cortex-M processor it was not intended that a user would have to initialize the NVIC before it would work. The NVIC comes up in a defined and working state from the start. PRIGROUP is set to 0.
The standard uses the function __NVIC_SetPriorityGrouping(uint32_t group) to set the priority group field. There is no abstraction here. The group can be any value 0..7. When the processor comes up, the group is set to 0. This means that you are considered to be in what I would call Priority_Group_0 (almost the complete opposite of what ST calls it) if I were to call it something, but is really just a number between 0 and 7 (with fully defined behavior). ST created an abstraction that attempts to put names that have meaning to the values.
The PRIGROUP field comes up set to 0 when the processor is reset. On the processor you are using, PRIGROUP set to 0,1,2 or 3 will result in the same behavior as you have 4 bits for interrupt priority and 4 bits for the Group Priority and 0 bits for sub priority. ST added an abstraction that you can use (but don't have too).
ST defines NVIC_PriorityGroup_4 and it puts a 3 in the PRIGROUP Field. ST defines NVIC_PriorityGroup_0 and it puts a 7 in the PRIGROUP Field.
The standard NVIC functions do not add this abstraction. You specify the integer you want in the PRIGROUP field. (They DO add an abstraction when setting the actual priority based on the number of PRIO bits used in the priority field - the Abstract Priority is always in the range of 0 .. ((2^#PRIOBITS)-1) - 0..15 in your case.)
PRIGROUP value ST Abstraction 0 NONE: should behave like NVIC_Priority_Group_4 1 NONE: should behave like NVIC_Priority_Group_4 2 NONE: should behave like NVIC_Priority_Group_4 3 NVIC_Priority_Group_4 (3) 4 NVIC_Priority_Group_3 (4) 5 NVIC_Priority_Group_2 (5) 6 NVIC_Priority_Group_1 (6) 7 NVIC_Priority_Group_0 (7)
Section 4.3.1 of the document referenced show how to use the NVIC by making calls to the standard CMSIS functions. Unfortunately they do not seem to show the standard functions used for priority grouping.
As noted NVIC_Init() is not a standard function NVIC_PriorityGroupConfig() is not a standard function NVIC_PriorityGroup_n is not a standard used to refer to PRIGROUP values. NVIC_IRQChannelPreemptionPriority() is not a standard function
The ST's method works as intended and is supported for ST parts.
The CMSIS method works as intended on all Cortex M processors and is supported by ARM.
You are free to use either way OR to write the NVIC registers directly.