AVR Toolchain - incorrect startup code for ATMega2561

Go To Last Post
20 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
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 :-)

JW

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

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

Quote:

Spot two differences

'e' ?

Do I win a prize?

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

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

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

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

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

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

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

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))
    );
  }

JW

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

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.

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

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?

JW

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

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

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

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.

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

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

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

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?

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

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]

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

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.

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

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.

JW

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

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

Quote:

which IIRC is the one from AS5.1,

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

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

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.

JW

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

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

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

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

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

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