Hi,
Can anyone tell me how my code can know what size the image is in FLASH ? Is there a symbol that I can reference that shows how much space the image occupies ?
I know this information is obvious from the generated .HEX file (and it may be possible to work it out from the .MAP file). I currently have to post-process the .HEX file and patch it (updating the relevant line's checksum accordingly).
Surely there is an easier way to do this !
Note that I'm not looking for the size of the CODE segment, just the overall image size.
Any ideas ?
Thanks,
David.
I haven't looked at these symbols for the ARM compiler, but just a note about zero-initialized data.
Zero-initialized variables should not need to consume any space in the FLASH image. The startup code just needs to know the start addres, and how many bytes of RAM to clear before calling main(). That is the big reason to separate initialized variables from zero-initialized (cleared) variables. Else, a 16kB large transfer buffer would require 16kB of (compressable) data mirrored in the FLASH.
Most C compilers uses the name BSS for zero-initialized data, where BSS stands for Block Started by Symbol.
"Most C compilers uses the name BSS for zero-initialized data, where BSS stands for Block Started by Symbol."
Interesting ... I remember learning years ago that it stood for 'block storage segment'.
Done a quick search, both seem to be acceptable. Neither (to me) seem particularly logical.
Why should everything be logical :)
Yes, more than one acronyme are suffering from contention as to the "original" or "true" name, since they often got invented in a more "creative" state of a developer and without being immediately documented.
The startup code only has a symbol to tell it where the BSS/ZI data starts. Normally the size isn't explicitly stored. Instead, there is a second symbol where the data ends, and the size is computed by the startup code.
This in relation to the DATA segment, where the startup code has a full set of data to copy.
This sounds reasonable, but assumes that all ZI data is contiguous. Is that a reasonable assumption for all compilers ?
At least for "real" processors, that assumption should be real. I'm not sure about compilers for embedded processors - if the processor has non-contiguous data memory areas, there can be a need to be able to split zero-initialized variables into these memory areas.
Fair enough. That probably explains why the ZI length is shown as 0 (though I don't see much value in having the symbol if it is always 0).
But what about the RW length ? My image definitely has some (non-zero) initialised data.
Are you sure that you haven't mixed up the IRAM1 and IROM1 symbols?
Quite sure. If you look above, you'll notice that the two report diferently. i.e.
Image$$ER_IROM1$$RW$$Base = 0x0000A9EC Image$$ER_IROM1$$RW$$Length = 0x00000000 Image$$ER_IROM1$$RW$$Limit = 0x0000A9EC Image$$RW_IRAM1$$RW$$Base = 0x40000060 Image$$RW_IRAM1$$RW$$Length = 0x00000868 Image$$RW_IRAM1$$RW$$Limit = 0x400008C8
David
Yes, your IRAM1 region has a couple of RW variables. Your IROM1 does not. Trying to use FLASH for writeable variables (le'ts assume we are talking about EEPROM or similar that allows writing at that granularity) would not be so good.
Hi Per,
No-one other than you has said anything about trying to use FLASH for writeable variables.
Can I suggest that you read the full thread properly before jumping to patronising conclusions ?
My previous comments referred to Robert's more constructive response above (9-Sep-2007 22:35), where he states :-
"In your example the total length of the image which needs to be stored in Flash is the length of the Load region which is 0x54EC (Compressed). The majority is occupied by code and constants which is the length of the ROM Execution region and is 0x5450 and in the remaining 0x9C bytes are the compressed initial values of RW data."
My question was, assuming the above is correct (and I have no reasons to doubt that it is), why do the linker symbols not show the individual sizes of the ROM execution region and the compressed RW region ?
I believe there may be a problem in that these symbols may only contain valid information when compression is not enabled.
For the avoidance of further doubt, we are talking about initialised (non-zero) variables, not ZI data. The compiler/linker must store the information on initial values somewhere within the IROM1 image and expand the data (initilalising RAM) at startup.
Nothing patronizing about my answer, and I have read the full thread.
I have not said that you are trying to use the FLASH for writeable variables. I am saying that your compiler specifically knows that it can't put variables there, and that I belive that is the reason why the symbols are zero.
And I'm trying to suggest that your R/W data is only represented by the IRAM1 symbols.
It is not an explanation why the compiler doesn't emit enough information to add upp to the total used space in the FLASH, but a suggestion why your IROM1 symbols shows zero for RW and ZI, while your IRAM1 symbols for RW and ZI are not zero.
Thanks for the reply Per, and my apologies if I misinterpreted the intention of your comment.
Believe me, with 20+ years embedded experience, I do know the difference between non-volatile/persistent and volatile storage media. I understand what you are suggesting and even agree that it makes some sense. However, it brings me back to the unanswered question of what is the point of the linker emitting symbols that, if you are completely correct, are ALWAYS going to be 0 ?
Regards,
PS: While I would certainly appreciate any comment you may have on my question above, I think this thread has probably started to outlive its usefulness. I'll look forward to the relevant information being made available by the linker some time soon.
Thanks to everyone who has contributed.