Failing linker with new device pack, ATtiny 0-series

Go To Last Post

16 posts / 0 new

Author

Message

vfz

Level: New Member

Joined: Tue. Jun 25, 2019

Posts: 15 View posts

Location: Sweden

Posted by vfz: Thu. Mar 12, 2020 - 07:58 AM

I have been developing for the 0- and 1-series ATtinies for some time and have been using avr-gcc under linux with device pack version 1.3.229. When setting up my build environment on a new computer I instead used the latest device pack with version 1.4.301. Compiling a super simple project for ATtiny202, without any hard coded addresses or such, then resulted in the output:

/home/d/devel/avr/toolchain/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld: address 0x803f80 of main.elf section `.data' is not within region `data'
/home/d/devel/avr/toolchain/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld: address 0x803f81 of main.elf section `.bss' is not within region `data'
/home/d/devel/avr/toolchain/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld: address 0x803f80 of main.elf section `.data' is not within region `data'
/home/d/devel/avr/toolchain/avr8-gnu-toolchain-linux_x86_64/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld: address 0x803f81 of main.elf section `.bss' is not within region `data'
collect2: error: ld returned 1 exit status

I then installed and used the older device pack 1.3.229 and everything worked. Should this be a bug report to Microchip or am I missing something fundamental?

I use a make bash-script that looks like this:

#!/bin/bash

GCCPATH="$HOME/devel/avr/toolchain/avr8-gnu-toolchain-linux_x86_64/bin"
BPATH="$HOME/devel/avr/toolchain/Atmel.ATtiny_DFP.1.3.229.atpack_FILES/gcc/dev/attiny202"
IPATH="$HOME/devel/avr/toolchain/Atmel.ATtiny_DFP.1.3.229.atpack_FILES/include"

$GCCPATH/avr-gcc -Wall -mmcu=attiny202 -Os -B $BPATH -I $IPATH main.c -o main.elf

Thanks!

Long time AVR user but more fond of analog electronics than compiler details...

Tags:

AVR Microcontrollers, megaAVR and tinyAVR

curtvm

Level: Raving Lunatic

Joined: Wed. Sep 21, 2005

Posts: 3105 View posts

Posted by curtvm: Thu. Mar 12, 2020 - 11:59 AM

I would start by getting into the 2's-

https://packs.download.microchip...

they have old links with old versions. you just have to poke around to find the latest.

If you have not already done so, in this linker file-

avr8-gnu-toolchain-linux_x86_64/avr/lib/ldscripts/avrxmega3.xn

change this line-

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

to-

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

I'm not sure where your error originates, but the .data section bumping into things means the data region is not getting set correctly which the linker change above takes care of. The first part of the solution is done in the crt.o file which has the symbol defined for linker use. The linker script in your toolchain doesn't take advantage and you get a combo of .data section and data region that will cause a problem (.data section and data region are not the same thing). It is a problem that only shows up it avr0/1 because of its 'fixed' upper ram address and variable lower addresses along with the incorrect use of Tdata.

vfz

Level: New Member

Joined: Tue. Jun 25, 2019

Posts: 15 View posts

Location: Sweden

Posted by vfz: Thu. Mar 12, 2020 - 01:04 PM

curtvm wrote:

I would start by getting into the 2's-

https://packs.download.microchip...

they have old links with old versions. you just have to poke around to find the latest.

Why do they have these packs, with version numbers 2.x.x for ATtinies, and simultaneously at packs.download.atmel.com another range of packs, with versions 1.4.301 etc??

Long time AVR user but more fond of analog electronics than compiler details...

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 100762 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

Posted by clawson: Thu. Mar 12, 2020 - 01:31 PM

AS7 versus MPLABX

Two IDEs - two different sets of packs - don't ask!

vfz

Level: New Member

Joined: Tue. Jun 25, 2019

Posts: 15 View posts

Location: Sweden

Posted by vfz: Thu. Mar 12, 2020 - 02:16 PM

Strange and confusing!

Ok, going back to curtvm's answer -

Thank you for pointing out that proposed change. But that file is coming from the avr-gcc toolchain package and not the device pack(s). So do you think it is something that should be reported as a bug to Microchip?

Long time AVR user but more fond of analog electronics than compiler details...

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 100762 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

Posted by clawson: Thu. Mar 12, 2020 - 02:40 PM

vfz wrote:

So do you think it is something that should be reported as a bug to Microchip?

I have a pretty strong feeling that they cannot have failed to spot the myriad threads about it on here! ;-)

I suppose for "belts and braces" you could open a support ticket but I think it's just going to get put on a very large "duplicate" pile ;-)

(someone on here has a script that auto-edits all your .x* files to correct all that may be involved)

curtvm

Level: Raving Lunatic

Joined: Wed. Sep 21, 2005

Posts: 3105 View posts

Posted by curtvm: Thu. Mar 12, 2020 - 07:29 PM

>someone on here has a script that auto-edits all your .x* files to correct all that may be involved)

Here is the short version-

https://www.avrfreaks.net/commen...

a longer version in previous post.

(I think this is the original thread on the issue)

Either script is not necessary as the only file used for avr0/1 is avrxemga3.xn, so just edit the 1 file manually. Any toolchain version you use, first thing to do is edit the one file. Eventually those who put out an avr toolchain will correct the problem, but for now you just take care of the problem yourself.

vfz

Level: New Member

Joined: Tue. Jun 25, 2019

Posts: 15 View posts

Location: Sweden

Posted by vfz: Fri. Mar 13, 2020 - 08:09 AM

Thank you guys. Then I am happy for the time being :)

Long time AVR user but more fond of analog electronics than compiler details...

Orbifreak

Level: New Member

