FreeRTOS-MPU does not use the MPU on M7 cores about stm32cubeh7 HOT 8 CLOSED

Hi @Palantir555,

I hope you are fine.

The issue you reported has been fixed in the frame of FreeRTOS Kernel V10.3.1. In addition, this version of FreeRTOS is integrated on the STM32CubeH7 V1.9.0 published on GitHub.

Thank you again for having reported.

With regards,

from stm32cubeh7.

Hi @Palantir555

Thank you for your contribution. Could you please confirm you are using the latest firmware version (STM32Cube H7 v1.7.0) and that the issue is systematically reproducible on your side?

With regards,

from stm32cubeh7.

Yeah, I'm at 1.7.0 (HEAD of master) at the moment.

The issue is 100% reproducible.

from stm32cubeh7.

Hi @Palantir555,

Thank you for having reported this point. It will be forwarded to our development teams for analysis. We will be back to you as soon as we get feedback.

Thank you for your patience and thank you again for your contribution.

With regards,

from stm32cubeh7.

To add to this, other parts of the port rely on Cortex M4-specific MPU capabilities. e.g:

#define portLAST_CONFIGURABLE_REGION            ( 7UL )

expects the MPU to support up to 8 regions, while the Cortex M7 supports up to 16. IF you are planning on expanding the port's awareness of those other 8 regions, please remove the 2 pieces of code within vPortStoreTaskMPUSettings that wipe out any MPU region not allocated by FreeRTOS.

Or provide an alternative way to allocate regions taking full advantage of the MPU HAL's capabilities.

from stm32cubeh7.

Hi @Palantir555,
Sorry for the delay,
Thanks indeed for the time spent to analyse and report the issue.
The issue is indeed confirmed, we are working to fix it.

keep you updated.

regards
Haithem.

from stm32cubeh7.

Thanks for the update Haithem. Let me know if there's anything I can do to help.

BTW, in case you haven't seen it, there's more info on that "after this fix" note here: #39

from stm32cubeh7.

ST Internal Reference: 87360

from stm32cubeh7.