Re: [avr-gcc-list] Setting pin to high in function instead of main, instructions in main never run?

[Richard Zetterberg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I forgot to add the disassembly after adding mmcu to linking.

Here's what it looks like now:

- --- --- Disassembly being --- ---


example.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000090  00000000  00000000  00000054  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .stab         000006cc  00000000  00000000  000000e4  2**2
                  CONTENTS, READONLY, DEBUGGING
  2 .stabstr      00000081  00000000  00000000  000007b0  2**0
                  CONTENTS, READONLY, DEBUGGING

Disassembly of section .text:

00000000 <__vectors>:
   0:   0c 94 34 00     jmp     0x68    ; 0x68 <__ctors_end>
   4:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
   8:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
   c:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  10:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  14:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  18:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  1c:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  20:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  24:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  28:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  2c:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  30:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  34:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  38:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  3c:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  40:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  44:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  48:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  4c:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  50:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  54:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  58:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  5c:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  60:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>
  64:   0c 94 3e 00     jmp     0x7c    ; 0x7c <__bad_interrupt>

00000068 <__ctors_end>:
  68:   11 24           eor     r1, r1
  6a:   1f be           out     0x3f, r1        ; 63
  6c:   cf ef           ldi     r28, 0xFF       ; 255
  6e:   d8 e0           ldi     r29, 0x08       ; 8
  70:   de bf           out     0x3e, r29       ; 62
  72:   cd bf           out     0x3d, r28       ; 61
  74:   0e 94 42 00     call    0x84    ; 0x84 <main>
  78:   0c 94 46 00     jmp     0x8c    ; 0x8c <_exit>

0000007c <__bad_interrupt>:
  7c:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>

00000080 <turn_on_pb>:
        return 0;
}

void turn_on_pb(void)
{
        PORTB |= (1 << PB0);
  80:   28 9a           sbi     0x05, 0 ; 5
}
  82:   08 95           ret

00000084 <main>:

void turn_on_pb(void);

int main(void)
{
        DDRB |= (1 << PB0);
  84:   20 9a           sbi     0x04, 0 ; 4
        turn_on_pb();
  86:   0e 94 40 00     call    0x80    ; 0x80 <turn_on_pb>
  8a:   ff cf           rjmp    .-2             ; 0x8a <main+0x6>

0000008c <_exit>:
  8c:   f8 94           cli

0000008e <__stop_program>:
  8e:   ff cf           rjmp    .-2             ; 0x8e <__stop_program>


- --- --- Disassembly end --- ---

On 3/1/12 4:00 PM, Richard Zetterberg wrote:
> Thanks for the input Georg-Johann and Johannes.
> 
> Georg-Johann: I double checked the fuses and the watchdog is not
> active.
> 
> Johannes: I'm not sure how I would go about doing that. But I just 
> read a document called "Getting started with GCC for AVR32" and
> found the following:
> 
> "The linking process needs information about code and data memory 
> location. Using a linker script provides this. If specifying which 
> device you are compiling code for by using the ?-mpart=<part>?
> option in avr32-gcc, a default linker script for that device will
> be used."
> 
> That got me thinking, maybe that's the problem, that I don't
> provide the mmcu when linking. So I changed this line in the
> makefile:
> 
> elf: avr-gcc example.o -o example.elf
> 
> To this:
> 
> elf: avr-gcc -mmcu=atmega328 example.o -o example.elf
> 
> 
> And after I compiled, linked, hexed and upload the problem was no 
> longer present.
> 
> With my no-existing experience I conclude that's the source of the 
> problem, and thus the problem is solved.
> 
> Does that make sense or is that just a coincidence that it is now 
> working?
> 
> On 3/1/12 3:30 PM, Georg-Johann Lay wrote:
> 
>> You are sure there is no watchdog active?
> 
> 
> On 3/1/12 3:24 PM, Johannes Bauer wrote:
> 
>> Why don't you include the whole program assembly (i.e. after 
>> linking), but only compile units? This would also show the
>> startup code, where a fault in setting up the stack pointer would
>> be visible (i.e. would cause the "call" to fail and therefore 
>> resetting the MCU instead of the behavior you desire).
> 
>> Best regards, Joe
> 
>> _______________________________________________ AVR-GCC-list 
>> mailing list address@hidden 
>> https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPT5FSAAoJEP99n2Mvs+maNKQP/jTAMXdXzh7hxLL+5SUM6ThD
vapgBAkv4MjdrGjr7FkpI7Yeh4oO0ob8zLt5dc5vYeRB3zlGc5ROAAiV9HKLV/C6
UwqxQd9VtFPtsi/xYo5bCu0nslJqjzh5nXa5Bdrt2m+6egybZ1rAF+OUwfxbFQbo
YJBxE4kfl/RLvdR5xBNajRQSIRVUOQC3o/RpKi6TcPo1C33iC8DwM34XaeYLQz8K
BovrHkEdwaO3GhinqEtREU56L1L3fOQG9TFczk/Y1ZmwuK5eES+IxoA4Ep+VLttC
ny1E6GLIQhg0/fmDwxWtmKvY6qDhc5wII1RHOMHkuXh4bsAnCarTfkWUVhfD5gWX
/s2OqKdTwX/ySTHoq2zzgMKcxBYIHYY6RCyT5tj+NYwT/MWQFE1HwxVgL39B1CQV
w7TW9TGHGe6xhs87VhWRSKfZmtuo7EmfTlXOCaLJtfHbgh3S29O3JizLvYGr59Ov
kQHwzBXT6KYuWuQaePCtGoyIGtsuEwUgSzkJCRGnFtGehTfmy641j5qfSTDAWGGt
O67LfmBda3kR6SSRlK9vBUM6pf0oS4cBacRh5OD+vBrlJqXR3Lu+FY2DKOFzGxFo
iJCCTQA6Ow+/mQF//ijjyz5ERkzDkDmIle/dHzIRY6qJUmbGi12N0AOtdFPY/tJy
vwZnm3b87urRzMLF5Bxu
=izOJ
-----END PGP SIGNATURE-----