gcc-avr 4.9.2 -Os messes with interrupt vectors

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

gcc-avr 4.9.2 -Os messes with interrupt vectors

avr-3
Hello,

I have been working on a project for some time and at some point, everything just stopped working. It appears that as soon as I include an ISR in my C code, the main function won't even be called anymore. I reduced my code to this:


#include <avr/io.h>
#include <avr/interrupt.h>

int main (void) {
  cli();
  DDRB = 0xff;
  while(1) PORTB |= (1 << PB5);
  return 0;
}

ISR(TIMER0_OVF_vect) {}

But the LED just won't turn on. The strange thing is: If I remove the ISR at the bottom without changing anything else, even keeping the include, everything works. If I remove the -Os option from gcc but keep the ISR, everything works.

I use these commands to compile, link and flash it:

F_CPU=16000000L
avr-gcc -Wall -DF_CPU=$F_CPU -c -mmcu=atmega168 -Os main.c -o main.o
avr-ld -mavr5 -o led-test.elf main.o
avr-objcopy -O ihex led-test.elf led-test.hex
sudo avrdude -c avrisp2 -p atmega168 -P usb -b 57600 -U flash:w:led-test.hex


I am quite new to the avr tools so I might just have made a silly mistake, so I would appreciate any tips!
Thank you!


LSB:
Distributor ID: Ubuntu
Description:    Ubuntu 16.04 LTS
Release:        16.04
Codename:       xenial

Output of avr-gcc -v:
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/4.9.2/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.9.2/lto-wrapper
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr CFLAGS='-g -O2 -fstack-protector-strong -Wformat ' CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS='-g -O2 -fstack-protector-strong -Wformat ' FCFLAGS='-g -O2 -fstack-protector-strong' FFLAGS='-g -O2 -fstack-protector-strong' GCJFLAGS='-g -O2 -fstack-protector-strong' LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro' OBJCFLAGS='-g -O2 -fstack-protector-strong -Wformat ' OBJCXXFLAGS='-g -O2 -fstack-protector-strong -Wformat '
Thread model: single
gcc version 4.9.2 (GCC)

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc-avr 4.9.2 -Os messes with interrupt vectors

Parthasaradhi Nayani
First off, you are disabling global interrupts (cli ()). You need to enable them (sei ()). I presume you are toggling the LED in ISR, if so the LED will not toggle as interrupts are disabled. 
 
Regards,
Parthasaradhi
Hyderabad


On Sunday, May 8, 2016 2:40 PM, "[hidden email]" <[hidden email]> wrote:


Hello,

I have been working on a project for some time and at some point, everything just stopped working. It appears that as soon as I include an ISR in my C code, the main function won't even be called anymore. I reduced my code to this:


#include <avr/io.h>
#include <avr/interrupt.h>

int main (void) {
  cli();
  DDRB = 0xff;
  while(1) PORTB |= (1 << PB5);
  return 0;
}

ISR(TIMER0_OVF_vect) {}

But the LED just won't turn on. The strange thing is: If I remove the ISR at the bottom without changing anything else, even keeping the include, everything works. If I remove the -Os option from gcc but keep the ISR, everything works.

I use these commands to compile, link and flash it:

F_CPU=16000000L
avr-gcc -Wall -DF_CPU=$F_CPU -c -mmcu=atmega168 -Os main.c -o main.o
avr-ld -mavr5 -o led-test.elf main.o
avr-objcopy -O ihex led-test.elf led-test.hex
sudo avrdude -c avrisp2 -p atmega168 -P usb -b 57600 -U flash:w:led-test.hex


I am quite new to the avr tools so I might just have made a silly mistake, so I would appreciate any tips!
Thank you!


LSB:
Distributor ID: Ubuntu
Description:    Ubuntu 16.04 LTS
Release:        16.04
Codename:       xenial