Joined: Wed. May 12, 2004

Posts: 4 View posts

Location: Slovenija

Posted by Orbifreak: Fri. Mar 13, 2020 - 12:10 PM

I have the same problem with QTouch project on Tiny1616 with 6 touch buttons.

Here are my actions:

1.Compiling in Ubuntu 16.04 gives result from 1st post from vtz.

- avr-gcc -- version gives : (AVR_8_bit_GNU_Toolchain_3.6.2_1759) 5.4.0

This is the latest version from microchip.

2.I imported then the same *.atzip from AtmelStart to AS7 on win8.1. The same result.

3.I updated AS7 to last version(7.0.2397). Success! Flashing my hardware. Works beautifuly.

- avr-gcc.exe -- version gives : (AVR_8_bit_GNU_Toolchain_3.6.2_1778) 5.4.0

4.But my development is in Linux. So I used linker file hack by curtvm. Compilation then works perfectly. Flashing my hardware. Fails miserably. Hardware is unresponsive. Flashing again with *.hex from windows - works like before.

Tried with older packs. Compilation still works, but resulting code doesn't.

Resulting *.lss files from win and Linux are completely different.

Now I just nervously checking AVR Toolchain for Linux in hope to see new dates on this page.

I will be very happy to hear any new ideas on this topic.

I just wonder, if Microchip developers (I am sure, they checking this forum) wants us to only use Windows.

Thank you in advance for any response.

vfz

Level: New Member

Joined: Tue. Jun 25, 2019

Posts: 15 View posts

Location: Sweden

#10

Posted by vfz: Fri. Mar 13, 2020 - 12:55 PM (Reply to #9)

Perhaps you could use an older device pack like I did to solve the problem? I am also working in a linux environment.

Long time AVR user but more fond of analog electronics than compiler details...

Orbifreak

Level: New Member

Joined: Wed. May 12, 2004

Posts: 4 View posts

Location: Slovenija

#11

Posted by Orbifreak: Fri. Mar 13, 2020 - 01:42 PM

Tried with older packs. Compilation still works, but resulting code doesn't.

I installed MPLAB X IDE v5.35, but it comes without any compiling tools. So when you use existing version of AVR Toolchain for Linux, which gives the same bad result as compiling with bare makefile.

curtvm

Level: Raving Lunatic

Joined: Wed. Sep 21, 2005

Posts: 3105 View posts

#12

Posted by curtvm: Fri. Mar 13, 2020 - 02:21 PM

>Resulting *.lss files from win and Linux are completely different.

Then you have something else going on, like different optimization, or linker optimization settings, not linking in a touch library, etc. Completely different doesn't happen without some help, as the compiler and packs are minimally different. The updates to the 'packs' seem to be mostly the things you would expect- odds and ends in the headers like a missing or wrong defines, and there is very little code in them- a startup file and some eewrite functions in a library.

I use the avr toolchain version from atmelchip, and also an avr toolchain 7.3.0 from arduino. They all work fine with the single linker script fix. I use mplabx in linux, and have been for a long time without problems no matter which 'pack' version happens to be in use. I use attiny416/817, atmega4809.

Orbifreak

Level: New Member

Joined: Wed. May 12, 2004

Posts: 4 View posts

Location: Slovenija

#13

Posted by Orbifreak: Fri. Mar 13, 2020 - 05:20 PM (Reply to #12)

I didnt change anything - just original makefile from AtmelStart on Linux and default settings on AS7 on Win8.1.

This is my first go with QTouch library which is quite compleks and closed source. With my code I didn't have any problems.

I am not in a hurry, so i will wait a little for new version of AVR Toolchain, before i start debugging. The fact - win version works - is killing my stamina.

But i can't define what i ment with 'completely different' - so here are both lss files.

Linux lss (generated with AtmelStart makefile included in *.atzip - linker file corrected like you suggested ):

Windows lss:(generated by default settings with latest AS7)

Both lss files are in attachments.

Attachment(s):

6tipk_t1616a_lin.lss_.txt

6tipk_t1616a_win.lss_.txt

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 100762 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#14

Posted by clawson: Fri. Mar 13, 2020 - 04:42 PM

Can't help thinking that could have gone better as two file attachments (or a zip?) with .lss renames to .lss.txt

I diffed them:

but one of the major changes seems to be the link order. In one you find almost the first thing are functions such as CPUINT_init and touch_init whereas in the other they are placed much later so it makes a one-to-one comparison almost impossible.

What I guess one could do is take it one function at a time, isolate that and just diff the single functions. Such as:

Obviously the address and opcode byes (that embed addresses) are going to be different in this but the first thing that jumps out at me from comparing just this one function is VPORTA_OUT=2 versus VPORTA_OUT=8. This is not just a difference in the generated code/address but the source itself is different. if that one line of source is different how many others are too ?

Orbifreak

Level: New Member

Joined: Wed. May 12, 2004

Posts: 4 View posts

Location: Slovenija

#15

Posted by Orbifreak: Fri. Mar 13, 2020 - 05:15 PM (Reply to #14)

Wow! This is great.

You found the only different line! (LED after RESET to see what code version is in flash: linux or win, but linux never worked !)

In attachments are the only files from AtmelStart.atzip I changed.

Hardware is very simple. 6 pins for touch buttons and 6 pins for LEDs.

Attachment(s):

main.c

touch_example.c

vfz

Level: New Member

Joined: Tue. Jun 25, 2019

Posts: 15 View posts

Location: Sweden

#16

Posted by vfz: Mon. Mar 16, 2020 - 09:08 AM

For reference, I think my original question is answered simply by this comment: https://www.avrfreaks.net/commen...

Long time AVR user but more fond of analog electronics than compiler details...

Jump To

Search form