LwMesh, Linker Options

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

I am using LwMesh in a project w/ the ATMEGA256RFR2.

 

I am also trying to "pre-program" my EEPROM with data embedded in a .ELF file.  While doing so, I have been experimenting with different linker options, etc. (see: http://www.atmel.com/webdoc/atme...).

 

I have come across something interesting.  When I uncheck the "Garbage collect unused sections (-Wl,--gc-sections)" option in AVR/GNU Linker Optimization, my build fails, specifically, faulting on a slew of "undefined references" in several LwMesh files (nwk.c, nwkTx.c, sys.c, sysEncrypt.c).  I did not expect this.  Am I doing something wrong, or is this a bug in the stack?

 

Science is not consensus. Science is numbers.

Last Edited: Fri. Oct 16, 2015 - 12:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Can you name a few things that are missing? GC settings must be matched in the compiler and the linker, I don't know how studio handles this.

 

Sounds like something is wrong with the studio-generated makefiles or libc supplied with the studio.

 

Building on Linux, I only see two unknown references to __bss_start__ and __bss_end__. Defining two dummy variables with those names "solves" the problem.

 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

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

That being said, there should be no reason not to use GC. After all, it does what it says - collects garbage.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

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

Alex -- thanks for quick response.  Please see attached image for errors.

 

 

As for using the option (or "not" using it), the variables I am trying to put in EEPROM are not used elsewhere in the code, and I don't want the linker to discard them.

Science is not consensus. Science is numbers.

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

Ok, I have no idea why this happens, but disabling GC is not a solution anyway.  There are a few ways of doing what you want to do:

1. define the variables with the "used" attribute:

Quote:
__attribute__ ((used)) int var = 123;
This alone should be enough.

 

2.  The batter way is to also place your variables into a separate section (and define them used as well for a good measure)

Quote:
__attribute__ ((used, section(".eeprom"))) int var = 123;

 

In this case you will need to define placement rules for the new section in the linker file.

 

Of course you can use preprocessor, so your code looks like

Quote:
EEPROM int var = 123;

 

3. And you can always just tell linker to keep the variable. Look at how .vectors section is handled.

 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

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

Thanks for the tips.  I was just trying to follow Atmel's guidance (www.atmel.com/webdoc/atmelstudio...).

 

Hence my other thread...

 

https://www.avrfreaks.net/forum/b...

 

I have had mixed success with the used attribute.

Science is not consensus. Science is numbers.

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

Well, I'd rather deal with problems of the used attribute (I've never seen any) than disable a huge optimization. Disabling GC added 1.5k of flash on R21 project.

 

And telling the linker to directly keep thing through the linker script works all the time.

 

 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

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

Good point.  I ended up getting it to work w/o disabling GC.

Science is not consensus. Science is numbers.