avr32-gcc section initialization bug

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

Hi all!

I seriously think I found and pinned down a bug in the avr32-gcc toolset relating it's initialization code.

The parameters of my environment:
32bit Linux
avr32-gcc version 3.4.1-348
UC3C1512C controller

(avr32 header pack was extracted from ASF, copied at the avr32/include/av32 path, so accessible like #include . No ASF used otherwise)

The bug:
When one customizes a linker script creating specific sections in RAM which shall be initialized from C code by initializators, the byte streams required for the initialization are properly compiled and linked in the resulting image, but the initialization code fails to respect the initalizators of the specific sections.

I attached a test case demonstrating this behavior. It tries to specify stack canaries around the stack which are supposed to be initialized by normal C initializers.

Normally one would except that the LED will stay lit in the demonstration, but it will be observed that the LED flashes instead. If one removes the section specifier attribute from the stack_b[] array, and compiles the code, the LED will stay lit as excepted.

Well, at least I think this is a bug, maybe I am just using the linker script incorrectly. Could someone point this out for me if this is the case?

Thanks!

Attachment(s): 

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

I can't initialize variables too, but I am using asf. For example I have global variable

volatile unsigned char test[5] = {1, 2, 3, 4, 5};

and when I am debugging I see that address of variable is 0x0000. When variable is not initialize it has normal address.

So you are not alone in this problem)

Last Edited: Mon. Sep 10, 2012 - 04:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

At the same time my colleague can initialize arrays %).

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

I seem to have this problem with XMEGA as well. I tried hacking in a quick sine lookup table for testing something and it seems to get optimized away, despite being marked as volatile.

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

Are people still having issues with this? I'm having huge problems getting arrays to work and they seem to get optimized away (or not initialized?) more often than not.

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

Well first look to see if -fdata-sections (and -gc-sections) are being used. If so then defeat one or both.

If that's not it check the objcopy that creates the load image and make sure it is including all flash components (then again maybe avr32 doesn't work this way?)

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

-fdata-sections and -gc-sections were both enabled and I got the same result after removing them. This is my objcopy line:

avr32-objcopy -O ihex CentralUnit.elf CentralUnit.hex

What I have is an array of this struct:

struct PYHFile
{
   const char* name;
   const unsigned char* data;
   const unsigned int size;
};

static const PYHFile PYHFiles[] =
{
   { "CUHandler.pyo", CUHandler_pyo, CUHandler_pyo_len }, 
   { "Config.pyo", Config_pyo, Config_pyo_len }, 
   ....
};

The name "CUHandler.pyo" is there but CUHandler_pyo_len is 0 when it's supposed to be 2186.

Edit: Semi-solved it. For some reason it does not work when I use a copy of the original size variable, but I have no idea why. If I change it to a reference it works:

struct PYHFile
{
   const char* name;
   const unsigned char* data;
   const unsigned int& size;     //<- Changed from a copy to a reference
};