xPortRaisePrivilege() and vPortResetPrivilege() from outside Kernel

Kernel
1

Hi all,

I’m looking for advice.

Background
I’m on a Cortex M33 with MPU support enabled in FreeRTOS. Therefore my regular unprivileged threads are limited to certain pre-prescribed memory regions.
My project has an additional OS interface layer for interfacing with FreeRTOS for software re-distributality and convenience reasons.
In certain controlled circumstances I wish for my unprivileged threads to intentionally break the MPU boundaries. The prime example is to print debug messages to the console. I don’t want to use one of my precious 3 configurable memory regions for this, and I’m trying to avoid some convoluted messaging system for a bit of debug.

Question
Previously (kernel v10.3.1) I was able to call xPortRaisePrivilege() and vPortResetPrivilege() from my OS interface layer; outside the FreeRTOS kernel, but inside “my” kernel.
I have recently updated FreeRTOS to v10.4.6 and I note that xPortRaisePrivilege() and vPortResetPrivilege() have been relocated to prevent my misuse of these functions.

I get it, but now I’m left wondering: What is the best/most-canonical way to call xPortRaisePrivilege() from my outside the FreeRTOS kernel, or otherwise print debug from my unprivileged threads?

2

One way to solve this problem is to have a separate debug logging task which has access to the UART peripheral. All the tasks can post messages to a queue which is serviced by the logging task.

If you want to raise privileged and then drop privilege, you can use portRAISE_PRIVILEGE and portRESET_PRIVILEGE. You need to ensure that the function that calls portRAISE_PRIVILEGE is placed in the FreeRTOS system calls section, otherwise the privilege will not be escalated. Following is the pseudo code demonstrating the idea -

void print_debug_message( const char * msg ) __attribute__( ( section( "freertos_system_calls" ) ) );
void print_debug_message( const char * msg )
{
    portRAISE_PRIVILEGE();
    uart_print_message( msg );
    portRESET_PRIVILEGE();
}
3

Hi Gaurav,

Thanks for your reply. I’m looking to avoid a separate logging task for now, but yes that’s the “proper” way to not violate the MPU protection.

As it happens your second solution is exactly what I had implemented before posting my question; I’m happy we’re on the same page.