Failing linker with new device pack, ATtiny 0-series

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AS7 versus MPLABX

 

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

>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.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

>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.

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


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 ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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...