Maximum priority from which ISR

Kernel
1

francisco-roman wrote on Tuesday, October 24, 2017:

Hello All,

I have a problem when I enable the assert functionality in freeRTOSconfig.h , the assert is referent to the priority grouping and the max level of interrupts.

configASSERT( ( portAIRCR_REG & portPRIORITY_GROUP_MASK ) <= ulMaxPRIGROUPValue );

FreeRtos: v9.00
Compiler: GCC
System: Cortex-M3
NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);

I had been cheking the values obtains during the xPortStartScheduler:

		Save the interrupt priority value that is about to be clobbered. */
		ulOriginalPriority = *pucFirstUserPriorityRegister;

		/* Determine the number of priority bits available.  First write to all
		possible bits. */
		*pucFirstUserPriorityRegister = **portMAX_8_BIT_VALUE**;

		/* Read the value back to see how many bits stuck. */
		ucMaxPriorityValue = *pucFirstUserPriorityRegister;

		/* Use the same mask on the maximum system call priority. */
		ucMaxSysCallPriority = configMAX_SYSCALL_INTERRUPT_PRIORITY & ucMaxPriorityValue;

		/* Calculate the maximum acceptable priority group value for the number
		of bits read back. */
		ulMaxPRIGROUPValue = portMAX_PRIGROUP_BITS;
        
>      In this point ucMaxPriorityValue = 248
		while( ( ucMaxPriorityValue & portTOP_BIT_OF_BYTE ) == portTOP_BIT_OF_BYTE )
		{
			ulMaxPRIGROUPValue--;
			ucMaxPriorityValue <<= ( uint8_t ) 0x01;
		}

		/* Shift the priority group value back to its position within the AIRCR
		register. */
>         In this point ulMaxPRIGROUPValue = 2;
		ulMaxPRIGROUPValue <<= portPRIGROUP_SHIFT;
		ulMaxPRIGROUPValue &= portPRIORITY_GROUP_MASK;

acording with the documentation in http://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html, usually the ucMaxPriorityValue is 11110000b or 11100000b depending of the priority group selected but when I read this register with my microcontroller the result value is 11111000b and I suppose that my microcontroller has five bits to select the max priorty, for this reason when FreeRTOS calculates the maximun acceptable priority group result is 512 and assume that the priority groupt is two.

so, when FreeRTOS makes the comparation it see this values:

portAIRCR_REG & portPRIORITY_GROUP_MASK = 0x300
ulMaxPRIGROUPValue = 200

and the assert stops the scheduler.

I had solutioning this issue changing the next value:

#define portTOP_BIT_OF_BYTE					( ( uint8_t ) 0x80 )

for

#define portTOP_BIT_OF_BYTE					( ( uint8_t ) 0xD0 )

and the issue is solved, but I’m not sure that this is the correct solution, please if anyone had the same o similar problem please help me.

Thank you for your support.

2

rtel wrote on Tuesday, October 24, 2017:

Thanks for providing so much information, but there are two important bits missing: which processor are you using and how many priority bits does the processor’s user guide say it has?

3

francisco-roman wrote on Thursday, October 26, 2017:

4

francisco-roman wrote on Saturday, November 04, 2017:

The microcontroller isn’t a comercial product and I don’t haver all information about it. But I’m in contact with de developers team and they told me that indeed the microcontroller has 5 priority bits. For this reason when FreeRtos try to determine the number of priority bits available the result is 11111000b and the priority group is two with 32 levels of priorities. Now the problen is I just need to use 16 levels of priority, I will mantain NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4), and I will omit the bit 3, then, what can I do to maintain this compatibility??
I think, that is necessary to put a mask with the correct priority group before selected, something like that:

ucMaxPriorityValue &= 0xf0

or mantain

#define portTOP_BIT_OF_BYTE                 ( ( uint8_t ) 0xD0 )

What Do you think?

5

richard_damon wrote on Sunday, November 05, 2017:

My question is why do you need just 16 levels, why not set the defines to define there to be 5 bits of priorities and have 32 levels?

6

rtel wrote on Sunday, November 05, 2017:

The defines must match the hardware, and, as per the documentation,
sub-priorities should not be used (set to 0 subpriority bits).