Output of avr-gcc -v:
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/4.9.2/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.9.2/lto-wrapper
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr CFLAGS='-g -O2 -fstack-protector-strong -Wformat ' CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS='-g -O2 -fstack-protector-strong -Wformat ' FCFLAGS='-g -O2 -fstack-protector-strong' FFLAGS='-g -O2 -fstack-protector-strong' GCJFLAGS='-g -O2 -fstack-protector-strong' LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro' OBJCFLAGS='-g -O2 -fstack-protector-strong -Wformat ' OBJCXXFLAGS='-g -O2 -fstack-protector-strong -Wformat '
Thread model: single
gcc version 4.9.2 (GCC)

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list



_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc-avr 4.9.2 -Os messes with interrupt vectors

avr-3
Thank you for your instant response.

I am sorry if I was unclear about that: I do *not* want the ISR to be called. The LED should turn on because I enable it in main(), however, the uC goes straight to the ISR!

For example, if I set the LED to high in the ISR and set it to low in main(), it will be set to high and the LED will turn on when I flash it. Even though I used cli()!

This behavior appears to depend on -Os, so I guess I am either using the tools incorrectly, or there is a bug in the optimization code.

8. Mai 2016 11:22 von [hidden email]:

First off, you are disabling global interrupts (cli ()). You need to enable them (sei ()). I presume you are toggling the LED in ISR, if so the LED will not toggle as interrupts are disabled. 
 
Regards,
Parthasaradhi
Hyderabad


On Sunday, May 8, 2016 2:40 PM, "[hidden email]" <[hidden email]> wrote:


Hello,

I have been working on a project for some time and at some point, everything just stopped working. It appears that as soon as I include an ISR in my C code, the main function won't even be called anymore. I reduced my code to this:


#include <avr/io.h>
#include <avr/interrupt.h>

int main (void) {
  cli();
  DDRB = 0xff;
  while(1) PORTB |= (1 << PB5);
  return 0;
}

ISR(TIMER0_OVF_vect) {}

But the LED just won't turn on. The strange thing is: If I remove the ISR at the bottom without changing anything else, even keeping the include, everything works. If I remove the -Os option from gcc but keep the ISR, everything works.

I use these commands to compile, link and flash it:

F_CPU=16000000L
avr-gcc -Wall -DF_CPU=$F_CPU -c -mmcu=atmega168 -Os main.c -o main.o
avr-ld -mavr5 -o led-test.elf main.o
avr-objcopy -O ihex led-test.elf led-test.hex
sudo avrdude -c avrisp2 -p atmega168 -P usb -b 57600 -U flash:w:led-test.hex


I am quite new to the avr tools so I might just have made a silly mistake, so I would appreciate any tips!
Thank you!


LSB:
Distributor ID: Ubuntu
Description:    Ubuntu 16.04 LTS
Release:        16.04
Codename:       xenial

Output of avr-gcc -v:
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/4.9.2/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.9.2/lto-wrapper
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr CFLAGS='-g -O2 -fstack-protector-strong -Wformat ' CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS='-g -O2 -fstack-protector-strong -Wformat ' FCFLAGS='-g -O2 -fstack-protector-strong' FFLAGS='-g -O2 -fstack-protector-strong' GCJFLAGS='-g -O2 -fstack-protector-strong' LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro' OBJCFLAGS='-g -O2 -fstack-protector-strong -Wformat ' OBJCXXFLAGS='-g -O2 -fstack-protector-strong -Wformat '
Thread model: single
gcc version 4.9.2 (GCC)

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list



_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc-avr 4.9.2 -Os messes with interrupt vectors

Parthasaradhi Nayani
Hi,

"I do *not* want the ISR to be called". I guess you do not want the interrupt to be enabled. If you do not start the timer (as the interrupt is timer related) this interrupt will never occur. If you are using the timer for something else and need the timer running, then you need not explicitly enable timer overflow interrupt (see TIMSK register bits). In the while loop, you are always setting the port bit which I guess is connected to the LED and the LED will glow when this bit is 1. Suggest toggling the LED through a while loop with delays (large enough to be able to see LED flashing) inserted.
 
Regards,
Parthasaradhi
Hyderabad


