• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 81 subscribers
  • Views 140 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28384D: Issue with uint16 pointer address calculation in Dram resulting in incorrect 0x80000000

Robert Li
Prodigy 90 points

Part Number: TMS320F28384D

Hello TI Support,

I am encountering an address parsing issue when casting a uint16_t pointer from a volatile union to a uint32_t. The calculated address is unexpectedly 0x00000000 instead of the expected physical RAM offset.

Environment:

  • Compiler: TI v22.6.2.LTS
  • Optimization: Off

Relevant Code:

c
 

//define
typedef union{
    uint16_t DramData[DRAM_Size];
    struct
    {
        uint16_t Debug_CNT;
    };

}Dram_var_Def;

volatile Dram_var_Def    Dram_var;
volatile __uint32_t address;


//Code
    DELAY_US(1);
    //Darm test
    address=(uint32_t) &Dram_var.DramData[0];
    ReadWriteMemoryTest(address,DRAM_Size);

Assembly Dump (from ReadWriteMemoryTest):

 
    0x082B4A    7640C122    LCR          F28x_usDelay
    0x082B4C    761F0260    MOVW         DP, #0x260
    0x082B4E    8F000000    MOVL         XAR4, #0x000000
    0x082B50    A800        MOVL         @0x0, XAR4
    0x082B51    FF2F0200    MOV          ACC, #0x200 << 15
    0x082B53    1E42        MOVL         *-SP[2], ACC
    0x082B54    0600        MOVL         ACC, @0x0
    0x082B55    76482D75    LCR          ReadWriteMemoryTest

Observed Watch Results:

  • address variable content: 0
  • &Dram_var.DramData[0] address: 0x80000000

Question:

Why is the address being resolved to 0? What steps should I take to fix this? 

Thank you.

  • 0
    Prodigy 90 points

    The problem is resolved!

    Solution: I added the __attribute__((far)) attribute to the variable declaration. This explicitly tells the compiler that the variable resides in "far" memory (e.g., external DRAM), ensuring it generates complete 32-bit address calculation instructions.

    Modified Code:

    c
    volatile Dram_var_Def Dram_var __attribute__((far));

    Assembly Dump Comparison (After Solution): Notice the changes in the generated assembly code, particularly in the MOV instructions for setting up the address (lines 0x082B4C - 0x082B4E):

    assembly
    0x082B47 76482A51    LCR          emif1_dram_config
    0x082B49 0226        MOVB         ACC, #38
    0x082B4A 7640C122    LCR          F28x_usDelay
    0x082B4C 28A90000    MOV          @AL, #0x0000   <-- Generates 32-bit address handling 0x082B4E
    0x082B4E 28A88000    MOV          @AH, #0x8000   <-- Generates 32-bit address handling 0x082B50
    0x082B50 761F0260    MOVW         DP, #0x260
    0x082B52 1E00        MOVL         @0x0, ACC
    0x082B53 FF2F0200    MOV          ACC, #0x200 << 15
    0x082B55 1E42        MOVL         *-SP[2], ACC
    0x082B56 0600        MOVL         ACC, @0x0
    0x082B57 76482D77    LCR          ReadWriteMemoryTest

    Thank you all for your help and guidance!