Hello,
for crc calculation, I'm using the total ROM size out of the .map file.
To check, all code is included, I've added the total ROM size to my start address.
Then I saw, that I only get the address of the first byte of my last word, half word ....
I would expect to get the address of the last byte or the last byte plus some stuffing bytes to get an alignment of 4.
Do you know, why I get the address of the first byte (of my last word/half word....) if I'm adding the total ROM size to my start address?
Best regards,klaus
Hello Klaus,
I'm not sure I understand where you are deriving your data. Could you add an output file or similar so that I can understand it better? Please also confirm which compiler version, and which processor you are using.
Looking at the .map output of an example project, I see something like this:
Memory Map of the image Image Entry point : 0x00000401 Load Region LR_ROM (Base: 0x00000000, Size: 0x00005354, Max: 0x00080000, ABSOLUTE) Execution Region ER_ROM (Exec base: 0x00000000, Load base: 0x00000000, Size: 0x00005348, Max: 0x00080000, ABSOLUTE) ...
This says the size of the execution region is 0x5348 bytes. The last filled byte of this section would therefore be 0x5347.
This matches the last entry in this section (0x5328+0x20):
... 0x00005328 0x00005328 0x00000020 Data RO 578 Region$$Table anon$$obj.o
However the load region is size 0x5354, as it also contains some RW data which is to be placed in a subsequent execution region.
I believe all the information output is correct?
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?
HI Klaus,
This feature is described here:https://developer.arm.com/documentation/101754/0622/armlink-Reference/Linker-Optimization-Features/Optimization-with-RW-data-compression
You can disable with the linker option --datacompressor off.
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
here are our compiler and linker versions:
MDK Essential 5.37C Compiler: ArmClang.exe V6.18Assembler: Armasm.exe V6.18Linker/Locator: ArmLink.exe V6.18Library 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.
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...