[SOLVED] Compiling for AtTiny1607 (or other 0-series/1-series) with avr-gcc

Log in or register to post comments
Go To Last Post
50 posts / 0 new
Author
Message
roosta
roosta's picture
Level: New Member
Joined: Wed. Sep 18, 2019
Posts: 9 View posts
#1
Posted by roosta: Sun. Nov 24, 2019 - 11:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, I am relatively new to the world of programming AVR directly but have had some success with the older ISP chips.

 

However I am planning a project where I would really like to use the AtTiny 1607 or 1617 but I cannot figure out how to compile even an example blink sketch with avr-gcc for such a target.

 

I have looked for guides and cannot find anything that is very comprehensive.

 

So my question - could someone help guide me through it?

 

Some more info about my environment -

 

OS - Fedora Linux

Installed - avr-libc, avr-gcc, avr-binutils, avr-gdb, avrdude from system repositories (is this foolish - should I compile from source?)

Downloaded AtTiny DFP "packs" from Microchip

 

I'm aware that I should include the AtTiny packs in my avr-gcc compile command but I cannot figure out how to do so.

 

Thanks!

Tags:

AVR Microcontrollers, megaAVR and tinyAVR, # ATtiny #tinyavr 1-series
Last Edited: Fri. Dec 6, 2019 - 11:21 PM
Top
ron_sutherland
ron_sutherland's picture
Level: Hangaround
Joined: Mon. Nov 12, 2018
Posts: 215 View posts
Location: Tempe, AZ, USA
Posted by ron_sutherland: Mon. Nov 25, 2019 - 12:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What version of avr-gcc is on your Fedora (show it like this)

 

$ avr-gcc -v
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/5.4.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/5.4.0/lto-wrapper
Target: avr
Configured with: ../gcc/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 -fdebug-prefix-map=/build/gcc-avr-n0nSsH/gcc-avr-5.4.0+Atmel3.6.0=. -fstack-protector-strong -Wformat ' CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2' CXXFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-avr-n0nSsH/gcc-avr-5.4.0+Atmel3.6.0=. -fstack-protector-strong -Wformat ' FCFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-avr-n0nSsH/gcc-avr-5.4.0+Atmel3.6.0=. -fstack-protector-strong' FFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-avr-n0nSsH/gcc-avr-5.4.0+Atmel3.6.0=. -fstack-protector-strong' GCJFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-avr-n0nSsH/gcc-avr-5.4.0+Atmel3.6.0=. -fstack-protector-strong' LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro' OBJCFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-avr-n0nSsH/gcc-avr-5.4.0+Atmel3.6.0=. -fstack-protector-strong -Wformat ' OBJCXXFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-avr-n0nSsH/gcc-avr-5.4.0+Atmel3.6.0=. -fstack-protector-strong -Wformat '
Thread model: single
gcc version 5.4.0 (GCC)

If it is not at least 5.4 then you may be out of luck

my projects: https://github.com/epccs

Last Edited: Mon. Nov 25, 2019 - 12:29 AM
Top
curtvm
curtvm's picture
Level: Raving Lunatic
Joined: Wed. Sep 21, 2005
Posts: 2732 View posts
Posted by curtvm: Mon. Nov 25, 2019 - 12:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not just use MPLABX-

 

https://www.microchip.com/mplab/...

AVR 8-bit Toolchain 3.6.2 - Linux 64-bit
https://www.microchip.com/mymicr...

 

https://www.microchip.com/mplab/...

MPLAB® X IDE v5.30
https://www.microchip.com/mplabx...

 

extract toolchain somewhere, /opt chosen here (which requires sudo on my system), but can extract it anywhere

:~/Downloads$ sudo tar -xvf avr8-gnu-toolchain-3.6.2.1759-linux.any.x86_64.tar.gz --directory=/opt

 

extract and install MPLABX, you only need 8bit support and can uncheck the 3 options it lists after its done-

:~/Downloads$ tar -xvf MPLABX-v5.30-linux-installer.tar
:~/Downloads$ sudo ./MPLABX-v5.30-linux-installer.sh

 

now open mplabx, maunally specify the toolchain location downloaded-

Tools Options Embedded Build Tools 
Add,  browse, find where avr8-gnu-toolchain was extracted, choose its bin directory, OK

 

You now can create a new project. The project wizard is simple enough, and you can choose the compiler (you have only one), the programmer (I assume you have something, otherwise choose the simulator for now).

 

Easy.

 

edit- needed change to fix ld script problem (replace fixed address with symbol)-

edit again- just need to change the xn linker script, no need for any project options as this is a one time fix

 

:~/Downloads$  sed -i.bak 's/0x802000/__DATA_REGION_ORIGIN__/' /opt/avr8-gnu-toolchain-linux_x86_64/avr/lib/ldscripts/avrxmega3.xn

 

 

Last Edited: Wed. Nov 27, 2019 - 03:01 AM
Top
MattRW
MattRW's picture
Level: Hangaround
Joined: Thu. Feb 14, 2019
Posts: 350 View posts
Location: Los Angeles area
Posted by MattRW: Mon. Nov 25, 2019 - 01:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a thread here where I provide instructions for building gcc-8 and other stuff for the purpose of generating avr-0 binaries.

I don't think the atpacks have files for the tiny's though.  Check https://github.com/stevenj/avr-libc3 for that maybe.

Top
ron_sutherland
ron_sutherland's picture
Level: Hangaround
Joined: Mon. Nov 12, 2018
Posts: 215 View posts
Location: Tempe, AZ, USA
Posted by ron_sutherland: Mon. Nov 25, 2019 - 01:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MattRW wrote:
atpacks have files for the tiny's

 

Looks like it does to me, but I have not used a tiny.

 

http://packs.download.atmel.com/#collapse-Atmel-ATtiny-DFP-pdsc

my projects: https://github.com/epccs

Top
meolsen
meolsen's picture
Level: Site Admin
Joined: Wed. Jul 27, 2011
Posts: 3443 View posts
Location: Microchip, Arizona
Posted by meolsen: Mon. Nov 25, 2019 - 01:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> I don't think the atpacks have files for the tiny's though.
.
Where on earth did you get that idea? All device support is provided in the atpack, be it for GCC, iar, avrasm2 or other...
.
I would install MPLAB and see what command line it generates. It uses -I to add the dfp include path, and -B to load the gcc spec file for the device from the DFP

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

