I'm writing code by the chip MC9S08AC128. So .s19 is generated after compiling.
I'm just wondering is there any approach to know how much size does the flash memory actually be used?
the information you are looking for is already in map file.
Look into your Cosmic link command file to see what the section names means.
An application that uses one or more object module(s) may require several
sections (code, data, interrupt vectors, etc.,...) located at different
addresses. Each object module contains several sections. The compiler
creates the following sections:
.text code (or program) section (e.g. ROM)
.const constant and literal data (e.g. ROM)
the information from your map :
start 000020f0 end 000037b2 length 5826 segment .BANK0
start 000037b2 end 00004000 length 2126 filler (0x83)
start 00004000 end 00007fc1 length 16321 segment .BANK1
start 00007fc1 end 00008000 length 63 filler (0x83)
PPAGE 0 with memory space of 7952 BYTES has occupied 5826 Bytes starting at addr 0x20f0 and ending at addr 0x37b2 with your code and the remaining 2126 bytes of this page is filled with pattern 0x83
PPAGE 1 with memory space of 16384 BYTES has occupied 16321 Bytes with your code and the remaining 63 bytes of this page is filled with pattern 0x83
0x83 is SWI instruction, so I guess Cosmic has some protection implemented
no object file should overlap the page boundary
so if you are looking for the information how big your code is, just sum the occupied spaces of all segments like in your case 5826+16321
you can check the used flash memory size in the generated .map file.
easy way is to check it at the last line:
Number of blocks to be downloaded: 4
Total size of all blocks to be downloaded: 205
thus the used flash size is 205byte.
Thanks for your quick response!
Unfortunately there is no such content in my generated map file(P.S. the compiler I use is COSMIC)
Below is the content of the map file generated I have simplified.(I also attach the download link for the completed map file)
start 000020f0 end 000022d0 length 480 section .BANK0 (.text)
start 00000100 end 0000023c length 316 section .bss
start 00000000 end 00004e58 length 20056 section .debug
start 000022d0 end 000022f4 length 36 section .BANK0 (.text)
start 00004e58 end 000099b6 length 19294 section .debug
f_APS__Initialize > 2 (2)
f_APS__SetHeaterSafetyState > 2 (2)
f_CBUIGetCSelPos 6 (3)
f_CBUIGetPBStatus 10 (6)
1 > _Commutils__SendMEBStartSteamKeep: (7)
2 + _QueueMsg: (6)
3 | + _GetBuffer: (3)
4 | + _HdrToIndex: (4)
5 | + _MBIndex: (4)
BOTTOMSTACK 000020ef defined in command file
*** not used ***
FLASHBACKKEY 0000ffb0 defined in command file
It is possible to ascertain the code size from the S19 file. Firstly, you have no interest in records other than S1 type, and perhaps S2 type when paged memory is used. Following the record type, the character pairs that follow represent hexadecimal byte values, in the following sequence -
For a S1 record with 32 data bytes, the size would be 0x23. The last record for each memory block may contain fewer data bytes than the maximum.
To determine the program size, multiply the number of records by the maximum record size. You may wish to ignore the records that define the vector table, etc., with address values FFxx.
This is indeed a approach anyway.
But considering that,for a 128K chip,there probably will be 3-4 thousands records at all including 8 blocks.And for each block there will be some dummy(empty) records.In this case,it will cost a heavy effort on filtering and checking how many records are be used actually.
So I am wondering if there is some more convenient way to get the result?(from the .map file?)
I attach the download link for the completed map file as below.
The first record within the S19 file is likely to be a S0 record that might occupy possibly two lines. This will be followed by S1 and/or S2 records, and the final record should be a S9 record. There should be no "dummy" S1 or S2 records within the S19 file. These records will generally occupy a single line per record.
By examining the S19 file within a text editor, you should easily be able to ascertain the number of lines in the file. Since most records will contain a fixed number of data bytes, with few records containg a lesser number, a good approximation may be achieved by assuming that all records have the same length.
If these characteristics do not hold for your particular S19 file, this would be quite unusual behaviour for a linker, unless you happen to be programming a specific value within unused flash memory. I would not expect there would be "unused flash" records for a data value of 0xFF, the unprogrammed flash state, as this would severely degrade the programming efficiency.
Assuming that you have 3000 records, with 32 bytes per record, the total code size should be very close to (3000 - 3) * 32 = 95904 bytes. This simplification would over-estimate by an average of 16 bytes per non-contiguous code block.
Thanks! What you told me is align with what I think of.
So if the segment is describe as below.
start 000020f0 end 000037b2 length 5826 segment .BANK0 Y
start 00004000 end 00007fbd length 16317 segment .BANK1 Y
start 00007fbd end 00008000 length 67 filler (0x83)
start 0000c000 end 0000eb0d length 11021 segment .BANK3 Y
start 0000eb0d end 0000f030 length 1315 segment .const Y
start 00000080 end 00000080 length 0 segment .bsct
start 00000100 end 00000100 length 0 segment .data
start 0000ffb0 end 0000ffb8 length 8 segment flash_backkey
start 0000ffbd end 0000ffbe length 1 segment flash_prot
start 0000ffbf end 0000ffc0 length 1 segment flash_opt
start 00000100 end 00000cf6 length 3062 segment .bss
start 00000000 end 00191730 length 1644336 segment .debug
start 00000080 end 000000f1 length 113 segment .ubsct Y
start 00008000 end 0000bc5e length 15454 segment .BANK2 Y
start 0000bc5e end 0000c000 length 930 filler (0x83)
start 00010000 end 00013a33 length 14899 segment .BANK4 Y
start 00013a33 end 00014000 length 1485 filler (0x83)
start 00014000 end 00017c93 length 15507 segment .BANK5 Y
start 00017c93 end 00018000 length 877 filler (0x83)
start 00018000 end 0001bd4d length 15693 segment .BANK6 Y
start 0001bd4d end 0001c000 length 691 filler (0x83)
start 0001c000 end 0001fb99 length 15257 segment .BANK7 Y
start 0001fb99 end 0001fb99 length 0 segment .fconst
start 0001fb99 end 00020000 length 1127 filler (0x83)
start 0000ff9c end 0000ffa0 length 4 segment VECT_TABLE_0
start 0000ffc0 end 00010000 length 64 segment VECT_TABLE_1
start 0000ff6b end 0000ff73 length 8 segment VERSION_CORE
start 0000ff73 end 0000ff7f length 12 segment VERSION
start 0000ff7f end 0000ff80 length 1 segment APPL_CRC
start 0000f030 end 0000f030 length 0 segment .utext
start 0000f030 end 0000ff6b length 3899 filler (0x83)
Does that mean I need to sum of length of the rows which is marked 'Y' to accumulate the total space occupied,am I correct?
Another question is,what does '.debug' mean?
according to Cosmic .debug is
"Debugging section. Used by the ZAP C source-level debugger or other third
party debuggers. Not of interest to most users."
it seems your linker command file is really heavily segmented .
you need to count all the segments including backkey, opt, prot,bss(data for RAM stored in FLASH - these are copied during the startup), vector table it will tell you the propper size of your application in MCU.
for your case, you are filling the empty location with 0x83, so the whole segment is filled with something (code, data or dummy filler 0x83). this means your flash will be filled by 100% by some numbers, just portion will be the code and the rest is filler.
if you are looking into how big will be your file it is sum of all above + some header as was mentioned in previous thread multiplied two times.
the multiplication is becauese there is ascii interpretation of each number by 2 hex digits. For eg 0xBA is coded as ascii 'B' and 'A' in the file.
I guess you will see the s19 will occupy some 300k on the disk of your PC.
following map file from some Hitex material, created by the linker from Cosmic.
start 00008000 end 00008cd7 length 3287 segment .text
start 00008cd7 end 00008cdf length 8 segment .const
start 00000050 end 00000050 length 0 segment iram
start 00000e00 end 00000e07 length 7 segment .data
start 00000050 end 00000055 length 5 segment .ubsct
start 00000800 end 00000800 length 0 segment .eeprom
start 00000e07 end 00000f2f length 296 segment .bss
start 00000000 end 00001d28 length 7464 segment .debug
start 0000ffe0 end 00010000 length 32 segment .const
The code size is 3287 Bytes.
The data size is 8 + 7 + 5 + 296 = 316 Bytes.
The vector table takes 32 Bytes from 0xFFE0.
The total test application size is 3287 + 316 +32 = 3635 Bytes.
• • • •
Retrieving data ...