On Sunday, May 8, 2016 3:06 PM, "[hidden email]" <[hidden email]> wrote:


Thank you for your instant response.

I am sorry if I was unclear about that: I do *not* want the ISR to be called. The LED should turn on because I enable it in main(), however, the uC goes straight to the ISR!

For example, if I set the LED to high in the ISR and set it to low in main(), it will be set to high and the LED will turn on when I flash it. Even though I used cli()!

This behavior appears to depend on -Os, so I guess I am either using the tools incorrectly, or there is a bug in the optimization code.

8. Mai 2016 11:22 von [hidden email]:

First off, you are disabling global interrupts (cli ()). You need to enable them (sei ()). I presume you are toggling the LED in ISR, if so the LED will not toggle as interrupts are disabled. 
 
Regards,
Parthasaradhi
Hyderabad


On Sunday, May 8, 2016 2:40 PM, "[hidden email]" <[hidden email]> wrote:


Hello,

I have been working on a project for some time and at some point, everything just stopped working. It appears that as soon as I include an ISR in my C code, the main function won't even be called anymore. I reduced my code to this:


#include <avr/io.h>
#include <avr/interrupt.h>

int main (void) {
  cli();
  DDRB = 0xff;
  while(1) PORTB |= (1 << PB5);
  return 0;
}

ISR(TIMER0_OVF_vect) {}

But the LED just won't turn on. The strange thing is: If I remove the ISR at the bottom without changing anything else, even keeping the include, everything works. If I remove the -Os option from gcc but keep the ISR, everything works.

I use these commands to compile, link and flash it:

F_CPU=16000000L
avr-gcc -Wall -DF_CPU=$F_CPU -c -mmcu=atmega168 -Os main.c -o main.o
avr-ld -mavr5 -o led-test.elf main.o
avr-objcopy -O ihex led-test.elf led-test.hex
sudo avrdude -c avrisp2 -p atmega168 -P usb -b 57600 -U flash:w:led-test.hex


I am quite new to the avr tools so I might just have made a silly mistake, so I would appreciate any tips!
Thank you!


LSB:
Distributor ID: Ubuntu
Description:    Ubuntu 16.04 LTS
Release:        16.04
Codename:       xenial

Output of avr-gcc -v:
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/4.9.2/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.9.2/lto-wrapper
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr CFLAGS='-g -O2 -fstack-protector-strong -Wformat ' CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS='-g -O2 -fstack-protector-strong -Wformat ' FCFLAGS='-g -O2 -fstack-protector-strong' FFLAGS='-g -O2 -fstack-protector-strong' GCJFLAGS='-g -O2 -fstack-protector-strong' LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro' OBJCFLAGS='-g -O2 -fstack-protector-strong -Wformat ' OBJCXXFLAGS='-g -O2 -fstack-protector-strong -Wformat '
Thread model: single
gcc version 4.9.2 (GCC)

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list





_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc-avr 4.9.2 -Os messes with interrupt vectors

avr-3
No, I will try to explain where my problem is. The code I posted before should turn the LED connected to PB5 on. The code also contains an ISR, but it is empty and as I never enable interrupts, it should never be called.

The code works without optimizations, but with -Os enabled, the LED does *not* turn on! If I remove the (empty) ISR and keep everything else the same, the LED *does* turn on with optimizations enabled!

My problem is not how to toggle the LED, I know how to do that. My problem is that the code behaves differently when using the optimization option -Os.

8. Mai 2016 14:36 von [hidden email]:

Hi,

"I do *not* want the ISR to be called". I guess you do not want the interrupt to be enabled. If you do not start the timer (as the interrupt is timer related) this interrupt will never occur. If you are using the timer for something else and need the timer running, then you need not explicitly enable timer overflow interrupt (see TIMSK register bits). In the while loop, you are always setting the port bit which I guess is connected to the LED and the LED will glow when this bit is 1. Suggest toggling the LED through a while loop with delays (large enough to be able to see LED flashing) inserted.
 
