| srec_input(1) | General Commands Manual | srec_input(1) |
srec_input - input file specifications
srec_* filename [ format ]
This manual page describes the input file specifications for the srec_cat(1), srec_cmp(1) and srec_info(1) commands.
Input files may be qualified in a number of ways: you may specify their format and you may specify filters to apply to them. An input file specification looks like this:
The filename may be specified as a file name, or the special name “-” which is understood to mean the standard input.
There are some cases where operator precedence of the filters can be ambiguous. Input specifications may also be enclosed by ( parentheses ) to make grouping explicit. Remember that the parentheses must be separate words, i.e. surrounded by spaces, and they will need to be quoted to get them past the shell's interpretation of parentheses.
All options may be abbreviated; the abbreviation is documented as the upper case letters, all lower case letters and underscores (_) are optional. You must use consecutive sequences of optional letters.
All options are case insensitive, you may type them in upper case or lower case or a combination of both, case is not important.
For example: the arguments “-help”, “-HEL” and “-h” are all interpreted to mean the -Help option. The argument “-hlp” will not be understood, because consecutive optional characters were not supplied.
Options and other command line arguments may be mixed arbitrarily
on the command line.
The GNU long option names are understood. Since all option names for srec_input are long, this means ignoring the extra leading “-”. The “--option=value” convention is also understood.
The format is specified by the argument after the file name. The format defaults to Motorola S‐Record if not specified. The format specifiers are:
The optional width argument describes the number of bytes which form each address multiple. For normal uses the default of one (1) byte is appropriate. Some systems with 16‐bit or 32‐bit targets mutilate the addresses in the file; this option will correct for that. Unlike most other parameters, this one cannot be guessed.
The -IGnore‐Checksums option may be used to disable checksum validation of input files, for those formats which have checksums at all. Note that the checksum values are still read in and parsed (so it is still an error if they are missing) but their values are not checked. Used after an input file name, the option affects that file alone; used anywhere else on the command line, it applies to all following files.
It is also possible to generate data, rather than read it from a file. You may use a generator anywhere you could use a file. An input generator specification looks like this:
-GENerate address‐range -data‐source
The -data‐source may be one of the following:
For example, to fill memory addresses 100..199 with newlines (0x0A), you could use a command like
srec_cat -generate 100 200 -constant 10 -o newlines.srec
This can, of course, be combined with data from files.
For example, to create a data region with 0xDE in the even bytes and 0xAD in the odd bytes, use a generator like this:
srec_cat -generate 0x1000 0x2000 -repeat‐data 0xDE 0xAD
The repeat boundaries are aligned with the base of the address range, modulo the number of bytes.
For example, to fill the holes in an EPROM image eprom.srec with the text “Copyright (C) 1812 Tchaikovsky”, combine a generator and an -exclude filter, such as the command
If you need to inject binary data into the string (e.g. a terminating NUL character), use the URL encoding that uses % followed by two hexadeimal characters. For example a backspace would be encoded as “%08”.
srec_cat eprom.srec \
-generate 0 0x100000 \
-repeat‐string 'Copyright (C) 1812 Tchaikovsky. ' \
-exclude -within eprom.srec \
-o eprom.filled.srec
The thing to note is that we have two data sources: the eprom.srec file, and generated data over an address range which covers first megabyte of memory but excluding areas covered by the eprom.srec data.
For example, to insert a subversion commit number into 4 bytes at 0x0008..0x000B you would use a command like
srec_cat -generate 8 12 -constant‐l‐e $VERSION 4 \
-o version.srec
This generator is a convenience wrapper around the -REPeat_Data generator. It can, of course, be combined with data from files.
Anything else will result in an error.
You may specify zero or more filters to be applied. Filters are applied in the order the user specifies.
Note: If you have holes in your data, you will get a different Adler checksum than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the Adler checksum filters. You will receive a warning if the data presented for Adler checksum has holes.
You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range.
http://en.wikipedia.org/wiki/Adler‐32
Note: If you have holes in your data, you will get a different Adler checksum than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the Adler filters. You will receive a warning if the data presented for Adler checksum has holes.
You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range.
http://en.wikipedia.org/wiki/Adler‐32
Note: If you have holes in your data, you will get a different Adler checksum than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the Adler checksum filters. You will receive a warning if the data presented for Adler checksum has holes.
You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range.
http://en.wikipedia.org/wiki/Adler‐32
Note: If you have holes in your data, you will get a different Adler checksum than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the Adler checksum filters. You will receive a warning if the data presented for Adler checksum has holes.
You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range.
http://en.wikipedia.org/wiki/Adler‐32
The following additional modifiers are understood:
| ibm | 0x8005 |
| ansi | 0x8005 |
| ccitt | 0x1021 |
| t10‐dif | 0x8bb7 |
| dnp | 0x3d65 |
| dect | 0x0589 |
See http://en.wikipedia.org/wiki/Cyclic_redundancy_check for a table of names and values.
Note: If you have holes in your data, you will get a different CRC than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the CRC filters. You will receive a warning if the data presented for CRC has holes.
You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range.
Note 2: there are a great many CRC16 implementations out there, see http://www.joegeluso.com/software/articles/ccitt.htm (now gone, reproduced at http://srecord.sourceforge.net/crc16-ccitt.html) and “A painless guide to CRC error detection algorithms” http://www.repairfaq.org/filipg/LINK/F_crc_v3.html for more information. If all else fails, SRecord is open source software: read the SRecord source code. The CRC16 source code (found in the srecord/crc16.cc file of the distribution tarball) has a great many explanatory comments.
Please try all twelve combinations of the above options before reporting a bug in the CRC16 calculation.
The following additional modifiers are understood:
Note: If you have holes in your data, you will get a different Fletcher checksum than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the Fletcher checksum filters. You will receive a warning if the data presented for Fletcher checksum has holes.
You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range.
http://en.wikipedia.org/wiki/Fletcher%27s_checksum
It is possible to select seed values for sum1 and sum2 in the algorithm, by adding seed values on the command line. They each default to 0xFF if not explicitly stated. The default values (0) means that an empty EPROM (all 0x00 or all 0xFF) will sum to zero; by changing the seeds, an empty EPROM will always fail.
The third optional argument is the desired sum, when the checksum itself is summed. A common value is 0x0000, placed in the last two bytes of an EPROM, so that the Fletcher 16 checksum of the EPROM is exactly 0x0000. No manipulation of the final value is performed if this value if not specified.
Note: If you have holes in your data, you will get a different Fletcher checksum than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the Fletcher filters. You will receive a warning if the data presented for Fletcher checksum has holes.
You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range.
http://en.wikipedia.org/wiki/Fletcher%27s_checksum
Note: If you have holes in your data, you will get a different Fletcher checksum than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the Fletcher checksum filters. You will receive a warning if the data presented for Fletcher checksum has holes.
You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range.
http://en.wikipedia.org/wiki/Fletcher%27s_checksum
Note: If you have holes in your data, you will get a different Fletcher checksum than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the Fletcher checksum filters. You will receive a warning if the data presented for Fletcher checksum has holes.
You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range.
http://en.wikipedia.org/wiki/Fletcher%27s_checksum
Please note: the execution start address is a different concept than the first address in memory of your data. If you want to change where your monitor will start executing, use the -execution‐start‐address option (srec_cat(1) only).
The address is where to place the 4‐byte STM32 CRC.
The CRC used is documented in “RM0041, STM32F100xx
reference manual”, page 46, chapter “CRC Calculation
Unit”, which can be found at
http://www.st.com/internet/mcu/product/216844.jsp
There are eight ways to specify an address range:
See also the -over option for a discussion on operator precedence.
You may need to enclose input‐specification in parentheses to make sure it can't misinterpret which arguments go with which input specification. This is particularly important when a filter is to follow. For example
This operator has the same precedence as the explicit union operator.
Most of the places above where a number is expected, you may supply one of the following:
See also the -over option for a discussion on operator precedence.
See also the -over option for a discussion on operator precedence.
See also the -over option for a discussion on operator precedence.
For example, the -OVER input‐specification option can be thought of as short‐hand for '(' -min file -max file ')', except that it is much easier to type, and also more efficient.
In addition, calculated values may optionally be rounded in one of three ways:
When using parentheses, they must each be a separate command line
argument, they can't be within the text of the preceding or following
option, and you will need to quote them to get them past the shell, as
'(' and ')'.
srec_input version 1.64
Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller
The srec_input program comes with ABSOLUTELY NO WARRANTY;
for details use the 'srec_input -VERSion License' command. This is
free software and you are welcome to redistribute it under certain
conditions; for details use the 'srec_input -VERSion License'
command.
| Scott Finneran | E‐Mail: | scottfinneran@yahoo.com.au |
| Peter Miller | E‐Mail: | pmiller@opensource.org.au |
| SRecord | Reference Manual |