Size of S19

[bobkang]

Hi,

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? 

[bigmac]

Hello,

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 -

• Record size, including address and checksum overheads..
• Start address for record (2 bytes for S1 type).
• Data bytes, usually 16 or 32 maximum per record.
• Checksum byte.

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.

Regards,

Mac

[bobkang]

Hi Mac,

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.

http://sdu.bz/Q7rJDrDy

[pavel_sadek · Accepted solution]

Hi

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)

simply says:

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

Pavel

[bobkang]

Thanks! Pavel.

[bobkang]

Hi Pavel,

Thanks! What you told me is align with what I think of.

So if the segment is describe as below.

                               --------

                               Segments

                               --------

start 000020f0 end 000037b2 length  5826 segment .BANK0              Y

start 000037b2 end 00004000 length  2126         filler (0x83)

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?

[pavel_sadek]

HI

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 :smileywink:.

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.

http://www.hitex.com/fileadmin/pdf/products/tessy/application-notes/AN-TESSY-0104.pdf

Segments:

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

Interpretation

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.

• • • •

Pavel

[bigmac]

Hello,

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.

Regards,

Mac

[ZhangJennie]

you can check the used flash memory size in the generated .map file.

easy way is to check it at the last line:

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

ExeFile:

--------

Number of blocks to be downloaded: 4

Total size of all blocks to be downloaded: 205

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

thus the used flash size is 205byte.

[bobkang]

Hi Zhang,

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)

http://sdu.bz/Q7rJDrDy

                               --------

                               Segments

                               --------

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)

.......

.......

.......

                               -------

                               Modules

                               -------

./obj/PwFail.obj:

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

./obj/sr__startup.obj:

start 000022d0 end 000022f4 length    36 section .BANK0 (.text)

start 00004e58 end 000099b6 length 19294 section .debug

.....

.....

.....

                             -----------

                             Stack usage

                             -----------

./obj/APS.obj:

f_APS__Initialize                              >    2   (2)

f_APS__SetHeaterSafetyState                    >    2   (2)

./obj/CB_UI.obj:

f_CBUIGetCSelPos                                    6   (3)

f_CBUIGetPBStatus                                  10   (6)

......

......

......

                              ---------

                              Call tree

                              ---------

   1 > _Commutils__SendMEBStartSteamKeep: (7)

   2      + _QueueMsg: (6)

   3      |    + _GetBuffer: (3)

   4      |    + _HdrToIndex: (4)

   5      |    + _MBIndex: (4)

          |

.....

.....

.....

                               -------

                               Symbols

                               -------

BOTTOMSTACK                                     000020ef   defined in command file

                                                           *** not used ***

FLASHBACKKEY                                    0000ffb0   defined in command file

                                                           *** not used ***

.....

.....

.....