AVR Toolchain - incorrect startup code for ATMega2561

Go To Last Post

20 posts / 0 new

Author

Message

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3270 View posts

Location: Bratislava, Slovakia

Posted by wek: Thu. Jun 30, 2011 - 10:44 AM

c:\tmp>"c:\Program Files\Atmel\AVRTools\AVRToolchain\bin\avr-gcc" --version
avr-gcc (AVR_8_bit_GNU_Toolchain_3.2.3_314) 4.5.1

c:\tmp>"c:\Program Files\Atmel\AVRTools\AVRToolchain\bin\avr-gcc" w.c -Os -DF_CPU=14745600UL -mmcu=atmega2561 -Wa,-adhlns=w.lst -Wl,-Map=w.map,--cref -o w.elf

w.c:

char a1[] = "abcdefghijklmnopqrstuvwxyz";

void foo1(void) {
  __asm(
".skip 70000,0 \n\t"
  );
}


int main(void) {
}

relevant portion of w.lss:

000000dc <__do_copy_data>:
      dc:	12 e0       	ldi	r17, 0x02	; 2
      de:	a0 e0       	ldi	r26, 0x00	; 0
      e0:	b2 e0       	ldi	r27, 0x02	; 2
      e2:	e4 e7       	ldi	r30, 0x74	; 116
      e4:	f2 e1       	ldi	r31, 0x12	; 18
      e6:	02 c0       	rjmp	.+4      	; 0xec <.do_copy_data_start>

000000e8 <.do_copy_data_loop>:
      e8:	05 90       	lpm	r0, Z+
      ea:	0d 92       	st	X+, r0

000000ec <.do_copy_data_start>:
      ec:	ac 31       	cpi	r26, 0x1C	; 28
      ee:	b1 07       	cpc	r27, r17
      f0:	d9 f7       	brne	.-10     	; 0xe8 <.do_copy_data_loop>

The same, when compiled using WinAVR20100110:

000000dc <__do_copy_data>:
      dc:	12 e0       	ldi	r17, 0x02	; 2
      de:	a0 e0       	ldi	r26, 0x00	; 0
      e0:	b2 e0       	ldi	r27, 0x02	; 2
      e2:	e8 e8       	ldi	r30, 0x88	; 136
      e4:	f2 e1       	ldi	r31, 0x12	; 18
      e6:	01 e0       	ldi	r16, 0x01	; 1
      e8:	0b bf       	out	0x3b, r16	; 59
      ea:	02 c0       	rjmp	.+4      	; 0xf0 <__do_copy_data+0x14>
      ec:	07 90       	elpm	r0, Z+
      ee:	0d 92       	st	X+, r0
      f0:	ac 31       	cpi	r26, 0x1C	; 28
      f2:	b1 07       	cpc	r27, r17
      f4:	d9 f7       	brne	.-10     	; 0xec <__do_copy_data+0x10>

Spot two differences :-)

(PS. verified by disassembling the respective lib that the error is indeed in incorrectly compiled crt)

Tags:

Tools, Atmel Studio (AVR-related), ATmega2561

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101172 View posts

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

Posted by clawson: Thu. Jun 30, 2011 - 12:04 PM

Quote:

Spot two differences

'e' ?

Do I win a prize?

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3270 View posts

Location: Bratislava, Slovakia

Posted by wek: Thu. Jun 30, 2011 - 12:24 PM

Bingo! :-)

Quote:

Do I win a prize?

I'll put aside a couple of beers in my cellar, or a bottle of wine or two... but what are the odds of an opportunity to hand them over? :-(

Jan

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101172 View posts

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

Posted by clawson: Thu. Jun 30, 2011 - 01:08 PM

I think faults in the CRT of other models have been identified previously (not this ELPM thing) so it sounds like their whole infrastructure for building the LibC may be FUBAR. Roll on the next WinAVR...

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3270 View posts

Location: Bratislava, Slovakia

Posted by wek: Thu. Jun 30, 2011 - 01:29 PM

clawson wrote:

I think faults in the CRT of other models have been identified previously [...]

Oh, I suspected that... I don't follow the AS5 issue too closely. Tried to search briefly but did not want to waste too much time.

clawson wrote:

[...] so it sounds like their whole infrastructure for building the LibC may be FUBAR. Roll on the next WinAVR...

