MicroBlaze compilation error when upgrading to FreeRTOS v11.3.0

Partners & Sponsors Xilinx
1

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.

2

This was removed in this PR - Sync up MicroblazeV9 port with Xilinx tree by mubinsyed · Pull Request #220 · FreeRTOS/FreeRTOS-Kernel · GitHub.

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.

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?

3

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.

4

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?