G3P-22238: Enable MPU privilege support for Cortex-M33 FreeRTOS port - #14
Merged
nickfritz33 merged 6 commits intoMay 6, 2026
Merged
Conversation
- portasm.c: Add ISB after DSB when enabling MPU in both vRestoreContextOfFirstTask and PendSV_Handler, as required by ARM architecture to flush the instruction pipeline after MPU configuration changes. - port.c: Clear MPU regions 4-7 before configuring FreeRTOS regions 0-3. TF-M may leave the NS MPU enabled with unknown content in regions 4-7; since higher region numbers take priority in ARMv8-M, these must be cleared to prevent them from overriding FreeRTOS region configuration. - cmsis_os2.c: Propagate osThreadPrivileged attribute to FreeRTOS portPRIVILEGE_BIT when configENABLE_MPU=1, allowing CMSIS-RTOS2 callers to create privileged tasks via the standard API. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…E_MPU=1 Add osThreadPrivileged and osThreadUnprivileged attribute bits to the FreeRTOS CMSIS wrapper header (previously only defined in the FuSa/CMSIS_5 header, so the configENABLE_MPU=1 code path in cmsis_os2.c could not compile). Change osThreadNew privilege logic from opt-in to opt-out: all threads created via osThreadNew are privileged by default. Pass osThreadUnprivileged explicitly to create an unprivileged thread. Genuinely unprivileged tasks intended to run under MPU restrictions should use xTaskCreateRestrictedStatic directly instead. This is required because ThreadAttributesWithStack defaults is_privileged to false, meaning many internal service threads throughout the codebase did not set osThreadPrivileged, causing them to run unprivileged under configENABLE_MPU=1 and fault with IACCVIOL at iThreadService::Bootstrap. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
With configENABLE_MPU=1, FreeRTOS uses portPRIVILEGE_BIT in the task priority to mark tasks as privileged. The CMSIS wrapper had no awareness of this, so all tasks created via osThreadNew ran unprivileged and faulted with IACCVIOL. - Add osThreadPrivileged and osThreadUnprivileged attribute bit definitions to cmsis_os2.h (previously only defined in the FuSa/CMSIS_5 header). - Propagate portPRIVILEGE_BIT in osThreadNew when configENABLE_MPU=1, defaulting to privileged unless osThreadUnprivileged is explicitly requested. This avoids touching every osThreadNew call site in the codebase since ThreadAttributesWithStack defaults is_privileged to false. Genuinely unprivileged tasks should use xTaskCreateRestrictedStatic directly. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- osThreadUnprivileged corrected from 0x00000008U to 0x00000002U to match
the released CMSIS-RTOS2 2.2.0 API specification (ARM-software/CMSIS_5)
- osThreadPrivileged (0x00000004U) was already correct and unchanged
- The 0x8 value was a manual addition that predated the 2.2.0 spec and
placed the bit outside the defined attr_bits layout:
bit 0 = osThreadJoinable (0x1)
bit 1 = osThreadUnprivileged (0x2) <- correct per 2.2.0
bit 2 = osThreadPrivileged (0x4)
- The incorrect 0x8 value had no runtime impact on FreeRTOS 10.5.1 since
cmsis_os2.c does not check osThreadUnprivileged in any code path, but
would have caused silent failure on RTX5 migration as RTX5 checks bit 1
- This commit is intentionally made before revert for documentation
purposes — the correct value will carry forward in the released 2.2.0
header replacement
Vendor upgrade from v2.1.3 to v2.2.0. Adds Process Isolation and Functional Safety APIs including osThreadUnprivileged/osThreadPrivileged and osThreadProtectPrivileged, which are required for MPU privilege support introduced in this branch.
Whitespace, brace style, and include ordering fixes applied by pre-commit hooks.
austinladshaw
approved these changes
May 4, 2026
austinladshaw
left a comment
austinladshaw
left a comment
There was a problem hiding this comment.
LGTM
We tested this manually in the lab and saw no issues. Let's get a few more tests in before merging, but as long as no major regressions, I think we are good to go.
Tests:
- OTA to new version
- OTA out of new version
- Soak tests on all 3 modules
Author
|
Attaching logs for OTA testing (release to test fw and test fw to release) |
nickfritz33
marked this pull request as ready for review
May 5, 2026 22:18
nickfritz33
restored the
nick/G3P-22238/create-unprivileged-task-cmsis-rtos
branch
May 19, 2026 19:19
nickfritz33
deleted the
nick/G3P-22238/create-unprivileged-task-cmsis-rtos
branch
May 19, 2026 19:22
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Context
This work supports G3P-22238, which creates an unprivileged FreeRTOS task on STM32H573 (Cortex-M33 with TrustZone). The CMSIS-RTOS2 wrapper previously had no mechanism to create unprivileged tasks via the `osThreadNew` API — all threads were created privileged regardless of the `osThreadUnprivileged` attribute flag.
Test plan
🤖 Generated with Claude Code