ATmega1280 code > 65 KBytes?

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

Hi all,

I have run into this consistently over the last weeks and I finally cannot avoid it. I am using an ATmega1280 with C code, the AVR library, and FreeRTOS. As my compiled code comes close to the 65536 byte boundary, the GNU linker seems to go nuts -- it starts overlaying parts of the AVRlib code into other parts of code.

seems to be intermixed with , among other weirdness. This conclusion comes from both the .lss file and from debugging the code with JTAGICE mkII.

I have not found a simple example of this, unfortunately. Just setting up sections in high memory doesn't trigger the problem. I really am not interested in posting 25 K lines of code to the forum. I would be happy to post tidbits from the map and .lss files, if those would be useful.

I am using -Os optimization (-O0 ran into the problem much earlier). I cannot use -mcall-prologues as I have the BootLoader in High Flash and that option confuses the BootLoader. Anyway, the optimization really doesn't seem to be the problem, it seems to be the linker.

Any ideas? I'm happy to post more info as needed. As a fallback position, I'm investigating both CodeVisionAVR and IAR compilers, but that appears to be some work to move the code.

Thanks for any help!

Stu Bell

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

Never observed. AVR Studio + DWARF-2 debugging is known to have
troubles with anything beyond 64 KB, but the linker itself (and the
resulting binary) are OK. In order to resolve this (right now),, you'd
either have to use something else than AVR Studio for debugging, or
switch to the old AVR-COFF debugging format.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Thanks Jörg. I also know about the debugging problem (and have a workaround), but that's not what I'm talking about. The code, as listed in the list file, and verified when loaded through either the JTAGICE mkII >or< my own intelHex loader in the Bootloader match up -- the linker is "mixing and matching" code on top of other code.

For example, here's part of the listing that includes the

:

    b686:	0e 94 3c 65 	call	0xca78 
    b68a:	66 e9       	ldi	r22, 0x96	; 150
    b68c:	70 e0       	ldi	r23, 0x00	; 0
    b68e:	ce 01       	movw	r24, r28
    b690:	01 96       	adiw	r24, 0x01	; 1
    b692:	0e 94 3c 65 	call	0xca78 
    b696:	d3 cf       	rjmp	.-90     	; 0xb63e 

0000b698 
: portSHORT main( void ) { b698: ce ef ldi r28, 0xFE ; 254 b69a: d1 e2 ldi r29, 0x21 ; 33 b69c: de bf out 0x3e, r29 ; 62 b69e: cd bf out 0x3d, r28 ; 61 void eeprom_read_block (void *pointer_ram, const void *pointer_eeprom, size_t n) { b6a0: fe 01 movw r30, r28 b6a2: 31 96 adiw r30, 0x01 ; 1 b6a4: a0 e0 ldi r26, 0x00 ; 0 b6a6: b0 e0 ldi r27, 0x00 ; 0 b6a8: 01 e0 ldi r16, 0x01 ; 1 b6aa: 10 e0 ldi r17, 0x00 ; 0 if (!__builtin_constant_p (n) || n > 256) { /* make sure size is a 16 bit variable. */ uint16_t size = n; asm volatile ( ".%=_start:" CR_TAB "sbiw %2,1" CR_TAB "brlt .%=_finished" CR_TAB

And, no, I do NOT have a call to eeprom_read_block in my main. Here's the beginning of the main routine:

portSHORT main( void )
{
  /*
	XMCRA = (1 << SRE);		// enable external SRAM, no sectors, no wait states
	XMCRB = (1 << XMBK);	// turn on external SRAM bus keepers
  */

	prvIncrementResetCount();

	/* simple initializations - these do not need the Scheduler running */
	AdcInit();
	TwiInit();
	AmxInit();
	DacInit();
	MfgInit();

	/* Start up the system tasks */
	vStartCommandHandler( mainCOMMAND_TASK_PRIORITY );
	vStartSPBInterface( mainSPB_INTFC_TASK_PRIORITY );

Thanks for any pointers!

Stu Bell

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

Remember that the .lst file is basically a disassembly listing,
interspersed with the source code as matched from the
debugging information. So as the debugging information
can only handle 64 KB with DWARF-2, the resulting
source code annotation will just be garbage (even though
the actual object code will be correct).

If you go the -gstabs way (and then convert to COFF), this
should also fix your .lst files.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Ah, yes, I see that now. I was always running my first versions of new code in the debugger to see how the new code worked.

Well, darn. I guess I need to learn to use Insight then. I've tried getting AVRStudio 4.12 to recognize the COFF files, to no avail. Well, I'll keep hacking.

Thanks!

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!