It surely needs time and feedback, but I would avoid to be the first to throw a stone...

Projects I am working on are surely orders of magnitude smaller than 'gcc and 'libc and stuff; yet I often find that a small and seemingly insignificant change results in a cascade of effects and ultimately of a surprising error in a completely different place... It's not easy (an euphemism for "impossible") to predict all possible ways how complex software can go wrong. One might argue that testing should be catching these, but how exactly are you going to test the unforeseen?

Jan

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3270 View posts

Location: Bratislava, Slovakia

Posted by wek: Thu. Jun 30, 2011 - 01:33 PM

Meantime, a quick fix for those who want to use the ATMega256x within the AS5/Toolchain environment: simply put the following lines (which is just a slightly adopted (inlined) version of this routine from gcrt1.S from avr-libc, credits go there) somewhere into your C sources:

  void __do_copy_data(void) __attribute__((__section__(".init4"), __naked__));
  void __do_copy_data(void) {
    __asm__(
   "   ldi r17, hi8(__data_end)                                                 \n"
   "   ldi r26, lo8(__data_start)                                               \n"
   "   ldi r27, hi8(__data_start)                                               \n"
   "   ldi r30, lo8(__data_load_start)                                          \n"
   "   ldi r31, hi8(__data_load_start)                                          \n"
   "                                                                            \n"
   "                                                                            \n"
   "   ldi r16, hh8(__data_load_start)                                          \n"
   "   out %[_RAMPZ], r16                                                  \n"
   "   rjmp  .L__do_copy_data_start                                             \n"
   " .L__do_copy_data_loop:                                                     \n"
   "   elpm  r0, Z+                                                             \n"
   "   st  X+, r0                                                               \n"
   " .L__do_copy_data_start:                                                    \n"
   "   cpi r26, lo8(__data_end)                                                 \n"
   "   cpc r27, r17                                                             \n"
   "   brne  .L__do_copy_data_loop                                              \n"
   :
   :  [_RAMPZ]    "I" (_SFR_IO_ADDR(RAMPZ))
    );
  }

SprinterSB

Level: Raving Lunatic

Joined: Thu. Dec 21, 2006

Posts: 2108 View posts

Location: Saar-Lor-Lux

Posted by SprinterSB: Sat. Oct 15, 2011 - 09:10 PM

wek wrote:

Meantime, a quick fix for those who want to use the ATMega256x within the AS5/Toolchain environment: simply put the following lines (which is just a slightly adopted (inlined) version of this routine from gcrt1.S from avr-libc, credits go there) somewhere into your C sources:
void __do_copy_data(void) __attribute__((__section__(".init4"), __naked__));

The original __do_copy_data is already in .init4 and if there is more than one function in an init section their order is unspecified. So you may want to put it later than .init4 but befor running ctors from .init6 and thus in .init5.

avrfreaks does not support Opera. Profile inactive.

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3270 View posts

Location: Bratislava, Slovakia

Posted by wek: Sat. Oct 15, 2011 - 10:26 PM

If I did not overlook something, if you put it directly into the application sources, it won't bring in the library version. Or do I miss something?

florin

Level: Rookie

Joined: Tue. Mar 4, 2003

Posts: 29 View posts

Location: Nyköping, Sweden

Posted by florin: Fri. Jan 20, 2012 - 12:12 PM

For some unknown reason this fix doesn't work on my xmega128a1. I could however copy crtx128a1.o from WinAVR-20100110 toolchain into Atmels AVR_Toolchain_3_2_3_579. It's really hard to understand why this still is not fixed by Atmel. Or is it maybe fixed in the AS5 release only but not in the freestanding toolchain?

bngn

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101172 View posts

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

#10

Posted by clawson: Fri. Jan 20, 2012 - 12:22 PM

Quote:

It's really hard to understand why this still is not fixed by Atmel.

Have you got 5.1Beta or 5.0 ? It's possible it *might* have been fixed between the two.

florin

Level: Rookie

Joined: Tue. Mar 4, 2003

Posts: 29 View posts

Location: Nyköping, Sweden

#11

Posted by florin: Fri. Jan 20, 2012 - 09:31 PM

