FAQs
English (US) 日本語 | Japanese 中文 | Chinese (Simplified)

Codewarrior debugger assembly code different from codewarrior compiler assembly code

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Codewarrior debugger assembly code different from codewarrior compiler assembly code

‎05-07-2010 04:51 PM
979 Views
RxScram
Contributor I

I am having a problem where the listing file that is generated at compile time (which is correct) is different from the mixed view disassembly that I see while debugging.  Unfortunately, the version I see during debugging is buggy.  I have global optimizations turned off, and am using Codewarrior 7.1.2. 

 

Original source code

 

TJ_MAINON_IN is mapped to MCF_GPIO_PORTTJ_PORTTJ4

TJ_AUXON_IN is mapped to MCF_GPIO_PORTTJ_PORTTJ3

TJ_LINEON_IN is mapped to MCF_GPIO_PORTTJ_PORTTJ5

 

 

// ON signals
if (!(MCF_GPIO_SETTJ & TJ_MAINON_IN))          result |= gHAL_DI_MAIN_ON;
if (!(MCF_GPIO_SETTJ & TJ_AUXON_IN))           result |= gHAL_DI_AUX_ON;
if (!(MCF_GPIO_SETTJ & TJ_LINEON_IN))          result |= gHAL_DI_LINE_ON;

 

 

Listing generated from Codewarrior compiler.  This is correct

 

 

;   72:  if (!(MCF_GPIO_SETTJ & TJ_MAINON_IN))               
;
0x0000007C  0x7000                   moveq    #0,d0
0x0000007E  0x103940100036           move.b   0x40100036,d0
0x00000084  0x08000004               btst     #4,d0
0x00000088  0x660E                   bne.s    *+16                  ; 0x00000098
;
;   72:                              result |= gHAL_DI_MAIN_ON;
;
0x0000008A  0x7000                   moveq    #0,d0
0x0000008C  0x302EFFFC               move.w   -4(a6),d0
0x00000090  0x08C00004               bset     #4,d0
0x00000094  0x3D40FFFC               move.w   d0,-4(a6)
;
;   73:  if (!(MCF_GPIO_SETTJ & TJ_AUXON_IN))                
;
0x00000098  0x7000                   moveq    #0,d0
0x0000009A  0x103940100036           move.b   0x40100036,d0
0x000000A0  0x08000003               btst     #3,d0
0x000000A4  0x660E                   bne.s    *+16                  ; 0x000000b4
;
;   73:                                       result |= gHAL_DI_AUX_ON;
;
0x000000A6  0x7000                   moveq    #0,d0
0x000000A8  0x302EFFFC               move.w   -4(a6),d0
0x000000AC  0x08C00005               bset     #5,d0
0x000000B0  0x3D40FFFC               move.w   d0,-4(a6)
;
;   74:  if (!(MCF_GPIO_SETTJ & TJ_LINEON_IN))               
;
0x000000B4  0x7000                   moveq    #0,d0
0x000000B6  0x103940100036           move.b   0x40100036,d0
0x000000BC  0x08000005               btst     #5,d0
0x000000C0  0x660E                   bne.s    *+16                  ; 0x000000d0
;
;   74:                                      result |= gHAL_DI_LINE_ON;
;
0x000000C2  0x7000                   moveq    #0,d0
0x000000C4  0x302EFFFC               move.w   -4(a6),d0
0x000000C8  0x08C00006               bset     #6,d0
0x000000CC  0x3D40FFFC               move.w   d0,-4(a6)

 

 

Mixed output from Codewarrior Debugger.  The code for the first two sections is correct, but the code for the TJ_LINEON_IN section is not. 

 

Please note how it does a btst #6,d0, instead of a btst #5,d0 as it does above.

 

 

 // ON signals
 if (!(MCF_GPIO_SETTJ & TJ_MAINON_IN))                result |= gHAL_DI_MAIN_ON;
00003816: 7000            moveq    #0,d0
00003818: 103940100036    move.b   0x40100036 (0x40100036),d0
0000381E: 08000004        btst     #4,d0
00003822: 660E            bne.s    gHAL_DI_read_all+0x98 (0x3832); 0x00003832
00003824: 7000            moveq    #0,d0
00003826: 302EFFFC        move.w   -4(a6),d0
0000382A: 08C00004        bset     #4,d0
0000382E: 3D40FFFC        move.w   d0,-4(a6)
 if (!(MCF_GPIO_SETTJ & TJ_AUXON_IN))                 result |= gHAL_DI_AUX_ON;
