Is there an example for using the Cortex-M33 MPU with nRF Connect SDK Bare Metal?

Hello,

We want to use the Arm Cortex-M33 Memory Protection Unit on the nRF54L15 with nRF Connect SDK Bare Metal to protect selected memory regions, for example, making a region read-only, preventing execution from a RAM region, or restricting access to privileged code.

The nrfx nRF54L15 driver support page does not list an MPU component, so we would appreciate clarification on the following:

  1. Can a Bare Metal application configure and use the Cortex-M33 MPU directly through the CMSIS ARM_MPU_* functions?

  2. Is there an example demonstrating MPU region configuration, access permissions, and handling of memory access violations?

  3. Does the S145 SoftDevice use or reserve any MPU regions, or impose restrictions on the application’s MPU configuration?

  4. If MPU configuration is not currently supported, does Nordic plan to add support and examples in a future release of nRF Connect SDK Bare Metal?

Thank you very much!

2.16.1.2
Parents
  • Hello,

    The MPU is already being configured on startup through the zephyr init code based on Kconfig settings and the chip's memory described in the board devicetree files: 

    RAM should be set to non-executable by default, but you can verify this by reading out the MPU configuration register or by trying to execute code from RAM.

    Best regards,

    Vidar

  • Thank you for the reply. I may be misunderstanding the architecture, but the code shown in your screenshot appears to come from Zephyr, while we are using nRF Connect SDK Bare Metal.

    My original question came from finding the MPU HAL in the nrfx documentation. We are evaluating whether the Cortex-M33 MPU can be used to segregate parts of our application and protect selected code and data regions.

    Could you clarify whether the Zephyr MPU initialization shown in your screenshot is also used by a Bare Metal application and, if so, how we can add a custom protected memory region?

    Thank you.

Reply
  • Thank you for the reply. I may be misunderstanding the architecture, but the code shown in your screenshot appears to come from Zephyr, while we are using nRF Connect SDK Bare Metal.

    My original question came from finding the MPU HAL in the nrfx documentation. We are evaluating whether the Cortex-M33 MPU can be used to segregate parts of our application and protect selected code and data regions.

    Could you clarify whether the Zephyr MPU initialization shown in your screenshot is also used by a Bare Metal application and, if so, how we can add a custom protected memory region?

    Thank you.

Children
  • Yes, the Bare Metal SDK also uses some code from Zephyr and that is what my screenshot shows. I am not sure if you are building from the command line or through the extension, but the extension makes it easy to browse what files are included in the build.

    That said, this code is not implemented as a generic driver. It will initialise the default regions and enable the MPU on startup but it does not expose APIs that will allow you to configure regions from your application, so for more advanced usage I would consider making my own driver using the Zephyr code as a reference.

    The Softdevice does  doesn't reserve access to the MPU. You can see which peripherals the Softdevice reserves access to in the documentation: https://docs.nordicsemi.com/r/bundle/sds_s145/page/sds/s1xx/sd_resource_reqs/hw_block_interrupt_vector.html 

  • Thank you for the clarification.

    I checked the linked S145 documentation and the referenced SoftDevice Controller and MPSL integration notes. For the nRF54L Series, I can see several reserved peripherals and channels, but I cannot find the Cortex-M33 MPU in those lists.

    We are developing software for a Class C medical device and need segregation between software components. In particular, we must treat the S145 SoftDevice as Software of Unknown Provenance (SOUP), so we are evaluating whether the MPU can isolate safety-related code and data and prevent unintended memory access by the SoftDevice.

    Could you please point me to the specific documentation stating that S145 reserves access to the MPU, or clarify whether you meant another peripheral?

    Thank you.

  • I am sorry, I meant to write that that the softdevice *doesn't* reserve access to the MPU. The MPU can be used freely by your application. I hope this is enough to get the necessary isolation between your critical application code and softdevice.

Related