Task Priority not being set for higher level of task priority; assertion ( uxPriority & (~portPRIVILEGE_BIT)) < configMAX_PRIORITES : Failed [FreeRTOS 8.0.1 - GNU GCC Compiler - AT32UC3C0512C]

Kernel
1

chu13279 wrote on Monday, January 07, 2019:

Hi,
I’m currently setting up the configuration of FreeRTOSConfig.h and I encountered problem trying to get higher level of priority when I tried to set a task at Priority level 5 and 6. I modified some of the parameters for higher level of task priorities as follows in the FreeRTOSConfig.h .

#define configMAX_PRIORITIES                    ( ( uint32_t ) 7 )
#define configMINIMAL_STACK_SIZE                ( ( uint16_t ) 200 )
/* configTOTAL_HEAP_SIZE is not used when heap_3.c is used. */
#define configTOTAL_HEAP_SIZE                   ( ( size_t ) ( 15000 ) )

The usStackDepth of xTaskCreate of the function has 100 words right now and there are total of 6 tasks, each one having task priority of 1 to 6. If I have enabled only 4 tasks, of level 1 to 4, then the program runs fine; however having enabled tasks with priority level 5 and 6 or at least one of them gives the following error in the terminal that I’m able to see what the microcontroller is doing.

assertion ( uxPriority & (~portPRIVILEGE_BIT)) < configMAX_PRIORITES : Failed

The task is created as following manner as en example.

void dummy1(void * pvParameters);
xTaskCreate(dummy1, "dum1", 100, NULL, task_prio_lvl_1, NULL);

Can please someone explain me what am I doing wrong? Thanks in advance.

Regards

2

rtel wrote on Monday, January 07, 2019:

[Please use a shorter title for your posts as it is hard to see anything
past “~po” in the web interface and the file names will be too long to
add the the static archive]

The assert is not in the current FreeRTOS version, but I can see it
here:
https://sourceforge.net/p/freertos/code/HEAD/tree/tags/V8.0.1/FreeRTOS/Source/tasks.c#l521

If configMAX_PRIORITIES is 7 then the assert should not fail if you pass
a value of 6, so I’m guessing you have either edited a version of
FreeRTOSConfig.h other than the one your compiler is actually picking up
(right click the configMAX_PRIORITIES constant in the editor and then
click whichever options takes you to where it is defined to see which
file is being used), or for some reason the dependencies are not working
and file containing the assert() has not been rebuilt since you edited
FreeRTOSConfig.h (try forcing a complete clean and rebuild).

3

chu13279 wrote on Monday, January 07, 2019:

Hi,

sorry for the long post title. Thansk for the reference to assertion message. For the last point, I too did understood that in theory the assert won’t fail as I’m passing the value of 6 in the end. I’ve tried changing FreeRTOSConfig.h with the same setup to see if it was picking up the wrong one. However, it didn’t work, so I’ll look up for the dependencies as you suggested. As an additional note, the build has been always cleanly built and uploaded so I guess this part wouldn’t be the issue. I’ll check up again and see if I can get it to work. Thanks.

4

chu13279 wrote on Tuesday, January 08, 2019:

I was able to fix temporarily to set the level of priority higher than 4. The FreeRTOS version 8.0.1 is the one that is using to build, so it was being modified at the correct place. However, it seems that parameters from FreeRTOSConfig.h are not being loaded correctly somehow. Because I fixed it by defining the max level of priority in tasks.c directly.

configASSERT( ( ( uxPriority & ( ~portPRIVILEGE_BIT ) ) < configMAX_PRIORITIES ) );

to this

configASSERT( ( ( uxPriority & ( ~portPRIVILEGE_BIT ) ) < 7 ) );

, and it is temporarily as I wouldn’t like to unchain by directly modifying the tasks.c for example instead of going to FreeRTOSConfig.h where it’s supposed to be modified for its parameters. So, is this about dependency issue that the file is not being discovered correclty even though everything is called out correctly or other type issue? Thanks

5

rtel wrote on Tuesday, January 08, 2019:

This sounds like you have a build issue with either the dependencies not
being worked out correctly, or incorrect paths, or something - I would
recommend you fix that before doing any further development.

6

chu13279 wrote on Tuesday, January 08, 2019:

Thanks for the help. I’ll fix build related issues before any further development. If I get to know something interesting, I’ll post it in the future.