You are not logged in.
Hello everybody!
After upgrade from avr-gcc-4.7.2 to avr-gcc-4.8.0-1 my avr project stopped work correctly.
I wrote a small test to show you this issue.
CPU is atmega8.
This code flashes a LED connected to pin PD4.
#include <avr/io.h>
#include <util/delay.h>
int main(void)
{
DDRD |= 1 << PD4;
while(1)
{
PORTD ^= 1 << PD4;
_delay_ms(250);
}
}
After compiling the program by avr-gcc-4.7.2 LED is flashing, the code is ok.
Disassembling list;
0: c0 12 rjmp .+36 ; 0x26
2: c0 19 rjmp .+50 ; 0x36
4: c0 18 rjmp .+48 ; 0x36
6: c0 17 rjmp .+46 ; 0x36
8: c0 16 rjmp .+44 ; 0x36
a: c0 15 rjmp .+42 ; 0x36
c: c0 14 rjmp .+40 ; 0x36
e: c0 13 rjmp .+38 ; 0x36
10: c0 12 rjmp .+36 ; 0x36
12: c0 11 rjmp .+34 ; 0x36
14: c0 10 rjmp .+32 ; 0x36
16: c0 0f rjmp .+30 ; 0x36
18: c0 0e rjmp .+28 ; 0x36
1a: c0 0d rjmp .+26 ; 0x36
1c: c0 0c rjmp .+24 ; 0x36
1e: c0 0b rjmp .+22 ; 0x36
20: c0 0a rjmp .+20 ; 0x36
22: c0 09 rjmp .+18 ; 0x36
24: c0 08 rjmp .+16 ; 0x36
26: 24 11 eor R1, R1
28: be 1f out $3f, R1
2a: e5 cf ldi R28, 0x5f
2c: e0 d4 ldi R29, 0x04
2e: bf de out $3e, R29
30: bf cd out $3d, R28
32: d0 02 rcall .+4 ; 0x38
34: c0 10 rjmp .+32 ; 0x56
36: cf e4 rjmp .-56 ; 0x0
38: 9a 8c sbi $11, 4
3a: e1 90 ldi R25, 0x10
3c: b3 82 in R24, 0x12
3e: 27 89 eor R24, R25
40: bb 82 out $12, R24
42: ef 2f ser R18
44: e9 3f ldi R19, 0x9f
46: e0 85 ldi R24, 0x05
48: 50 21 subi R18, 0x01
4a: 40 30 sbci R19, 0x00
4c: 40 80 sbci R24, 0x00
4e: f7 e1 brne .-8 ; 0x48
50: c0 00 rjmp .+0 ; 0x52
52: 00 00 nop
54: cf f3 rjmp .-26 ; 0x3c
56: 94 f8 cli
58: cf ff rjmp .-2 ; 0x58
After compiling the program by avr-gcc-4.8.0-1 LED is not flashing and disassembled code is partially messed.
Disassembling list;
0: 00 04 .dw 0x0004
2: 00 00 nop
4: 00 14 .dw 0x0014
6: 00 00 nop
8: 00 03 .dw 0x0003
a: 00 00 nop
c: 4e 47 sbci R20, 0xe7
e: 00 55 .dw 0x0055
10: d6 50 rcall .+3232 ; 0xcb2
12: d2 01 rcall .+1026 ; 0x416
14: 3c 1a cpi R17, 0xca
16: 31 14 cpi R17, 0x14
18: f5 d2 brpl .+116 ; 0x8e
1a: 6a 35 ori R19, 0xa5
1c: 11 4f cpse R20, R15
1e: b6 9c in R9, 0x3c
20: 41 a5 sbci R26, 0x15
22: f7 07 brid .-64 ; 0xffffffe4
24: c0 12 rjmp .+36 ; 0x4a
26: c0 19 rjmp .+50 ; 0x5a
28: c0 18 rjmp .+48 ; 0x5a
2a: c0 17 rjmp .+46 ; 0x5a
2c: c0 16 rjmp .+44 ; 0x5a
2e: c0 15 rjmp .+42 ; 0x5a
30: c0 14 rjmp .+40 ; 0x5a
32: c0 13 rjmp .+38 ; 0x5a
34: c0 12 rjmp .+36 ; 0x5a
36: c0 11 rjmp .+34 ; 0x5a
38: c0 10 rjmp .+32 ; 0x5a
3a: c0 0f rjmp .+30 ; 0x5a
3c: c0 0e rjmp .+28 ; 0x5a
3e: c0 0d rjmp .+26 ; 0x5a
40: c0 0c rjmp .+24 ; 0x5a
42: c0 0b rjmp .+22 ; 0x5a
44: c0 0a rjmp .+20 ; 0x5a
46: c0 09 rjmp .+18 ; 0x5a
48: c0 08 rjmp .+16 ; 0x5a
4a: 24 11 eor R1, R1
4c: be 1f out $3f, R1
4e: e5 cf ldi R28, 0x5f
50: e0 d4 ldi R29, 0x04
52: bf de out $3e, R29
54: bf cd out $3d, R28
56: d0 02 rcall .+4 ; 0x5c
58: c0 10 rjmp .+32 ; 0x7a
5a: cf e4 rjmp .-56 ; 0x24
5c: 9a 8c sbi $11, 4
5e: e1 90 ldi R25, 0x10
60: b3 82 in R24, 0x12
62: 27 89 eor R24, R25
64: bb 82 out $12, R24
66: ef 2f ser R18
68: e9 3f ldi R19, 0x9f
6a: e0 85 ldi R24, 0x05
6c: 50 21 subi R18, 0x01
6e: 40 30 sbci R19, 0x00
70: 40 80 sbci R24, 0x00
72: f7 e1 brne .-8 ; 0x6c
74: c0 00 rjmp .+0 ; 0x76
76: 00 00 nop
78: cf f3 rjmp .-26 ; 0x60
7a: 94 f8 cli
7c: cf ff rjmp .-2 ; 0x7c
Should I write a bug report?
Offline
I think, you should.
I have the same problem with the most recent avr-gcc-4.8.0 (on Archlinux, the mcu is an Atmega644PA). My code runs fine if it has been compiled with avr-gcc-4.7.0 (on Ubuntu 12.10).
Offline
I ran into this exact problem a couple weeks ago; I made my own package so I could use avr-gcc 4.8 before the official release was out. Took me a few days of banging my head against the wall to realize that it was the compiler's fault. That'll teach me to use prerelease software!
If you run 'avr-objdump -h' (or 'readelf -S') on the elf file that avr-gcc 4.8 produces, you'll see this:
Section Headers:
Sections:
Idx Name Size VMA LMA File off Algn
0 .note.gnu.build-id 00000024 00000000 00000000 000000b4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .data 00000072 00800100 000018f0 000019a4 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .text 000018cc 00000024 00000024 000000d8 2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .bss 00000035 00800172 00800172 00001a16 2**0
ALLOC
4 .stab 000044ac 00000000 00000000 00001a18 2**2
CONTENTS, READONLY, DEBUGGING
5 .stabstr 000014c6 00000000 00000000 00005ec4 2**0
CONTENTS, READONLY, DEBUGGING
6 .comment 00000011 00000000 00000000 0000738a 2**0
CONTENTS, READONLY
7 .debug_aranges 00000028 00000000 00000000 0000739b 2**0
CONTENTS, READONLY, DEBUGGING
8 .debug_info 00003185 00000000 00000000 000073c3 2**0
CONTENTS, READONLY, DEBUGGING
9 .debug_abbrev 0000048b 00000000 00000000 0000a548 2**0
CONTENTS, READONLY, DEBUGGING
10 .debug_line 00000704 00000000 00000000 0000a9d3 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_frame 00000420 00000000 00000000 0000b0d8 2**2
CONTENTS, READONLY, DEBUGGING
12 .debug_str 00000943 00000000 00000000 0000b4f8 2**0
CONTENTS, READONLY, DEBUGGING
13 .debug_loc 00001439 00000000 00000000 0000be3b 2**0
CONTENTS, READONLY, DEBUGGING
14 .debug_ranges 000001f0 00000000 00000000 0000d274 2**0
CONTENTS, READONLY, DEBUGGINGYou can see that there's a section, '.note.gnu.build-id', which isn't produced by avr-gcc 4.7. From what I can tell, it's extra metadata that identifies the 'build' of the program by the time and date at which it occured, the compiler version used, etc. This is presumably useful on PC platforms and it gets loaded into memory.
For some reason, presumably because the AVR linker scripts in binutils haven't been updated to be compatible with gcc 4.8, this extra metadata section is allocated at address zero: that is, it's located where the interrupt vector table should be, and the vector table is pushed forward! So the reset vector, which gets executed when the microcontroller starts, immediately executes a bunch of junk instructions! Not only that, you can't just cut out the '.note.gnu.build-id' section with avr-strip or avr-objcopy because all of the addresses in the code will then be off by 0x24!
I've tried to mess with the linker scripts (/usr/lib/ldscripts/avr*.x*) to omit the section, but my experience with linker scripts is limited, so I haven't been successful. For now, I'm sticking to 4.7.2.
You know, I should probably file a bug report.
Offline
Two hours of digging later, it looks like it is an Arch Linux package misconfiguration, but the avr linker scripts in binutils are also implicated somewhat because they don't handle the misconfiguration in a sane way.
Arch Linux bug report: https://bugs.archlinux.org/task/34902
Upstream bug report: http://sourceware.org/bugzilla/show_bug.cgi?id=15389
Until the package is updated, you can rebuild the package using ABS, removing this line in the PKGBUILD:
--enable-linker-build-id \I'll report back if that fixes it for me.
Or, roll back to 4.7.2-1:
http://arm.konnichi.com/2013/03/12/comm … pkg.tar.xz (x86_64)
http://arm.konnichi.com/2013/03/12/comm … pkg.tar.xz (i686)
Last edited by jgott (2013-04-23 18:40:29)
Offline
I'll report back if that fixes it for me.
The PKGBUILD modification that I suggested does, in fact, fix it.
Offline
Thank you! Removing the '--enable-linker-build-id' flag and recompilation of gcc-4.8.0 also fixed for me.
Offline
jgott wrote:I'll report back if that fixes it for me.
The PKGBUILD modification that I suggested does, in fact, fix it.
jgott, thank you very much!
Offline
As of now, avr-gcc 4.8.0-2 is in the repos and it's fixed.
Offline
Yes, I have already tested avr-gcc 4.8.0-2. It works fine.
Last edited by harmless (2013-04-24 16:01:14)
Offline