Regards,
Parthasaradhi
Hyderabad


On Sunday, May 8, 2016 3:06 PM, "[hidden email]" <[hidden email]> wrote:


Thank you for your instant response.

I am sorry if I was unclear about that: I do *not* want the ISR to be called. The LED should turn on because I enable it in main(), however, the uC goes straight to the ISR!

For example, if I set the LED to high in the ISR and set it to low in main(), it will be set to high and the LED will turn on when I flash it. Even though I used cli()!

This behavior appears to depend on -Os, so I guess I am either using the tools incorrectly, or there is a bug in the optimization code.

8. Mai 2016 11:22 von [hidden email]:

First off, you are disabling global interrupts (cli ()). You need to enable them (sei ()). I presume you are toggling the LED in ISR, if so the LED will not toggle as interrupts are disabled. 
 
Regards,
Parthasaradhi
Hyderabad


On Sunday, May 8, 2016 2:40 PM, "[hidden email]" <[hidden email]> wrote:


Hello,

I have been working on a project for some time and at some point, everything just stopped working. It appears that as soon as I include an ISR in my C code, the main function won't even be called anymore. I reduced my code to this:


#include <avr/io.h>
#include <avr/interrupt.h>

int main (void) {
  cli();
  DDRB = 0xff;
  while(1) PORTB |= (1 << PB5);
  return 0;
}

ISR(TIMER0_OVF_vect) {}

But the LED just won't turn on. The strange thing is: If I remove the ISR at the bottom without changing anything else, even keeping the include, everything works. If I remove the -Os option from gcc but keep the ISR, everything works.

I use these commands to compile, link and flash it:

F_CPU=16000000L
avr-gcc -Wall -DF_CPU=$F_CPU -c -mmcu=atmega168 -Os main.c -o main.o
avr-ld -mavr5 -o led-test.elf main.o
avr-objcopy -O ihex led-test.elf led-test.hex
sudo avrdude -c avrisp2 -p atmega168 -P usb -b 57600 -U flash:w:led-test.hex


I am quite new to the avr tools so I might just have made a silly mistake, so I would appreciate any tips!
Thank you!


LSB:
Distributor ID: Ubuntu
Description:    Ubuntu 16.04 LTS
Release:        16.04
Codename:       xenial

Output of avr-gcc -v:
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/4.9.2/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.9.2/lto-wrapper
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr CFLAGS='-g -O2 -fstack-protector-strong -Wformat ' CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS='-g -O2 -fstack-protector-strong -Wformat ' FCFLAGS='-g -O2 -fstack-protector-strong' FFLAGS='-g -O2 -fstack-protector-strong' GCJFLAGS='-g -O2 -fstack-protector-strong' LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro' OBJCFLAGS='-g -O2 -fstack-protector-strong -Wformat ' OBJCXXFLAGS='-g -O2 -fstack-protector-strong -Wformat '
Thread model: single
gcc version 4.9.2 (GCC)

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list





_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc-avr 4.9.2 -Os messes with interrupt vectors

Thomas D. Dean
On 05/08/16 06:22, [hidden email] wrote:

Looks like you are toggling the LED too fast to see it.

Try adding a delay in the while loop

while (1) {
   PORTB |= (1 << PB5);
   delay_ms(500); /* or something */
}

Look at the avr-libc documentation.
http://nongnu.org/avr-libc/user-manual/

Tom Dean

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc-avr 4.9.2 -Os messes with interrupt vectors

Senthil Kumar Selvaraj
In reply to this post by avr-3

[hidden email] writes:

> No, I will try to explain where my problem is. The code I posted before
> should turn the LED connected to PB5 on. The code also contains an ISR, but
> it is empty and as I never enable interrupts, it should never be called.

I guess you're not linking in the crt file for the device. The crt file
has startup code and the correct vector table for the device. Without
it, and without an alternate startup/vector table init code, you will
miss things like global variable initialization, SP setup etc., and
interrupt handlers won't run.

Instead of
>>> avr-ld -mavr5 -o led-test.elf main.o

