Jump to content
Forum sending old emails Read more... ×

Search the Community

Showing results for tags 'blinky'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • News
    • Announcements
    • Suggestions
    • New users say Hi!
  • Spotlight!
    • Sponsor Spotlight
    • Sponsor Giveaways
  • Energia
    • Energia - MSP
    • Energia - TivaC/CC3XXX
    • Energia - C2000
    • Energia Libraries
  • MSP Technical Forums
    • General
    • Compilers and IDEs
    • Development Kits
    • Programmers and Debuggers
    • Code vault
    • Projects
    • Booster Packs
    • Energia
  • Tiva-C, Hercules, CCXXXX ARM Technical Forums
    • General
    • SensorTag
    • Tiva-C, Hercules, CC3XXX Launchpad Booster Packs
    • Code Vault
    • Projects
    • Compilers and IDEs
    • Development Kits and Custom Boards
  • Beagle ARM Cortex A8 Technical Forums
    • General
    • Code Snippets and Scripts
    • Cases, Capes and Plugin Boards
    • Projects
  • General Electronics Forum
    • General Electronics
    • Other Microcontrollers
  • Connect
    • Embedded Systems/Test Equipment Deals
    • Buy, Trade and Sell
    • The 43oh Store
    • Community Projects
    • Fireside Chat
  • C2000 Technical Forums
    • General
    • Development Kits
    • Code Vault
    • Projects
    • BoosterPacks

Calendars

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Location


Interests


Sparkfun


Github

Found 1 result

  1. 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?
×