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.

CCSv3 vs CCSv5 CortexM3 Disassembly - More Detail

This appears to be an endianess issue in how the disassembler accesses memory.  Is there a workaround or other fix?

CCSv3

Disassembly

00002500 00ABF06F MVN.W           R0, #171
00002504 6800     LDR             R0, [R0]
00002506 0F01F010 TST.W           R0, #1
0000250A D007     BEQ             0x0000251C
0000250C 0073F06F MVN.W           R0, #115
00002510 6801     LDR             R1, [R0]
00002512 7180F041 ORR.W           R1, R1, #16777216
00002516 7100F021 BIC.W           R1, R1, #33554432
0000251A 6001     STR             R1, [R0]
0000251C BD24F7FE B.W             0x00000F68

Memory Image
0x00002500    0xF06F00AB    0x6800F010
0x00002508    0x0F01D007    0xF06F0073
0x00002510    0x6801F041    0x7180F021
0x00002518    0x71006001    0xF7FEBD24

CCSv5

Disassembly

00002500:   6FF0     LDR             R0, [R6, #0x7C]
00002502:   AB00     ADD             R3, SP, #0x0
00002504:   0068     LSL             R0, R5, #0x1
00002506:   10F0     ASR             R0, R6, #0x3
00002508:   010F     LSL             R7, R1, #0x4
0000250a:   07D0     LSL             R0, R2, #0x1F
0000250c:   6FF0     LDR             R0, [R6, #0x7C]
0000250e:   7300     STRB            R0, [R0, #0xC]
00002510:   0168     LSL             R0, R5, #0x5
00002512:   41F0     ROR             R0, R6
00002514:   8071     STRH            R1, [R6, #0x2]
00002516:   21F0     MOV             R1, #0xF0
00002518:   0071     LSL             R1, R6, #0x1
0000251a:   0160     LSL             R0, R4, #0x5
0000251c:   FEF724BD MRC2.W          P4, #7, R2, C7, C13, #5

Memory Image
0x00002500 F06F00AB    6800F010
0x00002500 0F01D007    F06F0073
0x00002500 6801F041    7180F021
0x00002500 71006001    F7FEBD24

  • Are you loading the executable on to a simulator or a Cortex M3 device? If device, which specific device?
    And are you using CCS v5.2.0.00069?

    The reason I ask if you are using a simulator is because there is one known issue where the Cortex R4 Functional Simulator BE32 shows incorrect instructions in the disassembly view due to incorrect endianness. But since you mention Cortex M3 it may not be the exact same issue, but could be a different bug.

    Can you provide the .out file that generates this disassembly in CCSv3 and CCSv5 so we can recreate and investigate the issue? And can you also confirm what build options were used when generating the .out file (specifically the target option (-mv7M3) and endianness option)?

     

  • I am using CCS v5.2.00068.  SImulator and emulator yield the same result.  Execution as well as memory dumps and disassembly.  Using a generic Cortex M3 as a starting point an assembly code project was used to initialize the debugger.  A configuration file was generated to target the specific device.  As far as how the code image was generated.  It comes as part of the code image of a return.  I do not have the source.  Nor is it guaranteed to have been generated using TI tools at all.  It would be possible to create a code snippet based on the disassembly or simply use .long constants to load the memory image. Let me try a few more things. 

       Was there a workaround for the Cortex R4 problem?

       

  • H G Hopkins said:
    Was there a workaround for the Cortex R4 problem?

    I don't see any workaround listed in the bug report. You may also view the bug report using the SDOWP link in my signature and entering the bug # SDSCM00042185.

    If you are able to provide a code snippet or executable file that we can load/disassemble that would be great, and would help reproduce this issue and investigate further.