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; }
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.