00003832: 7000            moveq    #0,d0
00003834: 103940100036    move.b   0x40100036 (0x40100036),d0
0000383A: 08000003        btst     #3,d0
0000383E: 660E            bne.s    gHAL_DI_read_all+0xb4 (0x384e); 0x0000384e
00003840: 7000            moveq    #0,d0
00003842: 302EFFFC        move.w   -4(a6),d0
00003846: 08C00005        bset     #5,d0
0000384A: 3D40FFFC        move.w   d0,-4(a6)
 if (!(MCF_GPIO_SETTJ & TJ_LINEON_IN))                result |= gHAL_DI_LINE_ON;
0000384E: 7000            moveq    #0,d0
00003850: 103940100036    move.b   0x40100036 (0x40100036),d0
00003856: 08000006        btst     #6,d0
0000385A: 660E            bne.s    gHAL_DI_read_all+0xd0 (0x386a); 0x0000386a
0000385C: 7000            moveq    #0,d0
0000385E: 302EFFFC        move.w   -4(a6),d0
00003862: 08C00006        bset     #6,d0
00003866: 3D40FFFC        move.w   d0,-4(a6)

 

Finally, I did an experiment where I tried using explicit pin definitions.  Since the first two sections are correct, I have removed them for clarity.  I tried using all 4 of the upper bits for port TJ, but each time the debugger disassembly showed it using pin 6, instead of the desired pin.

 

 

 

 if (!(MCF_GPIO_SETTJ & 0x20) )                       result |= gHAL_DI_LINE_ON;
0000384E: 7000            moveq    #0,d0
00003850: 103940100036    move.b   0x40100036 (0x40100036),d0
00003856: 08000006        btst     #6,d0
0000385A: 660E            bne.s    gHAL_DI_read_all+0xd0 (0x386a); 0x0000386a
0000385C: 7000            moveq    #0,d0
0000385E: 302EFFFC        move.w   -4(a6),d0
00003862: 08C00006        bset     #6,d0
00003866: 3D40FFFC        move.w   d0,-4(a6)

 if (!(MCF_GPIO_SETTJ & 0x10) )                       result |= gHAL_DI_LINE_ON;
0000384E: 7000            moveq    #0,d0
00003850: 103940100036    move.b   0x40100036 (0x40100036),d0
00003856: 08000006        btst     #6,d0
0000385A: 660E            bne.s    gHAL_DI_read_all+0xd0 (0x386a); 0x0000386a
0000385C: 7000            moveq    #0,d0
0000385E: 302EFFFC        move.w   -4(a6),d0
00003862: 08C00006        bset     #6,d0
00003866: 3D40FFFC        move.w   d0,-4(a6)


 if (!(MCF_GPIO_SETTJ & 0x80) )                       result |= gHAL_DI_LINE_ON;
0000384E: 7000            moveq    #0,d0
00003850: 103940100036    move.b   0x40100036 (0x40100036),d0
00003856: 08000006        btst     #6,d0
0000385A: 660E            bne.s    gHAL_DI_read_all+0xd0 (0x386a); 0x0000386a
0000385C: 7000            moveq    #0,d0
0000385E: 302EFFFC        move.w   -4(a6),d0
00003862: 08C00006        bset     #6,d0
00003866: 3D40FFFC        move.w   d0,-4(a6)


 if (!(MCF_GPIO_SETTJ & 0x40) )                       result |= gHAL_DI_LINE_ON;
0000384E: 7000            moveq    #0,d0
00003850: 103940100036    move.b   0x40100036 (0x40100036),d0
00003856: 08000006        btst     #6,d0
0000385A: 660E            bne.s    gHAL_DI_read_all+0xd0 (0x386a); 0x0000386a
0000385C: 7000            moveq    #0,d0
0000385E: 302EFFFC        move.w   -4(a6),d0
00003862: 08C00006        bset     #6,d0
00003866: 3D40FFFC        move.w   d0,-4(a6)

 

 

I have submitted an official help request, but I thought I would ask here too to see if anybody had any ideas.

 

Thank you.

Labels (1)
Labels
0 Kudos
Reply
1 Reply

‎05-08-2010 08:56 AM
538 Views
ipa
Contributor III

Hi,

I had similar problems with the compiler/linker for other micros from Freescale. It seems that their tools would like to be more smart than you when they see similar statements on many successive lines. My workaround to these problems was to break out the thinking chain of the tools by inserting a small dummy function between such successive lines. Hope this will help also in your case.

Regards,

Ipa

0 Kudos
Reply