Is the port under Cortex M4F with MPU with GCC supported and proven to use?

Partners & Sponsors ST
1

Hi

I would like to use GCC port for Arm Cortex M4 with MPU provided in the freertos source folder under the path “/FreeRTOSv202112.00/FreeRTOS/Source/portable/GCC/ARM_CM4_MPU”.

I would like to know that whether this port is proven to use as it is.

I got this doubt because in the supported devices information listed in the freertos website Arm Cortex M4F was mentioned but ArmCortex M4F with MPU was not explicitly mentioned as far as I explored.

Please reply.

2

Hey @ayyap05 thanks for submitting your first post to the forum!

To answer your question we actually have a documentation page explicitly about MPU support which you can find here.

But to quote a relevant portion of that page:
“FreeRTOS provides official Memory Protection Unit (MPU) support on ARMv7-M (Cortex-M3, Cortex-M4 and Cortex-M7 microcontrollers) and ARMv8-M (Cortex-M23 and Cortex-M33 microcontroller) cores”

That said, I’m going to be reaching out to our documentation team about the fact that the MPU support is not explicitly mentioned on the supported devices table. Thanks for bringing this to our attention!

3

Yes, it is. Let us know if you face any problem.

4

Yes aggarg,

I face a problem consistently. I have adapted STM32L4 project to use for STM32F407 board.

HAL initialization finishes smoothly. I added a simple led task and when executing past the function calls in this sequence xPortStartScheduler–>vPortSVCHandler–>prvSVCHandler–>prvRestoreContextOfFirstTask in port.c file and followed by portTASK_FUNCTION( prvTimerTask, pvParameters )–>prvProcessReceivedCommands() in timers.c file and exactly at this moment MemManage_Handler signal trap was caught.

I have not done any change in port files of ARM_CM4_MPU under GCC and using as it is.
heap_4.c is the heap management file included to use.

Is there any known fix or any workaround may require to solve this.
Please look into this and help me to solve.

Thanks.

5

I afraid, the problem might be caused by your adoption/platform conversion or maybe an undiscovered bug which is revealed now by e.g. running the software at much higher or different CPU clock.
You now, the FreeRTOS port and code is the same because the CPU is the same but anything else has changed…

6

What all did you do to adapt? Did you make sure to correctly export the variables from linker script? Can you try to use the non-MPU ARM_CM4F port to narrow down? Also, can your share your complete project?

7

Have you determined the exception is caused by the code you are viewing and not an interrupt, or another task that is not executing the code you are looking at in the debugger? There is code on the FreeRTOS website that shows how to find the address of the instruction that caused an exception (will provide a link when I’m at my computer).

8

This is the link Richard wanted to share - Debugging and diagnosing hard faults on ARM Cortex-M CPUs

The above page talks about hard fault and you can do the same for mem fault.

9

Hi,

When I used xTaskCreateRestricted() api with portMPU_REGION_READ_WRITE | portMPU_REGION_EXECUTE_NEVER for Memory_Region_t parameters to create task, the task is running without MemManage fault. Earlier I used xTaskCreate().

Cant we use xTaskCreate() api in a MPU port? Or do we need any modifications to use that?

Please reply.

Thanks.

10

You cannot use xTaskCreate to create an unprivileged task. For creating an unprivileged task, you should use xTaskCreateRestricted or xTaskCreateRestrictedStatic.

11

Sorry I am newbie to freertos.
Does it mean that when using MPU port we have to use xTaskCreateRestricted or xTaskCreateRestrictedStatic?
Please show me references of privileged and unprivileged task for understanding…

Thanks.

12

The followings are some useful links to read -

Here is an example - FreeRTOS/FreeRTOS/Demo/CORTEX_MPU_M7_NUCLEO_H743ZI2_GCC_IAR_Keil at main · FreeRTOS/FreeRTOS · GitHub

13

Thanks a lot everybody who replied and supported.