• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 233 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.

AWR2944: CLANG TI Compiler branch to the wrong addresses

Andrew Rofaiel
Prodigy 130 points
Part Number: AWR2944

Hello Experts,

I have a problem where function calls is not happening properly. 
Let's say we have func1 calling func2 in code but in assembly I find that branch instruction bl or b is jumping to random address in the middle of third function.

I confirmed the issue by looking at disassembly and map file addresses.

As expected, this is making the complete SW unstable.

Board -> AWR2944EVM and Compiler is CLANG TI latest LTS version.

Linker options

-Xlinker -qq \
-Xlinker --unused_section_elimination=on \
-Xlinker --diag_suppress=10063-D \
-Xlinker --diag_suppress=10068-D \
-Xlinker --diag_suppress=10247-D \
-Xlinker --reread_libs \
-Xlinker --compress_dwarf=on \
-Xlinker --copy_compression=rle \
-Xlinker -a \
-Xlinker --rom_model \

BR,
Andrew

  • 0
    TI__Guru**** 249900 points
    Andrew Rofaiel said:
    I confirmed the issue by looking at disassembly and map file addresses.

    I presume you used the disassembler built into the debugger.

    Please use the command line disassembler that comes with the compiler.  It is named tiarmdis, and is located in the same \bin directory as the compiler tiarmclang.  Run a command similar to ...

    tiarmdis executable_file.out > dis.txt

    Where executable_file.out is the name of the executable file created by the linker.  The disassembly is written to the text file dis.txt.  Compare this to the disassembly you see in the debugger.  Is it the same?  If it is different, then something went wrong after the executable file is created.  Perhaps when it is loaded or flashed.  Or maybe some bug causes memory where these instructions reside to be over-written. Or something similar.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 130 points

    Thanks alot George, that is a nice hint and I will use it next time.
    I actually did it in different way, I opened the hex file generated from linker and compared to what's in the debugger and I also used online hex to ARM assembly which showed me the same instruction as the debugger.

    The issue is solved now and It was really relevant to linker options.

    Thanks again,
    Andrew