Problems switching from 644p to 1284p

Log in or register to post comments
Go To Last Post
14 posts / 0 new
Author
Message
Baldrian
Baldrian's picture
Level: Hangaround
Joined: Thu. Jul 10, 2008
Posts: 195 View posts
Location: Ruhrpott, Germany
#1
Posted by Baldrian: Wed. Aug 4, 2010 - 11:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Folks,

I recently switched to the 1284p µc. In the beginning, everything was ok. The software was working fine. Now, after the code has grown a little bit more, I encounter missbehaviour in the software.
After long analysis, I figured out, that the code works fine, when I change the linking order.
When I put the api for a lib to the end of the linklist and the software works.
When I put the api in the beginning of the linklist the software does not work correctly, but the compiled package size is still the same.

My actual programm size using WinAVR-20100110 is like this:

Program:   53970 bytes (41.2% Full)
(.text + .data + .bootloader)

Data:       4886 bytes (29.8% Full)
(.data + .bss + .noinit)

EEPROM:      467 bytes (11.4% Full)

Plus the bootloader space of 4096 WORDS.

This seems to me like a problem occuring when the address space between the api functions and the library is to far.

I can fix the problem by changing the linkorder.
But I want to understand what happens here.

I'm sure, some of you can give me some hints.

http://xkcd.com/221/

Tags:

Tools, Compilers and General Programming
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101072 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Aug 4, 2010 - 11:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Show the linker invocation in both the working and non-working cases.

Top
Baldrian
Baldrian's picture
Level: Hangaround
Joined: Thu. Jul 10, 2008
Posts: 195 View posts
Location: Ruhrpott, Germany
Posted by Baldrian: Wed. Aug 4, 2010 - 12:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Show the linker invocation in both the working and non-working cases.

I'm using the AVRStudio generated makefile:

MCU = atmega1284p
.
COMMON = -mmcu=$(MCU)
.
## Linker flags
LDFLAGS = $(COMMON)
LDFLAGS += -Wl,--section-start=.bootloader=1E000 -Wl,--gc-sections  -Wl,--section-start=.noinit=0x804000 -Wl,-Map=project.map
.
OBJECTS = ...
.
## Library Directories
LIBDIRS = -L"Y:\" 
## Libraries
LIBS = -lmylib 
.
##Link
$(TARGET): $(OBJECTS)
	 $(CC) $(LDFLAGS) $(OBJECTS) $(LINKONLYOBJECTS) $(LIBDIRS) $(LIBS) -o $(TARGET)
.

For the working version I change the AVRStudio setting to external makefile and use the same makefile. I only change the list of all the object files under "OBJECTS = ..."

So, the same linker call, except for the order of the object files.

http://xkcd.com/221/

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101072 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Aug 4, 2010 - 01:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK so can you show the linker invocation in the working and non-working cases? I'm talking about something like:

Linking: test.elf
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1843200UL -Os -funsigned-char -funs
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -fverbose-
asm -Wa,-adhlns=test.o  -std=gnu99 -MMD -MP -MF .dep/test.elf.d test.o empty.o -
-output test.elf -Wl,-Map=test.map,--cref     -lm -Wl,-q

Top
Baldrian
Baldrian's picture
Level: Hangaround
Joined: Thu. Jul 10, 2008
Posts: 195 View posts
Location: Ruhrpott, Germany
Posted by Baldrian: Wed. Aug 4, 2010 - 01:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK. The Linker invocation looks like this (had to change the names a little):

Not Working Version:

avr-gcc -mmcu=atmega1284p -Wl,--section-start=.bootloader=1E000 -Wl,--gc-sections -Wl,--section-start=.noinit=0x804000 -Wl,-Map=test.map 1.o 2.o 3.o 4.o 5.o 6.o 7.o 8.o 9.o 10.o 11.o 12.o 13.o 14.o 15.o 16.o 17.o 18.o 19.o 20.o TESTLIB_API.o 22.o 23.o 24.o 25.o 26.o 27.o 28.o 29.o 30.o 31.o 32.o 33.o 34.o 35.o 36.o 37.o 38.o 39.o 40.o 41.o 42.o -L"Y:\app\lib" -ltestlib -o test.elf

Working Version:

avr-gcc -mmcu=atmega1284p -Wl,--section-start=.bootloader=1E000 -Wl,--gc-sections -Wl,--section-start=.noinit=0x804000 -Wl,-Map=test.map 1.o 2.o 3.o 4.o 5.o 6.o 7.o 8.o 9.o 10.o 11.o 12.o 13.o 14.o 15.o 16.o 17.o 18.o 19.o 20.o 21.o 22.o 23.o 24.o 25.o 26.o 27.o 28.o 29.o 30.o 31.o 32.o 33.o 34.o 35.o 36.o 37.o 38.o 39.o 40.o 41.o TESTLIB_API.o -L"Y:\app\lib" -ltestlib -o test.elf

I just put the testlib.api to the end of the object list and it works.

