Avr-Size Question - Still confused

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

Hi

This topic has been beaten to death over the years and I'm here again to gain some clarification.

 

I have a project using the ATtiny404 and and the code size is at the critical limit.  I am not using any eeprom in this project.

Using the Avr-Size -B option and the Avr-objdump tool, I am getting what appears as different results.

 

Here is the Avr-Size -B option output:

text       data        bss        dec        hex    filename
4135         14         42       4191       105f    ATtiny404_PS2_V6_1 Beta.elf

 

I read this as:

Flash = .text + .data = 4149 bytes

Ram =  .data + .bss  = 56 bytes

Am I interpreting this correctly?

 

 

Here is the Avr-objdump output:

Device: attiny404
Program:    4092 bytes (99.9% Full)  <<<  I've purposely pushed this to the limit as an experiment.
(.text + .data + .bootloader)

Data:         46 bytes (18.0% Full)
(.data + .bss + .noinit)

 

Why doesn't this agree with the reported Avr-Size -B ?  Are there unreported 'stored strings' causing the discrepancy?

I've always been under the assumption that this report is to be trusted.

 

In addition, when I attempt to program the the part (using Atmel ICE + Studio), I get an error claiming that my Flash memory has been exceeded.

The programming tool appears to be using the Avr-size -B report as the error source.

 

Timestamp:    2020-04-23 11:07:32.372
Severity:        ERROR
ComponentId:    20100
StatusCode:    1
ModuleName:    TCF (TCF command: Processes:launch failed.)

Loading executable to device failed. Segment 0xff8:0x1026 outside device limits. For more details, please check the elf file in the project folderLoading executable to device failed. Segment 0x1027:0x102a outside device limits. For more details, please check the elf file in the project folder

 

 

Any clarification would be appreciated.

Thanks

Jim

 

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

I read this as:

Flash = .text + .data = 4149 bytes

 

Why?   4135+14 = 4149 ??

4135+ 14 + 42 = 4191   yes

text   data  bss

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

avrcandies wrote:

I read this as:

Flash = .text + .data = 4149 bytes

 

Why?   4135+14 = 4149 ??

4135+ 14 + 42 = 4191   yes

text   data  bss

 

 

 

Why wouldn't 4149 indicate the total Flash used in bytes?  The .text is the application size and .data would be the initialized ram.  So the initialization values are stored in Flash also, correct?

The .bss size equates to the non-initialized ram and is unrelated to the Flash size.  I don't understand why they total all three sections and report this value.  Makes no sense.

 

Regardless, there still appears to be a difference between the two reports.

Am I unable to see the 'forest through the trees, as they say?

 

 

 

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

Do you have any other named flash sections?
.
EDIT actually what is ".bootloader" in the above?

Last Edited: Thu. Apr 23, 2020 - 04:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Do you have any other named flash sections? . EDIT actually what is ".bootloader" in the above?

 

Hi -

I have the bootloader block fuse set to 0 (i.e. no boot).  So all 4096 bytes should be available for .data( init data) and .text.

I searched the .map file and have no section .bootloader, so nothing is being added to the totals.

 

I do have some strings stored in flash (using PSTR).  Could this be the difference I am seeing?

 

take care -

Jim

Last Edited: Thu. Apr 23, 2020 - 05:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Ok -

I took a peek at the .lss file:

 

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00000004  00803f00  00001027  0000111b  2**0
                      CONTENTS, ALLOC, LOAD, DATA
  1 .text          00000ff8  00000000  00000000  000000f4  2**1
                      CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .rodata      0000002f  00008ff8  00000ff8  000010ec  2**0
                      CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .bss          0000002a  00803f04  00803f04  0000111f  2**0
                      ALLOC
  4 .fuse         00000009  00820000  00820000  0000111f  2**0
                      CONTENTS, ALLOC, LOAD, DATA
  5 .lock          00000001  00830000  00830000  00001128  2**0
                      CONTENTS, ALLOC, LOAD, DATA

 

 

Here, again, is the avr-size -B report:

text       data        bss        dec        hex    filename
4135         14         42       4191       105f    ATtiny404_PS2_V6_1 Beta.elf

 

