Hi Ryan,
I'm not sure I understand your question. The contents of register R11 (FP) are saved at offset 0x34 or 0x24, but ThreadX does not care what those contents are. Are you seeing problems at runtime?
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
From the cortex-a9 readme_threadx.txt. When getting the tx_thread_stack_ptr I expect the frame pointer to
be at offset 0x34 or 0x24 from that address. However the offset to the frame pointer for the current
thread is actually 0x19C based on the value of the R11 register. This offset seems consistent when
checking the thread at tx_thread_ready_next as well. However when going to tx_thread_ready_next from that
thread, or tx_thread_created_next/tx_thread_created_prev from the original thread, that offset no longer
points to the frame pointer, in addition to 0x34/0x24 not pointing to the frame pointer. We do have VFP
register support enabled, but I do not see any documentation indicating that would affect the strack
frame. What is the actual correct way to determine the frame pointer location relative to
tx_thread_stack_ptr as the below offsets in the documentation are not valid. Thanks.
Offset Interrupted Stack Frame Non-Interrupt Stack Frame
0x00 1 0
0x04 CPSR CPSR
0x08 r0 (a1) r4 (v1)
0x0C r1 (a2) r5 (v2)
0x10 r2 (a3) r6 (v3)
0x14 r3 (a4) r7 (v4)
0x18 r4 (v1) r8 (v5)
0x1C r5 (v2) r9 (v6)
0x20 r6 (v3) r10 (v7)
0x24 r7 (v4) r11 (fp)
0x28 r8 (v5) r14 (lr)
0x2C r9 (v6)
0x30 r10 (v7)
0x34 r11 (fp)
0x38 r12 (ip)
0x3C r14 (lr)
0x40 PC
Hi Ryan,
I'm not sure I understand your question. The contents of register R11 (FP) are saved at offset 0x34 or 0x24, but ThreadX does not care what those contents are. Are you seeing problems at runtime?
Hi Ryan, another thing I just thought of - do you have TX_ENABLE_VFP_SUPPORT defined? If so, the VFP registers will be saved above the GP registers, so the thread stack will have the VFP registers between the CPSR and R0 (for interrupt stack) or R4 (for non-interrupted stack).
If you don't have VFP enabled, can you step through the code that does the context saving (https://github.com/azure-rtos/threadx/blob/master/ports/cortex_a9/gnu/src/tx_thread_system_return.S) and see where your frame pointer is actually being saved in the thread stack?