Quantcast
Channel: MSP430 Technical Forums
Viewing all articles
Browse latest Browse all 2077

Analyzing blinky's disassembly

$
0
0

Hello everyone,

 

I disassembled the following code:

 

#include <msp430.h>


#define RED BIT0
#define GREEN BIT6


int main(int argc, const char *argv[])
{
        WDTCTL = WDTPW + WDTHOLD;
        P1DIR = BIT6 | BIT0;
        while (1) {
                P1OUT = BIT6;
                __delay_cycles(500000);
                P1OUT ^= (BIT6 | BIT0);
                __delay_cycles(500000);
        }
        return 0;
}

On running msp430-objdump -D hello_world.elf, I got:

Disassembly of section .text:

0000c000 <__watchdog_support>:
    c000:	55 42 20 01 	mov.b	&0x0120,r5	//0x120 is WDTCTL
    c004:	35 d0 08 5a 	bis	#23048,	r5	;#0x5a08 //Supposed to be WDTPW + WDTHOLD
    c008:	82 45 00 02 	mov	r5,	&0x0200	 // copying to RAM

0000c00c <__init_stack>:
    c00c:	31 40 00 04 	mov	#1024,	r1	;#0x0400

0000c010 <__do_copy_data>:
    c010:	3f 40 00 00 	mov	#0,	r15	;#0x0000
    c014:	0f 93       	tst	r15		
    c016:	08 24       	jz	$+18     	;abs 0xc028 
    c018:	92 42 00 02 	mov	&0x0200,&0x0120	
    c01c:	20 01 
    c01e:	2f 83       	decd	r15		
    c020:	9f 4f 88 c0 	mov	-16248(r15),512(r15);0xc088(r15), 0x0200(r15)
    c024:	00 02 
    c026:	f8 23       	jnz	$-14     	;abs 0xc018

0000c028 <__do_clear_bss>:
    c028:	3f 40 00 00 	mov	#0,	r15	;#0x0000
    c02c:	0f 93       	tst	r15		
    c02e:	07 24       	jz	$+16     	;abs 0xc03e
    c030:	92 42 00 02 	mov	&0x0200,&0x0120	
    c034:	20 01 
    c036:	1f 83       	dec	r15		
    c038:	cf 43 00 02 	mov.b	#0,	512(r15);r3 As==00, 0x0200(r15)
    c03c:	f9 23       	jnz	$-12     	;abs 0xc030

0000c03e <main>:
    c03e:	b2 40 80 5a 	mov	#23168,	&0x0120	;#0x5a80
    c042:	20 01 
    c044:	f2 40 41 00 	mov.b	#65,	&0x0022	;#0x0041
    c048:	22 00 
    c04a:	f2 40 40 00 	mov.b	#64,	&0x0021	;#0x0040
    c04e:	21 00 
    c050:	3e 40 03 00 	mov	#3,	r14	;#0x0003
    c054:	3f 40 06 8b 	mov	#-29946,r15	;#0x8b06
    c058:	1f 83       	dec	r15		
    c05a:	fe 23       	jnz	$-2      	;abs 0xc058
    c05c:	1e 83       	dec	r14		
    c05e:	fc 23       	jnz	$-6      	;abs 0xc058
    c060:	03 43       	nop			
    c062:	f2 e0 41 00 	xor.b	#65,	&0x0021	;#0x0041
    c066:	21 00 
    c068:	3e 40 03 00 	mov	#3,	r14	;#0x0003
    c06c:	3f 40 06 8b 	mov	#-29946,r15	;#0x8b06
    c070:	1f 83       	dec	r15		
    c072:	fe 23       	jnz	$-2      	;abs 0xc070
    c074:	1e 83       	dec	r14		
    c076:	fc 23       	jnz	$-6      	;abs 0xc070
    c078:	03 43       	nop			
    c07a:	e7 3f       	jmp	$-48     	;abs 0xc04a

0000c07c <__stop_progExec__>:
    c07c:	32 d0 f0 00 	bis	#240,	r2	;#0x00f0
    c080:	fd 3f       	jmp	$-4      	;abs 0xc07c

0000c082 <__ctors_end>:
    c082:	30 40 86 c0 	br	#0xc086	

0000c086 <_unexpected_>:
    c086:	00 13       	reti			

Disassembly of section .noinit:

00000200 <__wdt_clear_value>:
	...

Disassembly of section .vectors:

0000ffe0 <__ivtbl_16>:
    ffe0:	82 c0 82 c0 	bic	r0,	&0xc082	
    ffe4:	82 c0 82 c0 	bic	r0,	&0xc082	
    ffe8:	82 c0 82 c0 	bic	r0,	&0xc082	
    ffec:	82 c0 82 c0 	bic	r0,	&0xc082	
    fff0:	82 c0 82 c0 	bic	r0,	&0xc082	
    fff4:	82 c0 82 c0 	bic	r0,	&0xc082	
    fff8:	82 c0 82 c0 	bic	r0,	&0xc082	
    fffc:	82 c0 00 c0 	bic	r0,	&0xc000

My questions are:

 

1) In <__watchdog_support>

c000:    55 42 20 01     mov.b    &0x0120,r5    //0x120 is WDTCTL
c004:    35 d0 08 5a     bis    #23048,    r5    ;#0x5a08 //Supposed to be WDTPW + WDTHOLD
c008:    82 45 00 02     mov    r5,    &0x0200     // copying to RAM

The second line - WDTHOLD is the 8th bit in WDTCTL. So shouldnt it be 0x5a80 ? Why is it 0x5a08 ?

Why copy the modified content to RAM ? Why not directly write to WDTCTL register?

 

But later in main:

c03e:    b2 40 80 5a     mov    #23168,    &0x0120    ;#0x5a80

Now this seems consistent. So why is that "watchdog support" section even there?

 

 

2) In section <__do_copy_data>

   

c010:    3f 40 00 00     mov    #0,    r15    ;#0x0000
c014:    0f 93     tst    r15        
c016:    08 24     jz    $+18     ;abs 0xc028 

When #0 is explicitly moved to r15, after tst, its pretty obvious that jz will be evaluate to true. Then why not unconditionally jump to 0xc028 ?

 

If thats the case, what about the code just below jz? that is *dead* code, right?


Viewing all articles
Browse latest Browse all 2077

Trending Articles