# MicroBlaze compilation error when upgrading to FreeRTOS v11.3.0 **URL:** \ **Category:** Xilinx\ **Created:** [May 11, 2026, 11:23am UTC](https://forums.freertos.org/t/microblaze-compilation-error-when-upgrading-to-freertos-v11-3-0/24994 "2026-05-11T11:23:30Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![fyilmaz](https://avatars.discourse-cdn.com/v4/letter/f/b9bd4f/32.png) [@fyilmaz](https://forums.freertos.org/u/fyilmaz)\ **Post date:** [May 11, 2026, 11:23am UTC](https://forums.freertos.org/t/microblaze-compilation-error-when-upgrading-to-freertos-v11-3-0/24994/1 "2026-05-11T11:23:30Z")
Hello, I am upgrading to FreeRTOS Kernel v11.3.0 on MicroBlazeV9 and I get build errors in `portasm.S`: - `portSLR_OFFSET` undefined - `portSHR_OFFSET` undefined My design uses MicroBlaze Hardware Stack Protection (`XPAR_MICROBLAZE_USE_STACK_PROTECTION` is enabled in bsp). The port assembly still saves/restores `rslr` and `rshr`, but the required stack frame offsets (`portSLR_OFFSET`, `portSHR_OFFSET`) are missing in the current FreeRTOS v11.3.0 port. It appears these definitions existed in older FreeRTOS versions but were removed or changed around commit `5040a67`. According to MicroBlaze document, it provides SLR/SHR registers when stack protection is enabled, so the hardware feature itself is supported. #if( XPAR\_MICROBLAZE\_USE\_STACK\_PROTECTION ) /\* Restore the stack limits – must not load from r1 (Stack Pointer) because if the address of load or store instruction is out of range, it will trigger Stack Protection Violation exception. \*/ or r18, r0, r1 lwi r12, r18, portSLR\_OFFSET mts rslr, r12 lwi r12, r18, portSHR\_OFFSET mts rshr, r12 #endif I am trying to understand Where are `portSLR_OFFSET` and `portSHR_OFFSET` supposed to be defined in the FreeRTOS v11.3.0 MicroBlaze port—are they expected to come from the BSP, FreeRTOS port layer, or Xilinx/MicroBlaze headers? Was their removal intentional in newer releases, and what is the correct replacement approach? Have a good day. ---
**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\ **Post date:** [May 12, 2026, 7:09am UTC](https://forums.freertos.org/t/microblaze-compilation-error-when-upgrading-to-freertos-v11-3-0/24994/2 "2026-05-12T07:09:34Z")
This was removed in this PR - [Sync up MicroblazeV9 port with Xilinx tree by mubinsyed · Pull Request #220 · FreeRTOS/FreeRTOS-Kernel · GitHub](https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/220). The upstream port does not store/restore stack limit registers which is likely the reason for removal: [embeddedsw/ThirdParty/bsp/freertos10\_xilinx/src/Source/portable/GCC/MicroBlazeV9/portasm.S at master · Xilinx/embeddedsw · GitHub](https://github.com/Xilinx/embeddedsw/blob/master/ThirdParty/bsp/freertos10_xilinx/src/Source/portable/GCC/MicroBlazeV9/portasm.S). Do you want to restore this block and see if it works for you - [Blaming FreeRTOS-Kernel/portable/GCC/MicroBlazeV9/portasm.S at V11.0.1 · FreeRTOS/FreeRTOS-Kernel · GitHub](https://github.com/FreeRTOS/FreeRTOS-Kernel/blame/V11.0.1/portable/GCC/MicroBlazeV9/portasm.S#L70-L93)? ---
**Author:** ![fyilmaz](https://avatars.discourse-cdn.com/v4/letter/f/b9bd4f/32.png) [@fyilmaz](https://forums.freertos.org/u/fyilmaz)\ **Post date:** [May 12, 2026, 8:47am UTC](https://forums.freertos.org/t/microblaze-compilation-error-when-upgrading-to-freertos-v11-3-0/24994/3 "2026-05-12T08:47:08Z")
Hi Gaurav, Yes, I restored the block and the definitions as you suggested, and it worked. After restoring the code, I initially hit a `stack protection violation` exception when the `_STACK_SIZE` was set to `0x100`. Since the context frame grew after adding the SLR/SHR registers, it was overflowing the ISR stack. Increasing the `_STACK_SIZE` to `0x1000` resolved the issue and the system is now stable. Given that the assembly logic for stack protection is still present in `portasm.S`, shouldn’t these definitions be officially re-added to the port? If not, shouldn’t they be completely removed? Leaving the assembly logic in place while removing the necessary offsets seems to create an incomplete state for users who enable hardware stack protection in their BSP. Thanks. ---
**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\ **Post date:** [May 12, 2026, 9:47am UTC](https://forums.freertos.org/t/microblaze-compilation-error-when-upgrading-to-freertos-v11-3-0/24994/4 "2026-05-12T09:47:10Z")
> [@fyilmaz](#): > > Given that the assembly logic for stack protection is still present in `portasm.S`, shouldn’t these definitions be officially re-added to the port? If not, shouldn’t they be completely removed? The stack overflow detection in hardware is a useful feature and IMO, we should use it when it is available on the hardware. Therefore, I am in favor of restoring these #defines. Would you please raise a PR for this change?