Stack Frame offsets listed in readme_threadx.txt do not match actual offsets in memory.

Ryan 0 Reputation points
2023-03-30T13:51:28.36+00:00
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 

enter image description here

Azure RTOS
Azure RTOS
An Azure embedded development suite including a small but powerful operating system for resource-constrained devices.
326 questions
{count} votes

2 answers

Sort by: Most helpful
  1. Scott Azure RTOS 4,051 Reputation points
    2023-03-31T15:32:36.69+00:00

    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?


  2. Scott Azure RTOS 4,051 Reputation points
    2023-04-04T17:58:41.8366667+00:00

    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?