I know there can be some issues with progmem when breaching through the 64k because of the 16bit addressing.
But I'm still smaller than that.

Can there be problems with RAM positions >4096 bytes?

http://xkcd.com/221/

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101072 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Aug 4, 2010 - 02:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Can there be problems with RAM positions >4096 bytes?

Not according to your avr-size output if this is the 1284 you are building for. (obviously the program no longer fits in the 4K RAM of a 644!)

Top
Baldrian
Baldrian's picture
Level: Hangaround
Joined: Thu. Jul 10, 2008
Posts: 195 View posts
Location: Ruhrpott, Germany
Posted by Baldrian: Wed. Aug 4, 2010 - 02:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Not according to your avr-size output if this is the 1284 you are building for. (obviously the program no longer fits in the 4K RAM of a 644!)

That's why we changed to the 1284p :D

So, the problem must be in the program space and I can solve it by chaning the linkorder. But I'm curious to find out why this problem happens to avoid future problems when the code is growing.

http://xkcd.com/221/

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101072 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Aug 4, 2010 - 02:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That kind of depends what's in TESTLIB.API - presumably the .map files will also help to see how things are re-arranged?

Top
stu_san
stu_san's picture
Level: Raving Lunatic
Joined: Fri. Dec 30, 2005
Posts: 2321 View posts
Location: Fort Collins, CO USA
Posted by stu_san: Wed. Aug 4, 2010 - 02:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are any of your object files created from .S (assembly) files? Is it possible that you are using an RJMP or RCALL to call an external routine?

Also, you have not told us which version of Gcc (or WinAVR, if that's what you are using) you have.

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!

Top
Baldrian
Baldrian's picture
Level: Hangaround
Joined: Thu. Jul 10, 2008
Posts: 195 View posts
Location: Ruhrpott, Germany
Posted by Baldrian: Wed. Aug 4, 2010 - 03:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
That kind of depends what's in TESTLIB.API - presumably the .map files will also help to see how things are re-arranged?

I checked allready the map file. I'll put some parts here:
Not working:

 .
 .
 .
 .
 .text.leds     0x00005480       0x18 testlib_api.o
                0x00005480                leds
  .
  . //more API stuff
  .
  .              
 .text.prvTask
                0x000056aa      0x184 testlib_api.o
 .text.22 
                0x0000582e       0x54 22.o
 .
 . //many stuff between the api and the lib
 .
 .
 .text.testlibF1
                0x0000a0a8       0x8c Y:\app\lib\testlib.a(f1.o)

Working:

 .
 . //all the other o files are here
 .
 .
 .text.leds     0x00009cfa       0x18 testlib_api.o
                0x00009cfa                leds
 .
  . //more API stuff
 .
 .  
 .text.prvTask
                0x00009f24      0x184 testlib_api.o
 .text.testlibF1
                0x0000a0a8       0x8c Y:\app\lib\testlib.a(f1.o)

So, the api of the working version is near the lib. All the other o files are before the testlib_api.o.
(Maybe I'm searching on the wrong spot. Maybe the problem is fixed by any other .o file being in lower memory after rearranging the testlib_api.o)

And of course the variables in Data section are also rearranged.

It's a pitty that I cannot put the whole map file or any code up. I don't think my boss would like that :-(

@stu_san:
Only some small assembler functions for changing the clock speed or the watchdog.

Baldrian wrote:
My actual programm size using WinAVR-20100110 is like this:

http://xkcd.com/221/

Top
dkinzer
dkinzer's picture
Level: Posting Freak
Joined: Fri. Mar 12, 2004
Posts: 1299 View posts
Location: Portland, OR, USA
Posted by dkinzer: Wed. Aug 4, 2010 - 11:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a lot of speculation in this thread and not much in the way of facts. What exactly does your program do or fail to do when it malfunctions? Knowing this, you should be able to develop a strategy for narrowing down the location of the problem using standard debugging strategies/techniques, a process that will probably be simpler if you have debugging hardware like JTAGICE MkII.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39996 View posts
Location: Wisconsin USA
Posted by theusch: Thu. Aug 5, 2010 - 02:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not qualified to dig into the above, but if a segment with flash constants ended up loaded above 64k and there were no proper provisions for RAMPZ/LPM/ELPM and the like...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
meslomp
meslomp's picture
Level: Raving Lunatic
Joined: Wed. May 2, 2007
Posts: 6289 View posts
Location: Nieuwegein, Netherlands
Posted by meslomp: Thu. Aug 5, 2010 - 05:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you have a bootloader.....

did you set the fuses correctly ?

you tripple checked that everywhere in your project you changed the reference to the 1284 ?

Top
skeeve
skeeve's picture
Level: Raving Lunatic
Joined: Sun. Oct 29, 2006
Posts: 5390 View posts
Posted by skeeve: Thu. Aug 5, 2010 - 11:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did the linker give any warnings?
Any clues in the .lss file?

Iluvatar is the better part of Valar.

Top