Can you invoke the compiler driver with the correct device i.e.?

avr-gcc -mmcu=atmega168 -o led-test.elf main.o

That way, the driver will invoke the linker with the correct crt object
file and other libraries. You can pass -v to see what exactly goes to
the linker.

Regards
Senthil

>
> The code works without optimizations, but with -Os enabled, the LED does
> *not* turn on! If I remove the (empty) ISR and keep everything else the same,
> the LED *does* turn on with optimizations enabled!
>
> My problem is not how to toggle the LED, I know how to do that. My problem is
> that the code behaves differently when using the optimization option -Os.
>
> 8. Mai 2016 14:36 von [hidden email]:
>
>
>> Hi,
>> "> I do *not* want the ISR to be called". I guess you do not want the
>> interrupt to be enabled. If you do not start the timer (as the interrupt is
>> timer related) this interrupt will never occur. If you are using the timer
>> for something else and need the timer running, then you need not explicitly
>> enable timer overflow interrupt (see TIMSK register bits). In the while
>> loop, you are always setting the port bit which I guess is connected to the
>> LED and the LED will glow when this bit is 1. Suggest toggling the LED
>> through a while loop with delays (large enough to be able to see LED
>> flashing) inserted.> > Regards,
>> Parthasaradhi
>> Hyderabad
>>
>>
>>  >  >  >  On Sunday, May 8, 2016 3:06 PM, "> [hidden email]> " <> [hidden email]>
>> > wrote:
>>
>>
>>  > Thank you for your instant response.
>>
>> I am sorry if I was unclear about that: I do *not* want the ISR to be
>> called. The LED should turn on because I enable it in main(), however, the
>> uC goes straight to the ISR!
>>
>> For example, if I set the LED to high in the ISR and set it to low in
>> main(), it will be set to high and the LED will turn on when I flash it.
>> Even though I used cli()!
>>
>> This behavior appears to depend on -Os, so I guess I am either using the
>> tools incorrectly, or there is a bug in the optimization code.
>>
>> 8. Mai 2016 11:22 von > [hidden email]> :
>>
>>
>>> First off, you are disabling global interrupts (cli ()). You need to
>>> enable them (sei ()). I presume you are toggling the LED in ISR, if so the
>>> LED will not toggle as interrupts are disabled.>> >> Regards,
>>> Parthasaradhi
>>> Hyderabad
>>>
>>>
>>>  >>  >>  >>  On Sunday, May 8, 2016 2:40 PM, ">> [hidden email]>> " <>>
>>> [hidden email]>> > wrote:
>>>
>>>
>>>  >>           >> Hello,
>>>
>>> I have been working on a project for some time and at some point,
>>> everything just stopped working. It appears that as soon as I include an
>>> ISR in my C code, the main function won't even be called anymore. I
>>> reduced my code to this:
>>>
>>>
>>> #include <avr/io.h>
>>> #include <avr/interrupt.h>
>>>
>>> int main (void) {
>>>  cli();
>>>  DDRB = 0xff;
>>>  while(1) PORTB |= (1 << PB5);
>>>  return 0;
>>> }
>>>
>>> ISR(TIMER0_OVF_vect) {}
>>>
>>> But the LED just won't turn on. The strange thing is: If I remove the ISR
>>> at the bottom without changing anything else, even keeping the include,
>>> everything works. If I remove the -Os option from gcc but keep the ISR,
>>> everything works.
>>>
>>> I use these commands to compile, link and flash it:
>>>
>>> F_CPU=16000000L
>>> avr-gcc -Wall -DF_CPU=$F_CPU -c -mmcu=atmega168 -Os main.c -o main.o
>>> avr-ld -mavr5 -o led-test.elf main.o
>>> avr-objcopy -O ihex led-test.elf led-test.hex
>>> sudo avrdude -c avrisp2 -p atmega168 -P usb -b 57600 -U
>>> flash:w:led-test.hex
>>>
>>>
>>> I am quite new to the avr tools so I might just have made a silly mistake,
>>> so I would appreciate any tips!
>>> Thank you!
>>>
>>>
>>> LSB:
>>> Distributor ID: Ubuntu
>>> Description: Ubuntu 16.04 LTS
>>> Release: 16.04
>>> Codename: xenial
>>>
>>> Output of avr-gcc -v:
>>> Using built-in specs.
>>> Reading specs from /usr/lib/gcc/avr/4.9.2/device-specs/specs-avr2
>>> COLLECT_GCC=avr-gcc
>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.9.2/lto-wrapper
>>> Target: avr
>>> Configured with: ../src/configure -v --enable-languages=c,c++
>>> --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man
>>> --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared
>>> --with-system-zlib --enable-long-long --enable-nls
>>> --without-included-gettext --disable-libssp --build=x86_64-linux-gnu
>>> --host=x86_64-linux-gnu --target=avr CFLAGS='-g -O2
>>> -fstack-protector-strong -Wformat ' CPPFLAGS=-D_FORTIFY_SOURCE=2
>>> CXXFLAGS='-g -O2 -fstack-protector-strong -Wformat ' FCFLAGS='-g -O2
>>> -fstack-protector-strong' FFLAGS='-g -O2 -fstack-protector-strong'
>>> GCJFLAGS='-g -O2 -fstack-protector-strong'
>>> LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro' OBJCFLAGS='-g -O2
>>> -fstack-protector-strong -Wformat ' OBJCXXFLAGS='-g -O2
>>> -fstack-protector-strong -Wformat '
>>> Thread model: single
>>> gcc version 4.9.2 (GCC)
>>>
>>> _______________________________________________
>>> AVR-GCC-list mailing list
>>> [hidden email]
>>> https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>>>
>>>
>>>   >>  >>
>>
>>
>>   >  >   _______________________________________________
> AVR-GCC-list mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/avr-gcc-list


