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.

TMS320F28377D: TI C2000 tools ver 22.6.0 LTS problem?

Part Number: TMS320F28377D

I'm compiling the following lines:

volatile Uint32 *gpioDataReg;

.

.

.

gpioDataReg = (volatile Uint32 *)&GpioDataReg + (104/32)*GPY_DATA_OFFSET;

After the above gpioDataReg pointer should be 0x7F18 but it seems like the "plus" is not done and I get the value 0x7F00 (the address of GpioDataReg).

To solve it I split the above to two lines:

gpioDataReg = (volatile Uint32 *)&GpioDataRegs;

gpioDataReg += (104/32)*GPY_DATA_OFFSET;

now it works.

What am I missing here?

  • Hi -- Can you let us know what options you are using to build your code with the 22.6 C2000 compiler? Also if you could follow the directions in this article: How to Submit a Compiler Test Case to submit a reproducible test case, that will make it a lot easier for us to take a look at what is going on.

    Thanks!

  • Compiler_Options.txt
    Fullscreen
    1
    2
    3
    -v28 -ml -mt --cla_support=cla1 --float_support=fpu32 --idiv_support=none --tmu_support=tmu1 --vcu_support=vcu2 --fp_mode=relaxed
    --advice:performance=all --define=CPU1 --define=_FLASH --define=TI_BOARD --define=ATP -g --diag_warning=225 --diag_wrap=off --display_error_number
    --abi=eabi
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    A2D.pp.txtassembly_image.jpg.txt

    Line 22241 in the pp file.

    Compiler version: 22.6.0 LTS

    The jpg shows how it looks in memory after loading the image.

  • Hm, I am seeing the following when I compile your preprocessed test file to assembly:

    ;----------------------------------------------------------------------
    ; 22241 | gpioDataReg = (volatile Uint32 *)&GpioDataRegs + (104/32)*(0x8/2);
    ;----------------------------------------------------------------------
    MOVL XAR4,#||GpioDataRegs||+24 ; [CPU_ARAU] |22241|

    Can you please compile with -s and see if you are seeing this "+24"?

  • Additionally, when I disassemble the object file, I see:

    00000022 $C$L10:
    00000022 1e00 MOVL @0x0, ACC
    00000023 8f00 MOVL XAR4, #0x000018
    00000024 0018

    While there is no value yet for the address of GpioDataRegs because the file is not linked, it clearly added the 24 (hex 18) to its value of 0.

    I didn't see an optimization level in your compiler flags.  Are you compiling with optimization?

  • I also saw the +24 (or +0x18) in disasembly yet what I see in the memory after linker and loading the image is what I send you in the jpg  file (no addition of +24).

    The image run as there was no +0x18 to the GpioDataReg address.

  • and I don't use any optimization...

  • The address would have already been updated to include the 24 by the linker.  Why do you think the address is incorrect?  Where are you seeing the base address of GpioDataRegs?

  • The GpioDataRegs is a TI gpio registers defined in TI file F2837xD_GlobalVariablesDefs.c and its address is 0x7F00.

    When I split the line with += I get the correct result 0x7F18.

  • As there does not seem to be a problem with the code generation from your preprocessed test case, there may be something going wrong in the linker with the computation of the immediate address.  I would need the rest of the files used to link this project.  Is this is a CCS/SDK project?  Or can you provide the remaining object files (I don't need source) to link this?

  • Another possibility to consider ... The linker emits the correct instruction encoding.  After that, something else causes the opcode in the instruction to change to the wrong value.  This is not common, but I've seen it happen.  To investigate this, manually disassemble the final linked .out file created by the linker.  Use a command similar to ...

    Fullscreen
    1
    dis2000 final_executable_file.out > disassembly.txt
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Inspect disassembly.txt.  What do you see at the problem address 0x009d78?  Is it what you expect?

    Thanks and regards,

    -George

  • Not what I expected.

    No addition of 0x18 like you see in the attached jpg I send before.

  • Thank you for your patience.  I created a test case which reproduces the same behavior.  I filed the entry EXT_EP-10948 to have this investigated.  You are welcome to follow it with that link.

    Thanks and regards,

    -George