So, per the .lss info above:

  • .data =  4
  • .text = 4088
  • .rodata = 47  // This appears to stand for 'Read-Only Data'  i.e. string constants, etc?
  • .bss = 42
  • .fuse = 9      //I have a FUSES section in the Main module
  • .lock = 1      //I have a LOCK section in the Main module

 

Adding the items up:

  • .text + .rodata = 4135  <<<< this agrees with the avr-size -B report
  • .bss = 42  <<< agrees
  • .data + .fuse + .lock = 14 <<<< agrees with data as reported.

 

Reviewing the Avr-objdump output:

Program:    4092 bytes
(.text + .data + .bootloader)

 

Using the .lss file data >>>  .text + .data = 4092?

 

Data:         46 bytes
(.data + .bss + .noinit)

 

Using the .lss file data >>> .data + .bss = 46

 

 

So, If I'm correct, the avr-size -B would be more accurate if you add the text + data as the text also includes the string constants. 

The reported data value includes the .fuses and .lock (should they be included in the .elf file).

 

The avr_objdump fails to include the rodata section.  However, the Atmel tool uses the avr-objdump value to determine whether the flash has been exceeded.

 

Well, have I blown this analysis?  If so, tell me where I've gone wrong.

Thanks for listening.

Jim

 

 

Last Edited: Thu. Apr 23, 2020 - 06:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh there is the problem, the forum has reached it's limit of Jim's!  wink

it would seem the best course of action is to up size your AVR to the next level of flash, would that be an att804?

projects always scream for one more feature, so you might as well make room for the inevitable!

 

 

 

 

Flyover Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

ki0bk wrote:

Oh there is the problem, the forum has reached it's limit of Jim's!  wink

it would seem the best course of action is to up size your AVR to the next level of flash, would that be an att804?

projects always scream for one more feature, so you might as well make room for the inevitable!

 

 

 

Hi -

Yes, I understand that I've overfilled the bathtub and should bump up to the next size part.

 

My goal for the post was really to understand how to use and interpret the memory usage tools.  Damn confusing in my opinion.

Thanks for the response -

Jim

 

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

Are you being efficient with your code and any text?  It's very easy to get wasteful---just try a printf without realizing the impact.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

avrcandies wrote:

Are you being efficient with your code and any text?  It's very easy to get wasteful---just try a printf without realizing the impact.

 

I totally understand what you are saying.  I've got a lot of debug code that I ended up commenting out to save space.  Again, the purpose of the post was to understand how to interpret the output of the avr-objdump and avr-size tools. This was not meant as a request on minimizing my code.  I purposely used this particular project, uncommenting debug code, in an effort to push the limits of the code size.  The idea was to see the outputs of the different software tools under these conditions.

 

Thanks

Jim

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

BTW I  guess you already know about

avr-objdump -Pmem-usage filename.elf

This was developed by Atmel as a "better" solution than avr-size (even the -C option where it exists)

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

clawson wrote:

BTW I  guess you already know about

avr-objdump -Pmem-usage filename.elf

This was developed by Atmel as a "better" solution than avr-size (even the -C option where it exists)

 

Yes, I was actually using this command in my analysis.

I used avr-size -B filename.elf and avr-objdump -Pmem-usage filename.elf.

 

The best I can tell, I get the same results using avr-size -C and avr-objdump -Pmem-usage.  The only difference (that I noticed) is that the avr-objdump reads the device information and reports the % usage.

It still appears to me that using avr-size -B filename.elf gives you a more accurate report of resource usage.

I'm certainly interested in your opinion and if you believe differently.

Thanks

Jim

 

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

I'm a luddite. I would objcopy the hex to bin then look at the size of that. That's the number of flash bytes it will use!

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

clawson wrote:
I'm a luddite. I would objcopy the hex to bin then look at the size of that. That's the number of flash bytes it will use!

 

Ha!  I see myself in the same light.  I've always felt that the best way to do something is the way you already know how to do it.  Stick with what works.

Take care

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

Here is the Avr-Size -B option output:

text       data        bss        dec        hex    filename
4135         14         42       4191       105f    ATtiny404_PS2_V6_1 Beta.elf

 

Why wouldn't 4149 indicate the total Flash used in bytes?

I'm pretty sure that the "dec" column is the "total program size" (text + data + bss), keeping in mind that the size utility and its output pre-date microcontrollers with separate memory types.

The whole program would get loaded off of disk into RAM, and the relevant question was "will I have enough RAM today"?