_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc-avr 4.9.2 -Os messes with interrupt vectors

avr-3
God, thank you so much! I have had this issue for days without finding a solution! Using avr-gcc with mmcu=atmega168 instead of avr-ld with mavr5 appears to have solved the problem!

As you suggested, I used -v to see what is going on and you are right, I was missing the correct CRT file!

Thank you so much, Senthil! You saved me a lot of time and headache!

8. Mai 2016 16:16 von [hidden email]:


[hidden email] writes:
No, I will try to explain where my problem is. The code I posted before
should turn the LED connected to PB5 on. The code also contains an ISR, but
it is empty and as I never enable interrupts, it should never be called.

I guess you're not linking in the crt file for the device. The crt file
has startup code and the correct vector table for the device. Without
it, and without an alternate startup/vector table init code, you will
miss things like global variable initialization, SP setup etc., and
interrupt handlers won't run.

Instead of
avr-ld -mavr5 -o led-test.elf main.o

Can you invoke the compiler driver with the correct device i.e.?

avr-gcc -mmcu=atmega168 -o led-test.elf main.o

That way, the driver will invoke the linker with the correct crt object
file and other libraries. You can pass -v to see what exactly goes to
the linker.

Regards
Senthil

The code works without optimizations, but with -Os enabled, the LED does
*not* turn on! If I remove the (empty) ISR and keep everything else the same,
the LED *does* turn on with optimizations enabled!

My problem is not how to toggle the LED, I know how to do that. My problem is
that the code behaves differently when using the optimization option -Os.

8. Mai 2016 14:36 von [hidden email]:

Hi,
"> I do *not* want the ISR to be called". I guess you do not want the
interrupt to be enabled. If you do not start the timer (as the interrupt is
timer related) this interrupt will never occur. If you are using the timer
for something else and need the timer running, then you need not explicitly
enable timer overflow interrupt (see TIMSK register bits). In the while
loop, you are always setting the port bit which I guess is connected to the
LED and the LED will glow when this bit is 1. Suggest toggling the LED
through a while loop with delays (large enough to be able to see LED
flashing) inserted.> > Regards,
Parthasaradhi
Hyderabad


