rtos/FreeRTOS: support ARMv8-M (Cortex-M33) stacking#151
Open
anujdeshpande wants to merge 2 commits into
Open
Conversation
ARMv8-M FreeRTOS ports (e.g. the RP2350_ARM_NTZ port used on the
RP2350's Cortex-M33) save a different software frame than the classic
Cortex-M3/M4F ports the existing stackings assume. From the saved
pxTopOfStack the layout is:
0x00 PSPLIM
0x04 EXC_RETURN (software-saved LR)
0x08 R4 .. 0x24 R11
(0x28 S16..S31, only when the task used the FPU - extended frame)
<hardware frame: R0..R3, R12, LR, PC, xPSR (+ S0..S15, FPSCR)>
i.e. two extra leading words (PSPLIM, EXC_RETURN) and R4-R11 follow
EXC_RETURN instead of preceding it, so every register offset differs
from rtos_standard_cortex_m4f*. Add rtos_standard_cortex_m33_stacking
(basic frame) and rtos_standard_cortex_m33_fpu_stacking (extended FPU
frame) with the correct offsets and xPSR-based stack alignment.
Signed-off-by: Anuj Deshpande <anuj@makerville.io>
On ARMv8-M targets (Cortex-M33/M23) handle stack reconstruction before the existing armv7m FPU probe and choose the extended (FPU) vs basic layout from bit 4 of the software-saved EXC_RETURN at offset 0x04, which these ports always stack. This must not be gated on the cm4_fpu_enabled detection (fp_feature + CPACR): that probe does not reliably report the FPU on ARMv8-M cores, so relying on it silently reconstructed every FPU-extended-frame task with the basic layout, yielding pc=lr=xpsr=0 and a garbage call stack, while basic-frame tasks looked fine. Tested on an RP2350 (RP2350_ARM_NTZ port) with a CMSIS-DAP probe: all FreeRTOS tasks - both basic and FPU-extended frames - now produce correct backtraces via "thread apply all bt". Signed-off-by: Anuj Deshpande <anuj@makerville.io>
3ecf93d to
bd4179d
Compare
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
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.
Problem
info threads/ per-task backtraces are garbage when debugging FreeRTOS on ARMv8-M targets (e.g. RP2350 Cortex-M33,RP2350_ARM_NTZport). OpenOCD's FreeRTOS support only knows the classic Cortex-M3/M4F stack layouts.Originally reported downstream against the Flipper One MCU firmware: flipperdevices/flipperone-mcu-firmware#51
Two distinct issues:
Wrong stack layout. ARMv8-M ports save an extra
PSPLIM+EXC_RETURNahead of R4–R11 (and R4–R11 followEXC_RETURNrather than preceding it), so every register offset differs fromrtos_standard_cortex_m4f*. From the savedpxTopOfStack:Wrong frame-type selection. The
cm4_fpu_enabledprobe (fp_feature+ CPACR) does not reliably report the FPU on ARMv8-M cores, so the basic layout was applied to every task — FPU-extended-frame tasks reconstructed aspc=lr=xpsr=0, while basic-frame tasks happened to look fine.Fix
rtos_standard_cortex_m33_stacking(basic) andrtos_standard_cortex_m33_fpu_stacking(extended FPU frame) with correct offsets.freertos.c, handle ARMv8-M first and pick FPU vs basic purely from bit 4 of the software-savedEXC_RETURNat offset 0x04 (which these ports always stack), independent of the unreliable FPU detection.Testing
Tested on an RP2350 (Cortex-M33, FPU enabled) running a FreeRTOS application built with the
RP2350_ARM_NTZport, debugged over a CMSIS-DAP probe with-rtos FreeRTOS:pc=lr=xpsr=0(e.g. a task whose real PC was at frame offset0x80was instead read from0x40); tasks with a basic frame happened to decode correctly.thread apply all bt.Builds with
--enable-cmsis-dap-v2.