Top
MattRW
MattRW's picture
Level: Hangaround
Joined: Thu. Feb 14, 2019
Posts: 350 View posts
Location: Los Angeles area
Posted by MattRW: Mon. Nov 25, 2019 - 03:12 AM (Reply to #6)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meolsen wrote:

> I don't think the atpacks have files for the tiny's though.
.
Where on earth did you get that idea? All device support is provided in the atpack, be it for GCC, iar, avrasm2 or other...

 

 

$ pwd
/opt/local/avr/packs/1.3.300/device-specs
$ ls *tiny*
ls: cannot access '*tiny*': No such file or directory

 

Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4246 View posts
Location: SF Bay area
Posted by westfw: Mon. Nov 25, 2019 - 03:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The compile command should end up looking like:

 

avr-gcc -g -Wall -Os -I /Downloads/Atmel.ATtiny_DFP.1.3.229/include/ -B /Downloads/Atmel.ATtiny_DFP.1.3.229/gcc/dev/attiny1607 -mmcu=attiny1607 -o foo.elf foo.c

 

Where the  -B and -I options point into the uncompressed "packs" directory (it's a zip file, despite the weird extension), and are both necessary.

 

Top
MattRW
MattRW's picture
Level: Hangaround
Joined: Thu. Feb 14, 2019
Posts: 350 View posts
Location: Los Angeles area
Posted by MattRW: Mon. Nov 25, 2019 - 03:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, that's my problem!  There is one service pack for ATmega and one for ATtiny. 

I just downloaded

Microchip.ATmega_DFP.2.0.12.atpack 

Microchip.ATtiny_DFP.2.0.10.atpack

 

Top
roosta
roosta's picture
Level: New Member
Joined: Wed. Sep 18, 2019
Posts: 9 View posts
Posted by roosta: Mon. Nov 25, 2019 - 11:55 AM (Reply to #2)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  •  This is my gcc version

avr-gcc -v
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/9.2.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/avr/9.2.0/lto-wrapper
Target: avr
Configured with: ../gcc-9.2.0/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --with-system-zlib --enable-version-specific-runtime-libs --with-pkgversion='Fedora 9.2.0-1.fc31' --with-bugurl=https://bugzilla.redhat.com/
Thread model: single
gcc version 9.2.0 (Fedora 9.2.0-1.fc31) 

 

  • @curtvm I'm trying to stick to opensource solutions only
  • @MattRW thanks I will look at that in detail
  • @westfw - awesome thanks I will give that a go and report back!

 

Thanks everyone for the help.

Last Edited: Mon. Nov 25, 2019 - 12:00 PM
Top
El Tangas
El Tangas's picture
Level: Raving Lunatic
Joined: Thu. Jul 14, 2016
Posts: 2839 View posts
Posted by El Tangas: Mon. Nov 25, 2019 - 12:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

roosta wrote:
gcc version 9.2.0 (Fedora 9.2.0-1.fc31) 

 

Just to say, that in my tests v8 generates better code than v9. Go figure...

Top
roosta
roosta's picture
Level: New Member
Joined: Wed. Sep 18, 2019
Posts: 9 View posts
Posted by roosta: Mon. Nov 25, 2019 - 12:18 PM (Reply to #10)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have just tested the solution proposed by westfw - namely

 

avr-gcc -g -Wall -Os -I Microchip.ATtiny_DFP.2.0.10/include -B Microchip.ATtiny_DFP.2.0.10/gcc/dev/attiny1607 -mmcu=attiny1607 -o main.elf main.c
/usr/lib/gcc/avr/9.2.0/../../../../avr/bin/ld: skipping incompatible /usr/lib/gcc/avr/9.2.0/../../../../avr/lib/libm.a when searching for -lm
/usr/lib/gcc/avr/9.2.0/../../../../avr/bin/ld: cannot find -lm
/usr/lib/gcc/avr/9.2.0/../../../../avr/bin/ld: skipping incompatible /usr/lib/gcc/avr/9.2.0/../../../../avr/lib/libc.a when searching for -lc
/usr/lib/gcc/avr/9.2.0/../../../../avr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status

where main.c is

 

#include <avr/io.h>  
 
int main (void)
{
    
    /* STK600 have eight User Buttons and eight User LEDs which can be connected to any IO pin using cables */   
    
    /* Configure PB0 as input (remember to connect SW0 to PB0 using a cable */   
    PORTB.DIRCLR = PIN0_bm;   
 
    /* Configure PB1 as output (remember to connect LED0 to PB1 using a cable*/   
    PORTB.DIRSET = PIN1_bm;   
 
    while (1)  {     
        /* Check the status of SW0 */     
        
        /* 0: Pressed */     
        if (!(PORTB.IN & (PIN0_bm))) {       
            /* LED0 on */       
            PORTB.OUTCLR = PIN1_bm;     
        }     
 
        /* 1: Released */     
        else {       
            /* LED0 off */       
            PORTB.OUTSET = PIN1_bm;     
        }
    }
}

Any ideas on what might be going on?

Top
El Tangas
El Tangas's picture
Level: Raving Lunatic
Joined: Thu. Jul 14, 2016
Posts: 2839 View posts
Posted by El Tangas: Mon. Nov 25, 2019 - 12:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have the xmega3 libraries? That is "avr/lib/avrxmega3" and "lib/gcc/avr/(version)/avrxmega3" directories?

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98271 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Nov 25, 2019 - 12:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

Do you have the xmega3 libraries? That is "avr/lib/avrxmega3" and "lib/gcc/avr/(version)/avrxmega3" directories?

Exactly. This looks wrong:

/usr/lib/gcc/avr/9.2.0/../../../../avr/bin/ld: skipping incompatible /usr/lib/gcc/avr/9.2.0/../../../../avr/lib/libm.a when searching for -lm

 So the file it is trying to link with is /usr/avr/lib/libm.a but here's what I get on Windows when I build an empty main() for tiny1607:

START GROUP
LOAD c:/program files (x86)/atmel/studio/7.0/toolchain/avr8/avr8-gnu-toolchain/bin/../lib/gcc/avr/5.4.0/../../../../avr/lib/avrxmega3\libm.a

So it's actually linking with c:/program files (x86)/atmel/studio/7.0/toolchain/avr8/avr8-gnu-toolchain/avr/lib/avrxmega3\libm.a, forget the "front bit" of that but the point is that under avr/lib it if not simply libm.a in that directory but the libm.a in the avrxmega3 sub-directory that it attempts to use.

 

That's why it rejects libm.a because it is not the avrxmega3 version of that (there are 18 versions of libm.a in a usual installation).

Top
roosta
roosta's picture
Level: New Member
Joined: Wed. Sep 18, 2019
Posts: 9 View posts
Posted by roosta: Mon. Nov 25, 2019 - 03:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have an avrxmega3 directory here

ls /lib/gcc/avr/9.2.0/avrxmega3                                                                                                                                                                                             1 ↵
libgcc.a  libgcov.a  short-calls

But for some strange reason I have no avrxmega3 directory in /usr/avr/lib/

/usr/avr/lib/tiny-stack/libm.a
/usr/avr/lib/libm.a
/usr/avr/lib/avr6/libm.a
/usr/avr/lib/avrxmega6/libm.a
/usr/avr/lib/avr3/libm.a
/usr/avr/lib/avr5/libm.a
/usr/avr/lib/avr25/tiny-stack/libm.a
/usr/avr/lib/avr25/libm.a
/usr/avr/lib/avr4/libm.a
/usr/avr/lib/avrxmega2/libm.a
/usr/avr/lib/avrxmega5/libm.a
/usr/avr/lib/avrxmega7/libm.a
/usr/avr/lib/avrtiny/libm.a
/usr/avr/lib/avrxmega4/libm.a
/usr/avr/lib/avr51/libm.a
/usr/avr/lib/avr31/libm.a
/usr/avr/lib/avr35/libm.a

 yet I seem to have all the other architectures...

Top
meolsen
meolsen's picture
Level: Site Admin
Joined: Wed. Jul 27, 2011
Posts: 3443 View posts
Location: Microchip, Arizona
Posted by meolsen: Mon. Nov 25, 2019 - 03:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe try the avr-gcc from  https://www.microchip.com/mplab/avr-support/avr-and-arm-toolchains-c-compilers ?

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98271 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Nov 25, 2019 - 03:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

roosta wrote:
 yet I seem to have all the other architectures..
it's quite possible that whoever built that for Fedora was not an expert and made a mistake. These days I'd trust Atmel/Microchip to be the experts in building cohesive releases of avr-gcc for Linux so I'd follow Morten's advice and take his build.

Top
roosta
roosta's picture
Level: New Member
Joined: Wed. Sep 18, 2019
Posts: 9 View posts
Posted by roosta: Mon. Nov 25, 2019 - 04:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, I will give the microchip toolchain a go!

Top
roosta
roosta's picture
Level: New Member
Joined: Wed. Sep 18, 2019
Posts: 9 View posts
Posted by roosta: Mon. Nov 25, 2019 - 04:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've downloaded the Atmel Toolchain and unpacked it into my working directory and also unpacked the attiny pack into the working directory.

 

Running

bin/avr-gcc -g -Wall -Os -I include -B gcc/dev/attiny1607 -mmcu=attiny1607 -o main.elf main.c                                                                                                     1 ↵
/home/matt/Downloads/AtTiny1607_test/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld: address 0x803c00 of main.elf section `.data' is not within region `data'
/home/matt/Downloads/AtTiny1607_test/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld: address 0x803c00 of main.elf section `.data' is not within region `data'
collect2: error: ld returned 1 exit status

So it's progress! Just another hurdle to jump :-)

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98271 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Nov 25, 2019 - 04:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

roosta wrote:
Just another hurdle to jump :-)
You clearly have too much data in SRAM. If anything is "const" then put it in __flash.

Top
roosta
roosta's picture
Level: New Member
Joined: Wed. Sep 18, 2019
Posts: 9 View posts
Posted by roosta: Mon. Nov 25, 2019 - 04:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But I'm just compiling an empty while loop

 

#include <avr/io.h>  
 
int main (void)
{
    
    while (1)  {     
    
    }
}

 

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98271 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Nov 25, 2019 - 04:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


0x803c00 sounds "odd" but then these new Xmega based Tinys are odd!

 

....

 

Ah, yes, datasheet confirms that is the base for SRAM in "linear" address space:

 

 

So it sounds like the .x file may be wrong ?!?

Top
MattRW
MattRW's picture
Level: Hangaround
Joined: Thu. Feb 14, 2019
Posts: 350 View posts
Location: Los Angeles area
Posted by MattRW: Mon. Nov 25, 2019 - 04:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can confirm the same error message with gcc-8.3.0 and devpack ATtiny_DFP-2.0.10.

 

/opt/local/libexec/gcc/avr/8.3.0/collect2 
	-plugin /opt/local/libexec/gcc/avr/8.3.0/liblto_plugin.so 
	-plugin-opt=/opt/local/libexec/gcc/avr/8.3.0/lto-wrapper 
	-plugin-opt=-fresolution=/tmp/ccO3kbOz.res 
	-plugin-opt=-pass-through=-lgcc 
	-plugin-opt=-pass-through=-lm 
	-plugin-opt=-pass-through=-lc 
	-plugin-opt=-pass-through=-lattiny1607 
	-mavrxmega3 -Tdata 0x803C00 
	-L/opt/local/avr/packs/tiny-2.0.10/lib/avrxmega3 
	--defsym=__RODATA_PM_OFFSET__=0x8000 
	/opt/local/avr/packs/tiny-2.0.10/lib/avrxmega3/crtattiny1607.o 
	-L/opt/local/lib/gcc/avr/8.3.0/avrxmega3 
	-L/opt/local/lib/gcc/avr/8.3.0/../../../../avr/lib/avrxmega3 
	-L/opt/local/avr/packs/tiny-2.0.10 
	-L/opt/local/lib/gcc/avr/8.3.0 
	-L/opt/local/lib/gcc/avr/8.3.0/../../../../avr/lib 
	/tmp/ccksiGhT.o 
	--start-group -lgcc -lm -lc -lattiny1607 --end-group
/opt/local/lib/gcc/avr/8.3.0/../../../../avr/bin/ld: address 0x803c00 of a.out section `.data' is not within region `data'

 

Top
MattRW
MattRW's picture
Level: Hangaround
Joined: Thu. Feb 14, 2019
Posts: 350 View posts
Location: Los Angeles area
Posted by MattRW: Mon. Nov 25, 2019 - 05:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't know what to make of this but avrxmega3.x says:

__DATA_REGION_LENGTH__ = DEFINED(__DATA_REGION_LENGTH__) ? __DATA_REGION_LENGTH__ : 0xffa0;

...
MEMORY 
{
   
  text   (rx)   : ORIGIN = 0, LENGTH = __TEXT_REGION_LENGTH__
  data   (rw!x) : ORIGIN = 0x802000, LENGTH = __DATA_REGION_LENGTH__
  eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = __EEPROM_REGION_LENGTH__
  fuse      (rw!x) : ORIGIN = 0x820000, LENGTH = __FUSE_REGION_LENGTH__
  lock      (rw!x) : ORIGIN = 0x830000, LENGTH = __LOCK_REGION_LENGTH__
  signature (rw!x) : ORIGIN = 0x840000, LENGTH = __SIGNATURE_REGION_LENGTH__
  user_signatures (rw!x) : ORIGIN = 0x850000, LENGTH = __USER_SIGNATURE_REGION_LENGTH__
}

 

Top
roosta
roosta's picture
Level: New Member
Joined: Wed. Sep 18, 2019
Posts: 9 View posts
Posted by roosta: Mon. Nov 25, 2019 - 05:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@MattRW - I saw the avrxmega3.x file too but need to some reading before I can understand what exactly it means...

Top
MattRW
MattRW's picture
Level: Hangaround
Joined: Thu. Feb 14, 2019
Posts: 350 View posts
Location: Los Angeles area
Posted by MattRW: Mon. Nov 25, 2019 - 06:15 PM (Reply to #25)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

roosta wrote:

@MattRW - I saw the avrxmega3.x file too but need to some reading before I can understand what exactly it means...

 

I read once but need to refresh.  See attached.

Attachment(s): 

PDF icon gnu-ld.pdf
Top
curtvm
curtvm's picture
Level: Raving Lunatic
Joined: Wed. Sep 21, 2005
Posts: 2732 View posts
Posted by curtvm: Mon. Nov 25, 2019 - 06:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is something going on with the linker and options provided. I have been using the avr toolchain version for quite a while on a mega4809 in mplabx, but now just discovered the problem which reveals itself on a smaller mcu.

 

What appears to be happening is the linker starts off with the data segment address and size- 0x802000 and the correct length. Then I believe the data segment gets its new address (to match the mcu) and continues. But as soon as you get over the original data address+length, you get the error. The crt.o files seem to have the address/length as weak symbols used with the linker script. How they make their way into the linker I'm not sure. I turned on verbose options but cannot see where it goes wrong.

 

To test, I grabbed the linker script, put it in the project dir, then modified-

 

/* added  , but not really needed, and may be best to leave this out so an error is produced if the symbol is not defined */ 

__DATA_REGION_ORIGIN__ = DEFINED(__DATA_REGION_ORIGIN__) ? __DATA_REGION_ORIGIN__ : 0x802000;

 

/* modified , this is all that is needed */

data   (rw!x) : ORIGIN = __DATA_REGION_ORIGIN__, LENGTH = __DATA_REGION_LENGTH__

 

so now the data origin starts off correct it seems. I can now use all of ram without complaint. I added to the linker misc options to use this script-

-script=avrxmega3.x

 

Maybe all the linker scripts from the avr toolchain and similar need this mod (for the xmega3 ld scripts).

 

Last Edited: Mon. Nov 25, 2019 - 08:37 PM
Top
MattRW
MattRW's picture
Level: Hangaround
Joined: Thu. Feb 14, 2019
Posts: 350 View posts
Location: Los Angeles area
Posted by MattRW: Mon. Nov 25, 2019 - 06:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is the output with "-M" flag passed to the linker.  Note that the "-Tdata 0x803C00" arguments direct the linker to start the data section at 0x803C00.

 

Archive member included to satisfy reference by file (symbol)

/opt/local/lib/gcc/avr/8.3.0/avrxmega3/libgcc.a(_exit.o)
                              /opt/local/avr/packs/tiny-2.0.10/lib/avrxmega3/crtattiny1607.o (exit)

Memory Configuration

Name             Origin             Length             Attributes
text             0x0000000000000000 0x0000000000004000 xr
data             0x0000000000802000 0x0000000000000400 rw !x
eeprom           0x0000000000810000 0x0000000000000100 rw !x
fuse             0x0000000000820000 0x0000000000000009 rw !x
lock             0x0000000000830000 0x0000000000000400 rw !x
signature        0x0000000000840000 0x0000000000000400 rw !x
user_signatures  0x0000000000850000 0x0000000000000400 rw !x
*default*        0x0000000000000000 0xffffffffffffffff

Linker script and memory map

Address of section .data set to 0x803c00
                0x0000000000008000                __RODATA_PM_OFFSET__ = 0x8000
LOAD /opt/local/avr/packs/tiny-2.0.10/lib/avrxmega3/crtattiny1607.o
LOAD /tmp/ccSTj9Xq.o
START GROUP
LOAD /opt/local/lib/gcc/avr/8.3.0/avrxmega3/libgcc.a
LOAD /opt/local/lib/gcc/avr/8.3.0/../../../../avr/lib/avrxmega3/libm.a
LOAD /opt/local/lib/gcc/avr/8.3.0/../../../../avr/lib/avrxmega3/libc.a
LOAD /opt/local/avr/packs/tiny-2.0.10/lib/avrxmega3/libattiny1607.a
END GROUP
                [0x0000000000004000]                __TEXT_REGION_LENGTH__ = DEFINED (__TEXT_REGION_LENGTH__)?__TEXT_REGION_LENGTH__:0x100000
                [0x0000000000000400]                __DATA_REGION_LENGTH__ = DEFINED (__DATA_REGION_LENGTH__)?__DATA_REGION_LENGTH__:0xffa0
                [0x0000000000000100]                __EEPROM_REGION_LENGTH__ = DEFINED (__EEPROM_REGION_LENGTH__)?__EEPROM_REGION_LENGTH__:0x10000
                [0x0000000000000009]                __FUSE_REGION_LENGTH__ = DEFINED (__FUSE_REGION_LENGTH__)?__FUSE_REGION_LENGTH__:0x400
                0x0000000000000400                __LOCK_REGION_LENGTH__ = DEFINED (__LOCK_REGION_LENGTH__)?__LOCK_REGION_LENGTH__:0x400
                0x0000000000000400                __SIGNATURE_REGION_LENGTH__ = DEFINED (__SIGNATURE_REGION_LENGTH__)?__SIGNATURE_REGION_LENGTH__:0x400
                0x0000000000000400                __USER_SIGNATURE_REGION_LENGTH__ = DEFINED (__USER_SIGNATURE_REGION_LENGTH__)?__USER_SIGNATURE_REGION_LENGTH__:0x400
                0x0000000000008000                __RODATA_PM_OFFSET__ = DEFINED (__RODATA_PM_OFFSET__)?__RODATA_PM_OFFSET__:0x8000

.hash
 *(.hash)

.dynsym
 *(.dynsym)

.dynstr
 *(.dynstr)

.gnu.version
 *(.gnu.version)

.gnu.version_d
 *(.gnu.version_d)

.gnu.version_r
 *(.gnu.version_r)

[... remove bloat ...]

.text           0x0000000000000000       0xa2
 *(.vectors)
 .vectors       0x0000000000000000       0x7c /opt/local/avr/packs/tiny-2.0.10/lib/avrxmega3/crtattiny1607.o
                0x0000000000000000                __vectors
                0x0000000000000000                __vector_default
 *(.vectors)
 *(.progmem.gcc*)
                0x000000000000007c                . = ALIGN (0x2)
                0x000000000000007c                __trampolines_start = .
 *(.trampolines)
 .trampolines   0x000000000000007c        0x0 linker stubs
 *(.trampolines*)
                0x000000000000007c                __trampolines_end = .
 *libprintf_flt.a:*(.progmem.data)
 *libc.a:*(.progmem.data)
 *(.progmem.*)
                0x000000000000007c                . = ALIGN (0x2)
 *(.lowtext)
 *(.lowtext*)
                0x000000000000007c                __ctors_start = .
 *(.ctors)
                0x000000000000007c                __ctors_end = .
                0x000000000000007c                __dtors_start = .
 *(.dtors)
                0x000000000000007c                __dtors_end = .
 SORT_BY_NAME(*)(.ctors)
 SORT_BY_NAME(*)(.dtors)
 *(.init0)
 .init0         0x000000000000007c        0x0 /opt/local/avr/packs/tiny-2.0.10/lib/avrxmega3/crtattiny1607.o
                0x000000000000007c                __init
 *(.init0)
 *(.init1)
 *(.init1)
 *(.init2)
 .init2         0x000000000000007c        0xc /opt/local/avr/packs/tiny-2.0.10/lib/avrxmega3/crtattiny1607.o
 *(.init2)
 [... remove bloat ...]
 *(.init9)
 .init9         0x0000000000000088        0x8 /opt/local/avr/packs/tiny-2.0.10/lib/avrxmega3/crtattiny1607.o
 *(.init9)
 *(.text)
 .text          0x0000000000000090        0x4 /opt/local/avr/packs/tiny-2.0.10/lib/avrxmega3/crtattiny1607.o
                0x0000000000000090                __vector_22
                0x0000000000000090                __vector_28
                0x0000000000000090                __vector_1
                0x0000000000000090                __vector_24
                0x0000000000000090                __vector_12
                0x0000000000000090                __bad_interrupt
                0x0000000000000090                __vector_6
                0x0000000000000090                __vector_3
                0x0000000000000090                __vector_23
                0x0000000000000090                __vector_30
                0x0000000000000090                __vector_25
                0x0000000000000090                __vector_11
                0x0000000000000090                __vector_13
                0x0000000000000090                __vector_17
                0x0000000000000090                __vector_19
                0x0000000000000090                __vector_7
                0x0000000000000090                __vector_27
                0x0000000000000090                __vector_5
                0x0000000000000090                __vector_4
                0x0000000000000090                __vector_9
                0x0000000000000090                __vector_2
                0x0000000000000090                __vector_21
                0x0000000000000090                __vector_15
                0x0000000000000090                __vector_29
                0x0000000000000090                __vector_8
                0x0000000000000090                __vector_26
                0x0000000000000090                __vector_14
                0x0000000000000090                __vector_10
                0x0000000000000090                __vector_16
                0x0000000000000090                __vector_18
                0x0000000000000090                __vector_20
 .text          0x0000000000000094        0xa /tmp/ccSTj9Xq.o
                0x0000000000000094                main
 .text          0x000000000000009e        0x0 /opt/local/lib/gcc/avr/8.3.0/avrxmega3/libgcc.a(_exit.o)
                0x000000000000009e                . = ALIGN (0x2)
 *(.text.*)
 .text.libgcc.mul
                0x000000000000009e        0x0 /opt/local/lib/gcc/avr/8.3.0/avrxmega3/libgcc.a(_exit.o)
 .text.libgcc.div
                0x000000000000009e        0x0 /opt/local/lib/gcc/avr/8.3.0/avrxmega3/libgcc.a(_exit.o)
 .text.libgcc   0x000000000000009e        0x0 /opt/local/lib/gcc/avr/8.3.0/avrxmega3/libgcc.a(_exit.o)
 .text.libgcc.prologue
                0x000000000000009e        0x0 /opt/local/lib/gcc/avr/8.3.0/avrxmega3/libgcc.a(_exit.o)
 .text.libgcc.builtins
                0x000000000000009e        0x0 /opt/local/lib/gcc/avr/8.3.0/avrxmega3/libgcc.a(_exit.o)
 .text.libgcc.fmul
                0x000000000000009e        0x0 /opt/local/lib/gcc/avr/8.3.0/avrxmega3/libgcc.a(_exit.o)
 .text.libgcc.fixed
                0x000000000000009e        0x0 /opt/local/lib/gcc/avr/8.3.0/avrxmega3/libgcc.a(_exit.o)
                0x000000000000009e                . = ALIGN (0x2)
 *(.fini9)
 .fini9         0x000000000000009e        0x0 /opt/local/lib/gcc/avr/8.3.0/avrxmega3/libgcc.a(_exit.o)
                0x000000000000009e                exit
                0x000000000000009e                _exit
 *(.fini9)
[... remove bloat ...]
 *(.fini1)
 *(.fini1)
 *(.fini0)
 .fini0         0x000000000000009e        0x4 /opt/local/lib/gcc/avr/8.3.0/avrxmega3/libgcc.a(_exit.o)
 *(.fini0)
 *(.hightext)
 *(.hightext*)
 *(.progmemx.*)
                0x00000000000000a2                . = ALIGN (0x2)
 *(.jumptables)
 *(.jumptables*)
                0x00000000000000a2                _etext = .

.rodata
 *(.rodata)
 *(.rodata*)
 *(.gnu.linkonce.r*)

.data           0x0000000000803c00        0x0 load address 0x00000000000000a2
                [!provide]                        PROVIDE (__data_start = .)
 *(.data)
 .data          0x0000000000803c00        0x0 /opt/local/avr/packs/tiny-2.0.10/lib/avrxmega3/crtattiny1607.o
 .data          0x0000000000803c00        0x0 /tmp/ccSTj9Xq.o
 .data          0x0000000000803c00        0x0 /opt/local/lib/gcc/avr/8.3.0/avrxmega3/libgcc.a(_exit.o)
 *(.data*)
 *(.gnu.linkonce.d*)
                0x0000000000803c00                . = ALIGN (0x2)
                0x0000000000803c00                _edata = .
                [!provide]                        PROVIDE (__data_end = .)

.bss            0x0000000000803c00        0x0
                [!provide]                        PROVIDE (__bss_start = .)
 *(.bss)
 .bss           0x0000000000803c00        0x0 /opt/local/avr/packs/tiny-2.0.10/lib/avrxmega3/crtattiny1607.o
 .bss           0x0000000000803c00        0x0 /tmp/ccSTj9Xq.o
 .bss           0x0000000000803c00        0x0 /opt/local/lib/gcc/avr/8.3.0/avrxmega3/libgcc.a(_exit.o)
 *(.bss*)
 *(COMMON)
                [!provide]                        PROVIDE (__bss_end = .)
                0x00000000000000a2                __data_load_start = LOADADDR (.data)
                0x00000000000000a2                __data_load_end = (__data_load_start + SIZEOF (.data))

.noinit         0x0000000000803c00        0x0
                [!provide]                        PROVIDE (__noinit_start = .)
 *(.noinit*)
                [!provide]                        PROVIDE (__noinit_end = .)
                0x0000000000803c00                _end = .
                [!provide]                        PROVIDE (__heap_start = .)

.eeprom         0x0000000000810000        0x0
 *(.eeprom*)
                0x0000000000810000                __eeprom_end = .

.fuse
 *(.fuse)
 *(.lfuse)
 *(.hfuse)
 *(.efuse)

.lock
 *(.lock*)

.signature
 *(.signature*)

[... remove bloat ...]

OUTPUT(a.out elf32-avr)
LOAD linker stubs/opt/local/lib/gcc/avr/8.3.0/../../../../avr/bin/ld: address 0x803c00 of a.out section `.data' is not within region `data'

edit: removed bloat from map file printout

Last Edited: Mon. Nov 25, 2019 - 08:34 PM
Top
curtvm
curtvm's picture
Level: Raving Lunatic
Joined: Wed. Sep 21, 2005
Posts: 2732 View posts
Posted by curtvm: Mon. Nov 25, 2019 - 06:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> Note that the "-Tdata 0x803C00" arguments direct the linker to start the data section at 0x803C00.

 

Yes, but that seems to come after the data section is started at 0x802000. The original address (fixed) + length (which is initially changed because of a symbol) seem to determine if the data is in a valid range.

 

It also appears the ld internal script is used by default, so it is no help to modify the avrxmega3.x script. So for now, modify the avrxmega3.x  script and either copy into project folder or leave where it is, then add a

-script=where/the/script/is/avrxmega3.x

so you use the modified script

 

 

 

Last Edited: Mon. Nov 25, 2019 - 06:56 PM
Top
MattRW
MattRW's picture
Level: Hangaround
Joined: Thu. Feb 14, 2019
Posts: 350 View posts
Location: Los Angeles area
Posted by MattRW: Mon. Nov 25, 2019 - 07:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

curtvm wrote:

So for now, modify the avrxmega3.x  script and either copy into project folder or leave where it is, then add a

-script=where/the/script/is/avrxmega3.x

so you use the odified script

 

 

This seems to work.   However, is support for the .xe .xr files needed?  I'm guessing one needs to trap a switch in the specs file for it, if so.

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98271 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Nov 25, 2019 - 07:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd just amend the .x and set a 0x803c00 base for .data

 

Not near a PC now but build a 1607 project is AS7 and take a look at the build options and the .x it uses.

Top
curtvm
curtvm's picture
Level: Raving Lunatic
Joined: Wed. Sep 21, 2005
Posts: 2732 View posts
Posted by curtvm: Mon. Nov 25, 2019 - 07:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

>I'd just amend the .x and set a 0x803c00 base for .data

 

That value is being passed in, so may as well use the symbol value so you don't have to modify for every avr0/1 you want to use.

(the upper bounding address for ram is fixed, the base changes)

 

 

> However, is support for the .xe .xr files needed?

I doubt it.

 

My two line modification really only needs the second line, and it may be better the leave out the first addition so you get an error if the data start address does not make it to the linker (instead of using the incorrect default value).

 

The xc8 builtin script is correct, and its sources show the avr.sc script template that matches. Not sure where the avr toolchain version went wrong with their scripts (can't seem to find the source code, although there is a thread about that somewhere).

 

It would also seem that passing in the Tdata address (which is happening) should take care of things, but apparently it does not. At least not in a correct manner.

Last Edited: Mon. Nov 25, 2019 - 08:12 PM
Top
MattRW
MattRW's picture
Level: Hangaround
Joined: Thu. Feb 14, 2019
Posts: 350 View posts
Location: Los Angeles area
Posted by MattRW: Mon. Nov 25, 2019 - 08:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I add linker argument "-r" (or avr-gcc argument "-Wl,-r") it seems to work w/o the mods.

I wonder if that induces the loader to read the non-default linker file.

 

main.c is

#include <avr/io.h>

char abc = 1;

int main() { 
  while (1);
}

$ nm a.out | grep abc

00803c00 D abc

 

Last Edited: Mon. Nov 25, 2019 - 08:10 PM
Top
gchapman
gchapman's picture
Level: 10k+ Postman
Joined: Tue. Jan 9, 2007
Posts: 11720 View posts
Location: Arlington, Texas, u.S.A.
Posted by gchapman: Mon. Nov 25, 2019 - 10:53 PM (Reply to #32)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

curtvm wrote:
Not sure where the avr toolchain version went wrong with their scripts (can't seem to find the source code, although there is a thread about that somewhere).
Where have Atmel avr-gcc sourcecode gone ? | AVR Freaks

leads to

AVR and SAM Downloads Archive | Microchip Technology

[3/4 page]

AVR GCC 3.6.2

 

"Dare to be naïve." - Buckminster Fuller

Top
curtvm
curtvm's picture
Level: Raving Lunatic
Joined: Wed. Sep 21, 2005
Posts: 2732 View posts
Posted by curtvm: Mon. Nov 25, 2019 - 11:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok.

Looks the same as xc8, so not sure how the data origin symbol goes missing from the linker scripts as it is in the script template file.

Top
SprinterSB
SprinterSB's picture
Level: Raving Lunatic
Joined: Thu. Dec 21, 2006
Posts: 2095 View posts
Location: Saar-Lor-Lux
Posted by SprinterSB: Tue. Nov 26, 2019 - 08:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you using Binutils with xmega3 support?
.
https://sourceware.org/PR21472
.
Is -Tdata passed to ld as expected?
.
-r is relocatable link if that is what you want.

avrfreaks does not support Opera. Profile inactive.

Last Edited: Tue. Nov 26, 2019 - 08:17 AM
Top
je_ruud
je_ruud's picture
Level: Moderator
Joined: Thu. Feb 14, 2002
Posts: 418 View posts
Location: Microchip, Norway
Posted by je_ruud: Tue. Nov 26, 2019 - 08:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

We have done some changes related to definitions of origin and length. This require both a new toolchain and new DFP.

 

Now, there's a couple of things that have gone wrong here:

- The ATtiny and ATmega DFPs should have had a requirement for at least avr-gcc-3.6.2.1778.

- avr-gcc-3.6.2.1778 was included in Studio 7.0.2389, but hasn't been released to web yet. But the linker script modifications in #27 is what's needed to make the old toolchain work with the new DFPs.

Top
SprinterSB
SprinterSB's picture
Level: Raving Lunatic
Joined: Thu. Dec 21, 2006
Posts: 2095 View posts
Location: Saar-Lor-Lux
Posted by SprinterSB: Tue. Nov 26, 2019 - 09:16 AM (Reply to #37)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Isn't it possible to provide device support in such a way that it works with different versions of the tools (provided they have core support)?
.
Because that is what developers will do: use device packs to augment the tools without native support, so they can compile and link projects to run on that device.
.
And the purpose of device-specs was exactly that: revamp a tools distribution so it can compile for some device *without* the need to recompile the tools. And the purpose was certainly not to dongle tools and device packs.

avrfreaks does not support Opera. Profile inactive.

Top
je_ruud
je_ruud's picture
Level: Moderator
Joined: Thu. Feb 14, 2002
Posts: 418 View posts
Location: Microchip, Norway
Posted by je_ruud: Tue. Nov 26, 2019 - 09:38 AM (Reply to #38)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, that was the whole point with creating the DFPs, and we do strive to keep them independent of each other. But some times there are changes we would like to do that causes some dependency.

This change were to improve the memory usage report, which has been a bit unreliable.

Top
MattRW
MattRW's picture
Level: Hangaround
Joined: Thu. Feb 14, 2019
Posts: 350 View posts
Location: Los Angeles area
Posted by MattRW: Tue. Nov 26, 2019 - 03:56 PM (Reply to #37)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

je_tudd,

 

Can you elaborate on this comment:

I added to the linker misc options to use this script

 

Does "-script=/path/to/avrxmega3.x" get added to "*link:" entry in specs-attiny1607 ?

 

I have

%rename link prev_link

 

*link:
        %(prev_link)  -script=/opt/local/avr/lib/ldscripts/avrxmega3.x

Top
El Tangas
El Tangas's picture
Level: Raving Lunatic
Joined: Thu. Jul 14, 2016
Posts: 2839 View posts
Posted by El Tangas: Tue. Nov 26, 2019 - 04:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm a bit lost here. What exactly was changed in the new DFP versions that is causing this error with other toolchains?

 

Testing from AS7 and a non-Microchip gcc 9.1.0:

 

If I pass this to the linker (older DFP version) everything links fine:

-B "$(PackRepoDir)\Atmel\ATtiny_DFP\1.3.229\gcc\dev\attiny817"

 

But if I pass this new DFP version:

-B "$(PackRepoDir)\Atmel\ATtiny_DFP\1.4.283\gcc\dev\attiny817"

 

 

I get the same link error as #19

 

edit: Ok, the crtxxx.o library seems to be incompatible and is causing this error.

 

edit2: further investigation with objdump shows that the new library version has a few extra symbols defined compared to the old one (the specific example here is from tiny817):

 

old:

...
00000000         *UND*  00000000 main
00000000         *UND*  00000000 exit
00000009  w      *ABS*  00000000 __FUSE_REGION_LENGTH__

 

new:

...
00000000         *UND*  00000000 main
00000000         *UND*  00000000 exit
00000000  w      *ABS*  00000000 __TEXT_REGION_ORIGIN__
00803e00  w      *ABS*  00000000 __DATA_REGION_ORIGIN__
0000000a  w      *ABS*  00000000 __FUSE_REGION_LENGTH__
00002000  w      *ABS*  00000000 __TEXT_REGION_LENGTH__
00000200  w      *ABS*  00000000 __DATA_REGION_LENGTH__
00000080  w      *ABS*  00000000 __EEPROM_REGION_LENGTH__

 

edit3:

So now the fix to the linker script and theory of error cause suggested in #27 make complete sense to me. I need to remember this thread, it has important information.

Last Edited: Tue. Nov 26, 2019 - 05:56 PM
Top
curtvm
curtvm's picture
Level: Raving Lunatic
Joined: Wed. Sep 21, 2005
Posts: 2732 View posts
Posted by curtvm: Tue. Nov 26, 2019 - 08:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

summary-

 

A linker script is not specified anywhere in the build process, so the builtin linker script is used by avr-ld. (edit- actually not true, is using xn version from ldscripts folder)
The builtin linker script has the data MEMORY region set to a fixed address (0x802000), but should be using a crt*.o provided symbol. (edit- but is also true of the script file)
The crt*.o startup file (by mcu in use) is LOADed by the linker to get its symbols, like __DATA_REGION_ORIGIN__, etc.
The device specs provides the Tdata option, but is of no value here as the .data SECTION is not the data MEMORY region.
Since the Tdata option is used, the .data SECTION is now moved 'up', but the data MEMORY region does not change- causing the .data addresses in use to possibly exceed the data MEMORY region.

 

  simple example-

  MEMORY -> data region 0x1000, data length 0x100
  command line option -> -Tdata=0x1200
  first use of anything in the .data SECTION will be 0x1200, but that address is not in the data MEMORY region (0x1000-0x1100)

 

This probably points out that the use of Tdata is of no value here, and may have also been used incorrectly in the past. In this case it results in the error as we have the unusual moving base address of ram for the avr0/1. If moving .data from 0x800060 (MEMORY origin) to 0x800100 via Tdata (old avr), you just caused a similar problem but its more of a beneficial problem as you get an error before you used up all the ram. I don't know if this is actually the case, but I think they have always been passing Tdata to move the ram start address when needed, so I imagine this 'problem' has always been around.

Last Edited: Wed. Nov 27, 2019 - 03:04 AM
Top
je_ruud
je_ruud's picture
Level: Moderator
Joined: Thu. Feb 14, 2002
Posts: 418 View posts
Location: Microchip, Norway
Posted by je_ruud: Tue. Nov 26, 2019 - 09:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Basically curtvm is right.

 

This problem has been around for a while, and we're now trying to fix it.

The new DFPs will try to provide symbols for both __DATA_REGION_ORIGIN__ and __DATA_REGION_LENGTH__, but only __DATA_REGION_LENGTH__ is a weak symbol in the builtin linker script so we're not able to override ORIGIN.

When building for tiny1607 with the new DFP and a avr-gcc version <3.6.2.1778 the ORIGIN will be 0x2000 and the LENGTH will be overridden to 0x400, giving the range 0x2000-0x2400. When you compile your application the .data section, which starts at 0x3C00, will fall outside the DATA_REGION and the linker throws an error.

 

What avr-gcc version 3.6.2.1778 does is making ORIGIN a weak symbol too.

Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4246 View posts
Location: SF Bay area
Posted by westfw: Wed. Nov 27, 2019 - 02:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The new DFPs will try to provide symbols for both __DATA_REGION_ORIGIN__ and __DATA_REGION_LENGTH__ [in the ctrxxxx.o files]

How will this affect builds with :-nostartfiles"?  (not that they're likely to have a .data section, anyway.)

 

(incidentally, my "like this" example was from a bootloader with no ".data" and with "-nostartfiles", so it probably would have worked fine even when normal programs would have had the errors that were seen!)

 

Top
curtvm
curtvm's picture
Level: Raving Lunatic
Joined: Wed. Sep 21, 2005
Posts: 2732 View posts
Posted by curtvm: Wed. Nov 27, 2019 - 02:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm sort of providing some misinformation, and if I was paying attention I could do better :(

 

Let me revise a little. The linker is not using a builtin script, it is grabbing it from avr/lib/ldscripts-

./avr-ld -m avrxmega3 -verbose

 

opened script file /opt/avr8-gnu-toolchain-linux_x86_64/bin/../avr/lib/ldscripts/avrxmega3.xn using external linker script:

 

I missed that little piece of info, and it appears to be grabbing the xn version of the script (which is the same as the x version). So I edit the avrxmega3.xn script to use __DATA_REGION_ORIGIN__ (replace 0x802000). Then create some projects to verify- working ok. Somehow my original thought was the x version would be used, and didn't see any change when that was edited so assumed a builtin script was being used.

 

So it appears that simply editing one linker script will take care of things and there is no need to pass a linker script option as I previously said.
 

Last Edited: Wed. Nov 27, 2019 - 02:59 AM
Top
El Tangas
El Tangas's picture
Level: Raving Lunatic
Joined: Thu. Jul 14, 2016
Posts: 2839 View posts
Posted by El Tangas: Wed. Nov 27, 2019 - 02:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

curtvm wrote:
The device specs provides the Tdata option, but is of no value here as the .data SECTION is not the data MEMORY region.
Since the Tdata option is used, the .data SECTION is now moved 'up', but the data MEMORY region does not change- causing the .data addresses in use to possibly exceed the data MEMORY region.

 

Interestingly, during my earlier experiments with UPDI, I dumped the whole address space of a tiny1614 MCU and observed that the RAM is aliased at 0x1800, 0x2000, 0x2800, etc. in 2kB increments (this is the RAM size for this chip). The "official" address of RAM in this chip is 0x3800, which is of course part of this sequence.

So actually, I wouldn't be surprised if changing Tdata to 0x802000 would result in working code. I have to test it, maybe tomorrow.

Top
MattRW
MattRW's picture
Level: Hangaround
Joined: Thu. Feb 14, 2019
Posts: 350 View posts
Location: Los Angeles area
Posted by MattRW: Wed. Nov 27, 2019 - 03:08 PM (Reply to #45)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

curtvm wrote:

 

So it appears that simply editing one linker script will take care of things and there is no need to pass a linker script option as I previously said.
 

 

Thanks.   I have generated a shell script to fix the files in ldscripts and run it on my gcc-8.3.0 installation.  I'm leaving the specs-attiny1607 file alone.

(the popup for including code (<>) seems to be hosed, at least on my machine)

 

#!/bin/sh
#
# fix-ldscript
#   example usage: fix-ldscript .../ldscripts/avrxmega3.x
#
# This script updates the data memory specification in the ldscript provided
# by the AVR port of GNU binutils.  It does not provide a default address for
# the data section: the ld command is expected to include "-Tdata <address>"
# arguments.
#
# v191126a - MattRW
#
# ref: https://www.avrfreaks.net/commen...

already_fixed () {
  file=$1
  if [ -f ,orig/${file} ]; then
    return 1
  else
    return 0
  fi
}

fixit () {
  file=$1
  mv $file ,orig/${file}
  cp ,orig/${file} $file
  ed -s $file >/dev/null << 'EndOfInput'
/data .*ORIGIN = 0x
s/ORIGIN = 0x[0-9A-Fa-f]*,/ORIGIN = __DATA_REGION_ORIGIN__,/
wq
EndOfInput
}

dir=`dirname $1`
file=`basename $1`

cd $dir
mkdir -p ,orig
if [ ! `already_fixed $file` ]; then
  fixit $file
fi

# --- last line ---

 

 

Top
curtvm
curtvm's picture
Level: Raving Lunatic
Joined: Wed. Sep 21, 2005
Posts: 2732 View posts
Posted by curtvm: Wed. Nov 27, 2019 - 03:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

LDSDIR=/opt/avr8-gnu-toolchain-linux_x86_64/avr/lib/ldscripts/
sed -i.bak 's/0x802000/__DATA_REGION_ORIGIN__/' $(find $LDSDIR -type f -name 'avrxmega3*')

Top
MattRW
MattRW's picture
Level: Hangaround
Joined: Thu. Feb 14, 2019
Posts: 350 View posts
Location: Los Angeles area
Posted by MattRW: Wed. Nov 27, 2019 - 03:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice.  I thought of using "sed", but  I like the "ed" approach because if other required changes come up it provides a lot more functionality.

Top
roosta
roosta's picture
Level: New Member
Joined: Wed. Sep 18, 2019
Posts: 9 View posts
Posted by roosta: Fri. Dec 6, 2019 - 11:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Sorry to drag up an old thread - but I just wanted to thank all that helped solve this issue.

 

I now have blinking LEDs smiley

Top