> > > On Sunday, May 8, 2016 3:06 PM, "> [hidden email]> " <> [hidden email]>
> wrote:


> Thank you for your instant response.

I am sorry if I was unclear about that: I do *not* want the ISR to be
called. The LED should turn on because I enable it in main(), however, the
uC goes straight to the ISR!

For example, if I set the LED to high in the ISR and set it to low in
main(), it will be set to high and the LED will turn on when I flash it.
Even though I used cli()!

This behavior appears to depend on -Os, so I guess I am either using the
tools incorrectly, or there is a bug in the optimization code.

8. Mai 2016 11:22 von > [hidden email]> :

First off, you are disabling global interrupts (cli ()). You need to
enable them (sei ()). I presume you are toggling the LED in ISR, if so the
LED will not toggle as interrupts are disabled.>> >> Regards,
Parthasaradhi
Hyderabad


>> >> >> On Sunday, May 8, 2016 2:40 PM, ">> [hidden email]>> " <>>
[hidden email]>> > wrote:


>> >> Hello,

I have been working on a project for some time and at some point,
everything just stopped working. It appears that as soon as I include an
ISR in my C code, the main function won't even be called anymore. I
reduced my code to this:


#include <avr/io.h>
#include <avr/interrupt.h>

int main (void) {
cli();
DDRB = 0xff;
while(1) PORTB |= (1 << PB5);
return 0;
}

ISR(TIMER0_OVF_vect) {}

But the LED just won't turn on. The strange thing is: If I remove the ISR
at the bottom without changing anything else, even keeping the include,
everything works. If I remove the -Os option from gcc but keep the ISR,
everything works.

I use these commands to compile, link and flash it:

F_CPU=16000000L
avr-gcc -Wall -DF_CPU=$F_CPU -c -mmcu=atmega168 -Os main.c -o main.o
avr-ld -mavr5 -o led-test.elf main.o
avr-objcopy -O ihex led-test.elf led-test.hex
sudo avrdude -c avrisp2 -p atmega168 -P usb -b 57600 -U
flash:w:led-test.hex


I am quite new to the avr tools so I might just have made a silly mistake,
so I would appreciate any tips!
Thank you!


LSB:
Distributor ID: Ubuntu
Description: Ubuntu 16.04 LTS
Release: 16.04
Codename: xenial

Output of avr-gcc -v:
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/4.9.2/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.9.2/lto-wrapper
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++
--prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man
--bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared
--with-system-zlib --enable-long-long --enable-nls
--without-included-gettext --disable-libssp --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=avr CFLAGS='-g -O2
-fstack-protector-strong -Wformat ' CPPFLAGS=-D_FORTIFY_SOURCE=2
CXXFLAGS='-g -O2 -fstack-protector-strong -Wformat ' FCFLAGS='-g -O2
-fstack-protector-strong' FFLAGS='-g -O2 -fstack-protector-strong'
GCJFLAGS='-g -O2 -fstack-protector-strong'
LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro' OBJCFLAGS='-g -O2
-fstack-protector-strong -Wformat ' OBJCXXFLAGS='-g -O2
-fstack-protector-strong -Wformat '
Thread model: single
gcc version 4.9.2 (GCC)

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list


>> >>


> > _______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc-avr 4.9.2 -Os messes with interrupt vectors

avr-3
In reply to this post by Thomas D. Dean
Thank you for your reply! I solved the issue thanks to Senthil, but FYI

PORTB |= (1 << PB5)

does *not* toggle the LED, it is OR, not XOR. It was actually a problem with some linker flags.

8. Mai 2016 15:53 von [hidden email]:

On 05/08/16 06:22, [hidden email] wrote:

Looks like you are toggling the LED too fast to see it.

Try adding a delay in the while loop

while (1) {
PORTB |= (1 << PB5);
delay_ms(500); /* or something */
}

Look at the avr-libc documentation.
http://nongnu.org/avr-libc/user-manual

Tom Dean

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Loading...