Yes, you could be right there. I just use the toolchain part 3.2.3-579 as it seems to be the latest on Atmels site. JW refers to build 314 so obviously a significant amount of builds have been done without correcting this both trivial and fatal error anyhow.
I think it was a lot better in the good old WinAVR-days. Some of us don't want a new 390MB Studio for each and every piece of silicon we are working with.
Simple and stupid (but correct!), is perfectly fine with me.

bngn

planius

Level: Rookie

Joined: Sat. Jan 26, 2008

Posts: 21 View posts

Location: Melbourne, Australia

#12

Posted by planius: Sat. Jun 30, 2012 - 10:17 AM

I just switched to AVR Studio 5.1 and it seems this fix no longer works? Haven't made any other changes to the code...
Commenting out the fix doesn't seem to work, either.
Has someone else checked this with AVR Studio 5.1?

JohanEkdahl

Level: 10k+ Postman

Joined: Wed. Mar 27, 2002

Posts: 26945 View posts

Location: Lund, Sweden

#13

Posted by JohanEkdahl: Sat. Jun 30, 2012 - 11:03 AM

Quote:

I just switched to AVR Studio 5.1

If you switched, why not to the latest Atmel Studio 6? Not that I can promise that it is fixed there, but still, it is a version that is maintained.

Please understand that, for 8-bit AVR and XMega AVR work, Atmel Studio 6 is more or less AVR Studio 5.2 . The reason for the major jump is that Atmel Studio 6 also does Atmels ARM chips (of no consequence for AVR users).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

planius

Level: Rookie

Joined: Sat. Jan 26, 2008

Posts: 21 View posts

Location: Melbourne, Australia

#14

Posted by planius: Sat. Jun 30, 2012 - 11:40 AM

Ok, repeated the same thing with AVR Studio 6, same result. The fix no longer works and it doesn't work without the fix, either.

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3270 View posts

Location: Bratislava, Slovakia

#15

Posted by wek: Mon. Jul 2, 2012 - 02:06 PM

How did you come to the conclusion that you are hit by the same problem as in the initial post of this thread?

Can you please post the relevant portion of .lss (i.e. the __do_copy_data routine)?

I've just tried avr-gcc (AVR_8_bit_GNU_Toolchain_3.3.2_485) 4.5.1 which IIRC is the one from AS5.1, and it uses elpm as it should.

PS. The "fix" works with the 3.3.2_485 toolchain too.

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101172 View posts

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

#16

Posted by clawson: Mon. Jul 2, 2012 - 02:21 PM

Quote:

which IIRC is the one from AS5.1,

No one should be using 5.1 at this stage. AS6 contains 4.6.2

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3270 View posts

Location: Bratislava, Slovakia

#17

Posted by wek: Mon. Jul 2, 2012 - 02:32 PM

I don't have the "toolchain" from AS6 - AFAIK it hasn't been released as standalone, and I am absolutely not interested in ASxy as such.

But I doubt it would regress in regard of this particular bug.

planius

Level: Rookie

Joined: Sat. Jan 26, 2008

Posts: 21 View posts

Location: Melbourne, Australia

#18

Posted by planius: Mon. Jul 2, 2012 - 10:27 PM

Yes, my mistake. It's not this issue that caused my code to break when upgrading from AVR Studio 5.0 to 5.1/6.0, even though it looked like it at first. I have spent the last 3 days investigating and have now excluded this bug. It's something else related to to using PROGMEM that must have changed in 5.1/6.0, but I haven't figured out what yet...

larryvc

Level: Raving Lunatic

Joined: Thu. Dec 6, 2007

Posts: 4229 View posts

Location: Redmond, WA, USA

#19

Posted by larryvc: Mon. Jul 2, 2012 - 11:25 PM

How about posting some of the code that causes the errors? Perhaps a new thread would be a good place to do that. There are some issues with PROGMEM changes. PROGMEM variables need to be CONST.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." - Marcus Aurelius

planius

Level: Rookie

Joined: Sat. Jan 26, 2008

Posts: 21 View posts

Location: Melbourne, Australia

#20

Posted by planius: Tue. Jul 3, 2012 - 12:50 AM

Yes, will do. Have made the change to CONST already.
https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=971051#971051

Jump To

Search form

AVR Toolchain - incorrect startup code for ATMega2561

Tags: