Missing S9 record when converting Intel hex to S19
Brought to you by:
pmiller,
scottfinneran
Menu
▾
▴
#11 Missing S9 record when converting Intel hex to S19
When converting Intel hex file to Motorola S19 file
S9 record is missing in output. No such behaviour when converting omf file (source of hex file) to S19, altough "hole" is filled with 0xFF.
srec_cat -version
srec_cat version 1.33.D001
(Windows precompiled, same result with 1.36)
Why there is still no Windows precompiled 1.37 available at SourceForge?
main.hex:
:03000000020008F3
:0300610002000397
:0500030012006480FE04
:010064002279
:0101FF0012ED
:06003700E478FFF6D8FD9D
:080015007900E94400601B7A48
:05001D0000900069786D
:030022000075A0C6
:0A00250000E493F2A308B8000205FE
:08002F00A0D9F4DAF275A0FF7C
:08003D007800E84400600A7934
:030045000075A0A3
:0600480000E4F309D8FCFE
:08004E007800E84400600C7921
:0B00560000900000E4F0A3D8FCD9FAF1
:03000800758107F8
:0A000B00120065E5826003020003A5
:04006500758200227E
:00000001FF
main.hex.s19 (srec_cat.exe -mult main.hex -intel -o main.hex.s19):
S0220000687474703A2F2F737265636F72642E736F75726365666F7267652E6E65742F1D
S123000002000812006480FE758107120065E58260030200037900E94400601B7A00900070
S123002069780075A000E493F2A308B8000205A0D9F4DAF275A0FFE478FFF6D8FD7800E820
S12300404400600A790075A000E4F309D8FC7800E84400600C7900900000E4F0A3D8FCD96F
S10C0060FA020003227582002259
S10401FF12E9
S5030005F7
main.omf.s19 (srec_cat.exe -mult main.omf -aomf -o main.omf.s19):
S00700004D41494ED3
S123000002000812006480FE758107120065E58260030200037900E94400601B7A00900070
S123002069780075A000E493F2A308B8000205A0D9F4DAF275A0FFE478FFF6D8FD7800E820
S12300404400600A790075A000E4F309D8FC7800E84400600C7900900000E4F0A3D8FCD96F
S1230060FA0200032275820022FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF59
S1230080FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7C
S12300A0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5C
S12300C0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3C
S12300E0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1C
S1230100FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB
S1230120FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDB
S1230140FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBB
S1230160FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9B
S1230180FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7B
S12301A0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5B
S12301C0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3B
S12301E0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1208
S5030010EC
S9030000FC
omf file (source of other files)
Logged In: YES
user_id=1788180
Originator: YES
File Added: main.hex
generated by linker from omf in link process
Logged In: YES
user_id=1788180
Originator: YES
File Added: main.hex.s19
generated with: srec_cat.exe -mult main.hex -intel -o main.hex.s19
generated with: srec_cat.exe -mult main.omf -aomf -o main.omf.s19
Logged In: YES
user_id=1788180
Originator: YES
File Added: main.omf.s19
Logged In: YES
user_id=1597145
Originator: NO
Record type S9 in the S19 format indicates the starting execution address for a program.
The corresponding data in an Intel Hex file would be encoded as either record type 03 or 05. There are no records of type 03 or 05 present in the source Hex file you've provided as a test case.
IMO it would be inappropriate for SRecord to arbitrarily insert an S9 record in its S19 output when there is no data in the input Hex file from which to derive that information.
Logged In: YES
user_id=1788180
Originator: YES
goosnarrggh,
From srecord's documentation (pdf), description of srec_motorola format:
"S9 - A termination record for a block of S1 records. The address field may optionally contain the 2-byte address of the instruction to which control is passed. If not specified, the first entry point specification encountered in the object module input will be used. There is no data field."
Termination record - so should be present, right? Address field is optional, so record may take the form S903FE?
Regards,
Patryk
The intel hex line
:00000001FF
is an "end of file" record.
The SRecord line
S9030000FC
is an "execution start address" record (a "goto" address for the boot monitor)
There is no one-to-one mapping from one to the other, and srec_cat tries to preserve semantics, although this isn't always possible. The Intel hex input has no execution start address, so the output S19 file doesn't have one, either.
If you want to insert an execution start address into an SRecord file, use the --execution-start-address=0xNNNN command line option.
The AOMF file has an "end of module" record that has no start-address in it, so the S9 record produced from it looks like a bug.
Analysis showed that the original bug was correct operation, however a spurious start address record was being generated when converting from AOMF. This has been fixed.