Problems switching from 644p to 1284p

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 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.

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

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

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

  • 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

  • 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?

  • 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!)

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

  • 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?

  • 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!

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

  • 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

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

  • 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 ?

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