Total ROM Size in -map file doesn't include last byte of ROM, why?

Hello Ronan,

thank you for your response.

I'm using µVision Version 5.37 and an ST G4 controller.

I'm deriving my data out of the .map file:

    Total ROM Size (Code + RO Data + RW Data)     146904 ( 143.46kB)

There I also found my last placed data in ROM:

Exec Addr    Load Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x20014078   0x080245d8   0x00000004   Data   RW         1875    RAM_DMA     yyy.o

Now I would expect, to get the address of the last byte inside the ROM, by adding the total ROM size to my start address (0x08000800):

146904 -> 0x00023dd8 (convert size to hex)

0x08000800 + 0x00023dd8 = 0x80245D8 -> last byte?

If I check the calculated last address of my ROM I'll get the start address of the last data (no matter if it's of size 1, 2, 3 or 4 bytes). But the last data is of size 4, so I would expect to get 0x80245DB as last byte.

Maybe I made a mistake, a logical error, but I can't see it at the moment....

Hello Ronan,

thank you for your response.

I'm using µVision Version 5.37 and an ST G4 controller.

I'm deriving my data out of the .map file:

    Total ROM Size (Code + RO Data + RW Data)     146904 ( 143.46kB)

There I also found my last placed data in ROM:

Exec Addr    Load Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x20014078   0x080245d8   0x00000004   Data   RW         1875    RAM_DMA     yyy.o

Now I would expect, to get the address of the last byte inside the ROM, by adding the total ROM size to my start address (0x08000800):

146904 -> 0x00023dd8 (convert size to hex)

0x08000800 + 0x00023dd8 = 0x80245D8 -> last byte?

If I check the calculated last address of my ROM I'll get the start address of the last data (no matter if it's of size 1, 2, 3 or 4 bytes). But the last data is of size 4, so I would expect to get 0x80245DB as last byte.

Maybe I made a mistake, a logical error, but I can't see it at the moment....

What is reported as the size of the Load Region? You should have something similar to the following in the map file:

Memory Map of the image

  Image Entry point : 0x00000401

  Load Region LR_ROM (Base: 0x00000000, Size: 0x00005354, Max: 0x00080000, ABSOLUTE)

Load Region LR_EXECUTION (Base: 0x08000800, Size: 0x00024e44, Max: 0x0003f800, ABSOLUTE, COMPRESSED[0x00023ddc])

May I have to look at the "COMPRESSED" size? Why is it not the same as the total rom size?

Hello Ronan,

thank you very much for the link. I think it's a useful option and I don't want to disable it.

So the compressed size seems to be the right size, right? Is there also a document which describes the "total rom size" etc.?

Do you know, why it's different?

This is a question of ROM size vs RAM size (or Load region vs Execution region in scatterloading terminology).

The compressed data is stored in 'ROM', taking up as little space (in Flash in a real device), and the init code (__main, which itself calls __scatterload) copies and decompresses to your (S)RAM, taking its full size there.

So in your example that region will take up 0x23ddc bytes of "ROM", and 0x24e44 bytes of "RAM".

Apologies, I should have mentioned data-compression previously.

And what about the "total ROM size" at the End of the .map file, why is it different to the compressed size?

Hi again Klaus,

I have been discussing this internally.

Can you confirm which version of the compiler you are using? I wonder if this is an issue with an older toolchain.

It would also be good to use "fromelf -z" on the generated executable. What does that report, and does it match the linker output?

> fromelf -z Blinky.axf

========================================================================

** Object/Image Component Sizes

      Code (inc. data)   RO Data    RW Data    ZI Data      Debug   Object Name

     14712        202       6608         12       3652      87147   Blinky.axf
     14712        202       6608         12          0          0   ROM Totals for Blinky.axf

Hello Ronan,

here are our compiler and linker versions:

MDK Essential 5.37
C Compiler: ArmClang.exe V6.18
Assembler: Armasm.exe V6.18
Linker/Locator: ArmLink.exe V6.18
Library Manager: ArmAr.exe V6.18

Now I'm totally confused.... 

here is my map. file output:

==============================================================================


      Code (inc. data)   RO Data    RW Data    ZI Data      Debug   

    120140       2874      26472       4496      16316    1308369   Grand Totals
    120140       2874      26472        296      16316    1308369   ELF Image Totals (compressed)
    120140       2874      26472        296          0          0   ROM Totals
    
    ==============================================================================

    Total RO  Size (Code + RO Data)               146612 ( 143.18kB)
    Total RW  Size (RW Data + ZI Data)             20812 (  20.32kB)
    Total ROM Size (Code + RO Data + RW Data)     146908 ( 143.46kB)

==============================================================================

and fromelf-z tells me:

========================================================================

** Object/Image Component Sizes

      Code (inc. data)   RO Data    RW Data    ZI Data      Debug   Object Name

    120140       2874      28504       4496      16316    1308369   C:... (uncompressed)
    120140       2874      28504        296      16316    1308369   C:... (compressed)
         0          0       2032          0          0          0   (incl. padding)
    120140       2874      28504        296          0          0   ROM Totals for C:...

There are the same size for code, rw and zi data, but different size for ro data....

Hmm... the difference is the 2032 bytes of padding (26472+2032=28504).

Is the "ROM Totals" from fromelf correct?

Yes, if I add the ROM totals from fromelf (Code + ro data + rw data) I'll get the expected result.

Thanks for confirming. I'll flag this up internally.

Hello Ronan,

thank you very much.

It seems like the output of the fromelf is the same as the compressed size, we've talked about several days ago...