Bulky, seemingly unnecessary section .data

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


For some time now, I've tried to figure out what the .data section in the flash is for. However, I find searching for it in the forum quite difficult. One obstacle is that I apparently can't search for .data (including the dot). The website either doesn't respond, or it omits the dot. Looking forward to the new AVRFreaks site.

Anyway, what puzzels me is that there are about 1284 bytes that are visible in the .hex file, and pretty much nowhere else. It definitely isn't actual code. Then I thought that it could be pointers to variables, but the addresses don't match at all, and besides, I don't use THAT many variables.

I also thought that it could be some debugging stuff, although it doesn't seem to hold much useful information. And changing the debug settings in the makefile did nothing. I'm using the avr32-gcc compiler with a makefile. No ASF, and no AVR Studio.

The only reference in the .lss file is this line:

 12 .data         00000504  00000024  80001ac8  00002024  2**2
                  CONTENTS, ALLOC, LOAD, DATA

The mentioned flash area (0x80001ac8) begins with a few pointers, all pointing at addresses outside what is visible in the .lss file.

Then follows just over 200 bytes, all 0. And at last, a bunch of 32-bit constants in a pattern:
and so on up to
and then 8 bytes of other stuff in the end.

In the actual code in the .lss file, I cannot find any reference at all to this part of the flash. The closest I can find is the reference to the .ctors section (which is called _data_lma in the .sym file). But that looks like it is just a few words being loaded into the RAM.

So why is it there? Is it necessary? And if not, is there an easy way to get rid of it?

This is for a UC3C bootloader (which works nicely, by the way), so I'd like the code to be as compact as possible. Changing optimization options had some effect on the actual code, but not on this section.

Here is the "offending" part of the .hex file. Sorry about the size.


I won't be surprised, if there are several posts about this topic already. But I havn't been able to locate any of them. If they exist, I'd really appreciate a link.

Br, E

You're absolutely right. This member is stupid. Please help.

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

Follow-up: Well, it seems that it actually isn't unnecessary, whatever it is. Just to try it, I just cropped the section from the .hex file and uploaded it to the UC3C. The program didn't seem to run without that section. But what it actually does, still puzzles me.

You're absolutely right. This member is stupid. Please help.

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

I agree that the search function in this forum is quite often not really productive.
Since you know that you're using gcc, have a look at your corresponding gcc linker script, the gcc (libc) documentation and/or use google...



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

Thank you very much for the highly informative link. Point taken – googling would probably work better than using the forum's search function.

The weird thing is, I cannot recognize the data in the data section at all. It certainly doesn't look like any constants I've got in my program.

Ah, well. I think I'll just ignore it and live with it.

You're absolutely right. This member is stupid. Please help.

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

Try using "avr32-objdump -t" on the output elf file to get a list of all program sections and their contents. The output is unordered and contains some less useful information, so you should sort and filter it.

If you’re on Linux and want to see everything that’s not a function:

avr32-objdump -t out.elf | grep 'O ' | sort

Here’s the shortened output of one of my projects:

00000008 g     O .data  00000004 flashcdw_wait_until_ready
00000010 l     O .bss   00000004 gain_pins
00000014 l     O .bss   00000001 reserved
00000015 l     O .bss   00000001 fm_state
00000018 l     O .bss   00000004 flashc_workaround_scfg_flash
0000001c l     O .bss   00000004 flashc_workaround_mcfg_cpuins
00000020 l     O .bss   0000000c dac_chipsel
0000002c l     O .bss   00000004 conversion_function
00000030 l     O .bss   00000004 _int_line_handler_table_0
00000034 l     O .bss   00000008 _int_line_handler_table_1
80003f3c g     O .exception  00000000 ipr_val
80004010 l     O .rodata     00000100 static_crc8_table


1. Memory address of the object (in hex)
2. Visibility local or global
3. Object (Functions if you don’t filter them out)
4. Section
5. Size of the object in bytes (in hex)
6. Name of the object, aka. name of the variable

Now about the sections:
.data is for initialised global variables. I only have one of those, named flashcdw_wait_until_ready, probably from the FLASHC ASF driver. It’s a simple int (4 bytes).
Example: int flashcdw_wait_until_ready = 0;

.bss is for uninitialised global variables. My variable dac_chipsel is an array with a total size of 12 bytes. It’s declared as static, so visibility is local.
Example: static uint32_t dac_chipsel[3];

.exception is a special section, usually in the Flash, where the ASF’s INTC driver places the interrupt handler table named ipr_val and some code for it.

.rodata is for read-only data in the Flash. That’s where your global variables go if you declare them const.
Example: static const uint8_t static_crc8_table[256] = { ... };

Hope this helps.

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

Thanks a lot. I'll try that.

Linux? Unfortunately not. If I utter the word out loud, our administrator will probably burn incense and start chanting to ward off evil...

You're absolutely right. This member is stupid. Please help.

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

Strange... this 0x0504 bytes large area doesn't show up in the object dump. But after reading the .map file once more, I see that the area contains a number of things:

So now I have some more stuff to search for. Have a nice weekend! :)

You're absolutely right. This member is stupid. Please help.

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

As far as I can tell, the .data section is memory allocation.
In my (assembler) projects I use these for fixed memory allocation:

SRAM_VAR0: .word 0x00000000    // Arbitrary 32 bit variable 0
SRAM_VAR1: .word 0x00000000    // Arbitrary 32 bit variable 1
SRAM_ARR0: .fill 16,1,0x00     // Array of 16 bytes
SRAM_VAR2: .word 0x00000000    // Arbitrary 32 bit variable 3

SRAM_VAR0 is alias for address 0x00000004 (skipping NULL pointer)
SRAM_VAR1 is alias for address 0x00000008
SRAM_VAR2 is alias for address 0x0000001C
and so on.

This way I get a compile-error if I allocate too much memory, and avr32-size.exe shows how much memory I have allocated whenever I build the project.