srec_input(1)

✨ NAME ✨

Okay bestie, this is the manual page for srec_input(1) — the whole input file specifications situation. It's the glow-up guide for how input files work with the srec_cat(1), srec_cmp(1) and srec_info(1) commands. 💅

🌈 SYNOPSIS 🌈

srec_* filename [ format ]

💖 DESCRIPTION 💖

So the tea is: this 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:

filename [ format ][ -ignore-checksums ][ filter ... ]

The filename may be specified as a file name, or the special name - which is understood to mean the standard input. 🫶

🎀 Grouping with Parentheses 🎀

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. 😭

🔤 Those Option Names Sure Are Long 🔤

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. 👑

🗂️ File Formats 🗂️

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:

• -Absolute_Object_Module_Format — this option says to use the Intel Absolute Object Module Format (AOMF) to read the file. (See srec_aomf(5) for a description of this file format.)
• -Ascii_Hex — this option says to use the Ascii-Hex format to read the file. See srec_ascii_hex(5) for a description of this file format.
• -Atmel_Generic — this option says to use the Atmel Generic format to read the file. See srec_atmel_genetic(5) for a description of this file format.
• -Binary — this option says the file is a raw binary file, and should be read literally. (This option may also be written -Raw.) See srec_binary(5) for more information. 🧚
• -B-Record — this option says to use the Freescale MC68EZ328 Dragonball bootstrap b-record format to read the file. See srec_brecord(5) for a description of this file format.
• -COsmac — this option says to use the RCA Cosmac Elf format to read the file. See srec_cosmac(5) for a description of this file format.
• -Dec_Binary — this option says to use the DEC Binary (XXDP) format to read the file. See srec_dec_binary(5) for a description of this file format.
• -Elektor_Monitor52 — this option says to use the EMON52 format to read the file. See srec_emon52(5) for a description of this file format.
• -FAIrchild — this option says to use the Fairchild Fairbug format to read the file. See srec_fairchild(5) for a description of this file format.
• -Fast_Load — this option says to use the LSI Logic Fast Load format to read the file. See srec_fastload(5) for a description of this file format.
• -Formatted_Binary — this option says to use the Formatted Binary format to read the file. See srec_formatted_binary(5) for a description of this file format.
• -Four_Packed_Code — this option says to use the FPC format to read the file. See srec_fpc(5) for a description of this file format.
• -Guess — this option may be used to ask the command to guess the input format. This is slower than specifying an explicit format, as it may open and scan and close the file a number of times. 😬
• -HEX_Dump — this option says to try to read a hexadecimal dump file, more or less in the style output by the same option.

This is not an exact reverse mapping, because if there are ASCII equivalents on the right hand side, these may be confused for data bytes. Also, it doesn't understand white space representing holes in the data in the line. 💀

• -IDT — this option says to use the IDT/sim binary format to read the file. See srec_idt(5) for a description of this file format.
• -Intel — this option says to use the Intel hex format to read the file. See srec_intel(5) for a description of this file format.
• -INtel_HeX_16 — this option says to use the Intel hex 16 (INHX16) format to read the file. See srec_intel16(5) for a description of this file format.
• -LOGIsim — this format is read and written by the open source Logisim program. See srec_logisim(5) for more info.
• -Memory_Initialization_File — this option says to use the Memory Initialization File (MIF) format by Altera to read the file. See srec_mif (5) for a description of this file format.
• -Mips_Flash_Big_Endian — this option says to use the MIPS Flash file format to read the file. See srec_mips_flash (5) for a description of this file format.
• -Mips_Flash_Little_Endian — this option says to use the MIPS Flash file format to read the file. See srec_mips_flash (5) for a description of this file format.
• -MOS_Technologies — this option says to use the Mos Technologies format to read the file. See srec_mos_tech(5) for a description of this file format.
• -Motorola [ width ] — this option says to use the Motorola S-Record format to read the file. (May be written -S-Record as well.) See srec_motorola(5) for a description of this file format.

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. 👑

• -MsBin — this option says to use the Windows CE Binary Image Data Format to read the file. See srec_msbin(5) for a description of this file format.
• -Needham_Hexadecimal — this option says to use the Needham Electronics ASCII file format to read the file. See srec_needham(5) for a description of this file format.
• -Ohio_Scientific — this option says to use the Ohio Scientific format. See srec_os65v(5) for a description of this file format.
• -PPB — this option says to use the Stag Prom Programmer binary format. See srec_ppb(5) for a description of this file format.
• -PPX — this option says to use the Stag Prom Programmer hexadecimal format. See srec_ppx(5) for a description of this file format.
• -SIGnetics — this option says to use the Signetics format. See srec_spasm(5) for a description of this file format.
• -SPAsm — this is a synonym for the -SPAsm_Big_Endian option.
• -SPAsm_Big_Endian — this option says to use the SPASM assembler output format (commonly used by PIC programmers). See srec_spasm(5) for a description of this file format.
• -SPAsm_Little_Endian — this option says to use the SPASM assembler output format, but with the data the other way around.
• -STewie — this option says to use the Stewie binary format to read the file. See srec_stewie(5) for a description of this file format.
• -Tektronix — this option says to use the Tektronix hex format to read the file. See srec_tektronix(5) for a description of this file format.
• -Tektronix_Extended — this option says to use the Tektronix extended hex format to read the file. See srec_tektronix_extended(5) for a description of this file format.
• -Texas_Instruments_Tagged — this option says to use the Texas Instruments Tagged format to read the file. See srec_ti_tagged(5) for a description of this file format.
• -Texas_Instruments_Tagged_16 — this option says to use the Texas Instruments SDSMAC 320 format to read the file. See srec_ti_tagged_16(5) for a description of this file format.
• -Texas_Instruments_TeXT — this option says to use the Texas Instruments TXT (MSP430) format to read the file. See srec_ti_txt(5) for a description of this file format.
• -TRS80 — this option says to use the Radio Shack TRS-80 object file format to read the file. See srec_trs80(5) for a description of this file format.
• -VMem — this option says to use the Verilog VMEM format to read the file. See srec_vmem(5) for a description of this file format.
• -WILson — this option says to use the wilson format to read the file. See srec_wilson(5) for a description of this file format.

🧮 Ignore Checksums 🧮

• -IGnore-Checksums — this 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. 💅
• -redundant-bytes=value — use this option to permit a file to contain redundant values for some memory locations. The default is for this condition to be a warning.
  • ignore — no warning or error is issued when redundant settings are detected.
  • warning — a warning is issued when redundant settings are observed, the warning includes the problematic address.
  • error — a fatal error is issued when redundant settings are observed, the fatal error message includes the problematic address and byte value. 😭
• -contradictory-bytes=value — use this when you want to allow a file to have conflicting values for the same memory location 🫶. Whichever value shows up last in the input(s) wins — that's the one that gets used. By default? Yeah no, that's a fatal error bestie 💀. The value can be:
  • ignore — zero warnings, zero errors, we simply do not perceive the contradiction ✨.
  • warning — you get a warning when contradictory settings show up, and the warning tells you the problematic address and the values 👀.
  • error — fatal error time 🚨, and the message includes the problematic address and byte values.

---

🌸 Generators 🌸

Okay so plot twist: you don't have to read data from a file — you can straight-up generate it 🧚. A generator can go anywhere you'd put a file. The spec looks like this:

  -GENerate address-range -data-source

And the -data-source can be any one of these lil guys:

• -CONSTant byte-value — manufactures data where every byte in the given address range is the given byte-value 💅. If byte-value isn't in the range 0..255, that's an error, no cap.

So like, to fill memory addresses 100..199 with newlines (0x0A), you'd do:

  srec_cat -generate 100 200 -constant 10 -o newlines.srec

And obviously you can combine this with data from actual files, because why not 🔥.

• -REPeat_Data byte-value... — manufactures data that repeats the given byte values over and over across the given address range 🎀. If any of the byte-values aren't in the range 0..255, error.

Example: want 0xDE in the even bytes and 0xAD in the odd bytes? Generator goes brrr:

  srec_cat -generate 0x1000 0x2000 -repeat-data 0xDE 0xAD

Important detail bestie: the repeat boundaries are aligned with the base of the address range, modulo the number of bytes ⭐.

• -REPeat_String text — basically -repeat-data's twin, except the data being repeated is the text of the given string 🦋.

For example, to fill the holes in an EPROM image eprom.srec with the text “Copyright (C) 1812 Tchaikovsky”, you combine a generator and an -exclude filter, like this 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 hexadecimal 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 notice 👑: there are two data sources here — the eprom.srec file, and the generated data over an address range covering the first megabyte of memory, but excluding the areas covered by the eprom.srec data.

• -CONSTant_Little_Endian value width — manufactures data with the given numeric value, at a given byte width, in little-endian byte order 💖. If the value doesn't fit into the given byte width, that's an error. It will repeat over and over within the address range.

So to insert a subversion commit number into 4 bytes at 0x0008..0x000B, you'd do something like:

  srec_cat -generate 8 12 -constant-l-e $VERSION 4 \
      -o version.srec

This one's just a convenience wrapper around the -REPeat_Data generator ✨. And yeah, it can absolutely be combined with data from files.

• -CONSTant_Big_Endian value width — same energy as above, but big-endian byte ordering 🌈.

Anything else? Error. That's it, that's the list 💅.

---

🎀 Input Filters 🎀

You can specify zero or more filters to be applied, and they get applied in the order you specify them — order matters, bestie, don't forget 😭.

• -Adler_16_Big_Endian address — inserts an “Adler” 16-bit checksum of the data into the data 🔥. Two bytes, big-endian order, dropped in at the given address. Holes in the input data are ignored. Bytes are processed in ascending address order (not the order they appear in the input).

Note 🫶: if you have holes in your data, you'll get a different Adler checksum than if there were no holes. This matters because the in-memory EPROM image won't have holes. You almost always want to use the -fill filter before any of the Adler checksum filters. You'll get a warning if the data presented for Adler checksum has holes.

Also be aware that the lower and upper bounds of your data may not match the lower and upper bounds of your EPROM 👀. That's another reason to use the -fill filter — it establishes the data across the full EPROM address range.

http://en.wikipedia.org/wiki/Adler-32

• -Adler_16_Little_Endian address — inserts an Adler 16-bit checksum of the data into the data 💖. Two bytes, in little-endian order, inserted at the given address. Holes in the input data are ignored. Bytes are processed in ascending address order (not in the order they appear in the input).

Note 🌸: holes → different Adler checksum than if there were no holes. Important because the in-memory EPROM image will not have holes. You almost always want the -fill filter before any of the Adler filters. You'll get a warning if the data presented for Adler checksum has holes.

And again: the lower and upper bounds of your data might not be the same as your EPROM's bounds — another reason for -fill, because it establishes the data across the full EPROM address range.

http://en.wikipedia.org/wiki/Adler-32

• -Adler_32_Big_Endian address — inserts an Adler 32-bit checksum of the data into the data ⭐. Four bytes, big-endian order, inserted at the given address. Holes in the input data are ignored. Bytes are processed in ascending address order (not in the order they appear in the input).

Note 🦋: holes → 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 the -fill filter before any of the Adler checksum filters. You'll receive a warning if the data presented for Adler checksum has holes.

Also, the lower and upper bounds of your data may not match the lower and upper bounds of your EPROM — another reason to use -fill, since it establishes the data across the full EPROM address range.

http://en.wikipedia.org/wiki/Adler-32

• -Adler_32_Little_Endian address — inserts an Adler 32-bit checksum of the data into the data 💜. Four bytes, in little-endian order, inserted at the given address. Holes in the input data are ignored. Bytes are processed in ascending address order (not in the order they appear in the input).

Note 👑: holes in your data → different Adler checksum than if there were no holes. Important because the in-memory EPROM image will not have holes. You almost always want the -fill filter before any of the Adler checksum filters. You will receive a warning if the data presented for Adler checksum has holes.

And one more time for the people in the back: the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM — another reason to use -fill, because it establishes the data across the full EPROM address range 💅.

http://en.wikipedia.org/wiki/Adler-32

• -AND value — bit-wise ANDs a value onto every data byte 🎀. Super useful if you need to clear bits. Only existing data is altered — no holes get filled, periodt.
• -Bit_Reverse [ width ] — reverses the order of the bits in each data byte 🔄. If you specify a width (in bytes), you can reverse the order of multi-byte values too — this is implemented using the byte-swap filter ✨.
• -Byte_Swap [ width ] — swaps pairs of odd and even bytes 🫶. With a width (in bytes) you can reverse the order of 4 and 8 bytes; the default is 2 bytes. (Widths in excess of 8 are assumed to be a number of bits.) Lowkey important: it's not possible to swap non-power-of-two addresses. If you need to change the alignment, use the offset filter before and after.
• -Checksum_BitNot_Big_Endian address [ nbytes [ width ]] — inserts the one's complement checksum of the data into the data, most significant byte first 💖. The data is literally summed; if there are duplicate bytes, you'll get an incorrect result, and if there are holes, it behaves as if they were filled with zeros. If the data already contains bytes at the checksum location, you need an exclude filter or you'll get errors. You need to apply crop or fill filters before this filter. The value is written most significant byte first. nbytes (how many bytes of resulting checksum) defaults to 4. width (the width in bytes of the values being summed) defaults to 1.
• -Checksum_BitNot_Little_Endian address [ nbytes [ width ]] — inserts the one's complement (bitnot) checksum of the data into the data, least significant byte first 🌸. Otherwise similar to the above.
• -Checksum_Negative_Big_Endian address [ nbytes [ width ]] — inserts the two's complement (negative) checksum of the data into the data 💀. Otherwise similar to the above.
• -Checksum_Negative_Little_Endian address [ nbytes [ width ]] — this one drops the two's complement (negative) checksum of your data right back into the data, little-endian style. Otherwise it's literally the same deal as the filter above 💅
• -Checksum_Positive_Big_Endian address [ nbytes [ width ]] — inserts the simple checksum of the data into the data. Everything else? Same as above, bestie ✨
• -Checksum_Positive_Little_Endian address [ nbytes [ width ]] — the simple checksum, but little-endian. Again, otherwise similar to the ones above 🎀
• -CRC16_Big_Endian address [ modifier... ] — okay so this one is the icon of the whole section, no cap 👑 It inserts an industry standard 16-bit CRC checksum of your data into the data. Two bytes, big-endian order, get inserted at the address you give it.

Holes in the input data are ignored. And listen — bytes are processed in ascending address order, not in the order they happen to appear in the input. Read that again, it matters fr fr.

These extra modifiers are understood:

• number — sets the polynomial to be used to the given number.
• -POLYnomial name — pick the CRC polynomial by name. The known names are:

ibm       0x8005
ansi      0x8005
ccitt     0x1021
t10-dif   0x8bb7
dnp       0x3d65
dect      0x0589

There's a whole table of names and values over at http://en.wikipedia.org/wiki/Cyclic_redundancy_check if you wanna vibe-check it 🦋

• -Most_To_Least — the CRC calculation processes the most significant bit in each byte first, then heads toward the least significant bit. This is the default ⭐
• -Least_To_Most — same party but backwards: the least significant bit in each byte gets processed first, then it walks toward the most significant bit.
• -CCITT — the CCITT calculation is performed. Initial seed is 0xFFFF. This is the default 💜
• -XMODEM — the alternate XMODEM calculation gets performed. Initial seed is 0x0000.
• -BROKEN — a common-but-broken calculation is performed (see note 2 below, bestie, I'm not kidding). Initial seed is 0x84CF 💀
• -AUGment — the CRC gets augmented by sixteen zero bits at the end of the calculation. This is the default ✨
• -No‐AUGment — no augmentation at the end of the calculation. It's less standard conforming, but some implementations do it anyway 🙈

Note: if you've got 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'll get 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. That's another reason to reach for -fill, because it establishes the data across the full EPROM address range. Basically: fill first, thank me later 🫶

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" at http://www.repairfaq.org/filipg/LINK/F_crc_v3.html for more info. 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. Twelve. Combinations. Do it 🧚

• -CRC16_Little_Endian address [ modifier... ] — the same as the -CRC16_Big_Endian filter, except the bytes come out in little-endian byte order 🦋
• -CRC32_Big_Endian address [ modifier... ] — the 32-bit cousin, and she is serving 🔥 This filter inserts an industry standard 32-bit CRC checksum of the data into the data. Four bytes, big-endian order, inserted at the address given. Holes in the input data are ignored. Bytes are processed in ascending address order (not in the order they appear in the input). Also — go read the note about holes up above, it applies here too 👀

These extra modifiers are understood:

• -CCITT — the CCITT calculation is performed. The initial seed is all one bits. This is the default ⭐
• -XMODEM — an alternate XMODEM-style calculation is performed. The initial seed is all zero bits.

• -CRC32_Little_Endian address — the same as the -CRC32_Big_Endian filter, except little-endian byte order 💜
• -Crop address-range — isolates a section of data and discards the rest. Like a little data haircut ✂️
• -Exclude address-range — excludes a section of data and keeps the rest. This is the logical complement of the -Crop filter — same energy, opposite direction 🎀
• -Exclusive_Length_Big_Endian address [ nbytes [ width ]] — the same as the -Length_Big_Endian filter, except the result does not include the length itself 🙈
• -Exclusive_Length_Little_Endian address [ nbytes [ width ]] — the same as the -Length_Little_Endian filter, except the result does not include the length itself.
• -Exclusive_MAXimum_Big_Endian address [ nbytes ] — the same as the -MAXimum_Big_Endian filter, except the result does not include the maximum itself.
• -Exclusive_MAXimum_Little_Endian address [ nbytes ] — the same as the -MAXimum_Little_Endian filter, except the result does not include the maximum itself.
• -Exclusive_MINimum_Big_Endian address [ nbytes ] — the same as the -MINimum_Big_Endian filter, except the result does not include the minimum itself.
• -Exclusive_MINimum_Little_Endian address [ nbytes ] — the same as the -MINimum_Little_Endian filter, except the result does not include the minimum itself.
• -eXclusive‐OR value — bit-wise XORs value against every data byte. Iconic for when you need to invert bits 💅 Only existing data is altered — no holes get filled, periodt.
• -Fill value address-range — fills any gaps in the data with bytes equal to value. The fill only happens inside the address-range you hand it, so no surprise glow-ups elsewhere 🌸
• -Fletcher_16_Big_Endian address [ sum1 sum2 [ answer ]] — inserts a Fletcher 16-bit checksum of the data into the data. Two bytes, big-endian order, at the address you gave. Holes in the input data are ignored. Bytes are processed in ascending address order (not in the order they appear in the input) ⭐

Note: if you've got holes in your data, you'll get a different Fletcher checksum than if there were no holes. This matters because the in-memory EPROM image will not have holes. You almost always want to run the -fill filter before any of the Fletcher checksum filters. You'll get a warning if the data presented for Fletcher checksum has holes ⚠️

Also: the lower and upper bounds of your data may not match the lower and upper bounds of your EPROM. Another reason to use -fill — it establishes the data across the full EPROM address range 🫶

http://en.wikipedia.org/wiki/Fletcher%27s_checksum — go read it, iykyk 📚

You can pick seed values for sum1 and sum2 in the algorithm by adding seed values on the command line. They each default to 0xFF if you don't explicitly state them. The default values (0) mean 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, for 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 isn't specified 🦋

• -Fletcher_16_Little_Endian address — inserts a Fletcher 16-bit checksum of the data into the data. Two bytes, in little-endian order, at the address given. Holes in the input data are ignored. Bytes are processed in ascending address order (not in the order they appear in the input) 💜

Note: holes in your data = a different Fletcher checksum than if there were no holes. Important, because the in-memory EPROM image will not have holes. You almost always want -fill before any of the Fletcher filters. You'll get a warning if the data presented for Fletcher checksum has holes ⚠️

And again: the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. Another reason to use -fill — it establishes the data across the full EPROM address range 🌈

http://en.wikipedia.org/wiki/Fletcher%27s_checksum ✨

• -Fletcher_32_Big_Endian address — inserts a Fletcher 32-bit checksum of the data into the data. Four bytes, big-endian order, at the address given. Holes in the input data are ignored. Bytes are processed in ascending address order (not in the order they appear in the input) 🔥

Note: holes in your data mean 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'll receive a warning if the data presented for Fletcher checksum has holes 💀

Okay so also, bestie, please be aware that the lower and upper bounds of your data are lowkey not always the same as the lower and upper bounds of your EPROM. Which is, like, yet another reason to use the -fill filter — because it will establish the data across the full EPROM address range. Slay. 💅

http://en.wikipedia.org/wiki/Fletcher%27s_checksum

• -Fletcher_32_Little_Endian address — this filter may be used to insert a Fletcher 32-bit checksum of the data into the data. Four bytes, in little-endian order, get inserted at the address given. Holes in the input data are ignored. Bytes are processed in ascending address order (not in the order they appear in the input). 🫶

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. 😭

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

• -Length_Big_Endian address [ nbytes [ width ]] — this filter may be used to insert the length of the data (high water minus low water) into the data. This includes the length itself. If the data already contains bytes at the length location, you need to use an exclude filter, or this will generate errors. The value will be written with the most significant byte first. The number of bytes defaults to 4. The width defaults to 1, and is divided into the actual length, thus you can insert the width in units of words (2) or longs (4). 🔥
• -Length_Little_Endian address [ nbytes [ width ]] — the same as the -Length_Big_Endian filter, except the value will be written with the least significant byte first.
• -MAXimum_Big_Endian address [ nbytes ] — this filter may be used to insert the maximum address of the data (high water + 1) into the data. This includes the maximum itself. If the data already contains bytes at the given address, you need to use an exclude filter, or this will generate errors. The value will be written with the most significant byte first. The number of bytes defaults to 4.
• -MAXimum_Little_Endian address [ nbytes ] — the same as the -MAXimum_Big_Endian filter, except the value will be written with the least significant byte first.
• -Message_Digest_5 address — this filter may be used to insert a 16 byte MD5 hash into the data, at the address given. 🎀
• -MINimum_Big_Endian address [ nbytes ] — this filter may be used to insert the minimum address of the data (low water) into the data. This includes the minimum itself. If the data already contains bytes at the given address, you need to use an exclude filter, or this will generate errors. The value will be written with the most significant byte first. The number of bytes defaults to 4.
• -MINimum_Little_Endian address [ nbytes ] — the same as the -MINimum_Big_Endian filter, except the value will be written with the least significant byte first.
• -NOT — this filter may be used to bit-wise NOT the value of every data byte. Super useful if you need to invert the data. Only existing data is altered, no holes are filled. ✨
• -OFfset nbytes — this filter may be used to offset the addresses by the given number of bytes. No data is lost, the addresses will wrap around in 32 bits, if necessary. You may use negative numbers for the offset, if you wish to move data lower in memory.

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). ikyk 😌

• -OR value — this filter may be used to bit-wise OR a value to every data byte. Useful if you need to set bits. Only existing data is altered, no holes are filled.
• -Random_Fill address-range — this filter may be used to fill any gaps in the data with random bytes. The fill will only occur in the address range given. 🎲
• -Ripe_Message_Digest_160 address — this filter may be used to insert an RMD160 hash into the data.
• -Secure_Hash_Algorithm_1 address — this filter may be used to insert a 20 byte SHA1 hash into the data, at the address given. 👑
• -Secure_Hash_Algorithm_224 address — this filter may be used to insert a 28 byte SHA224 hash into the data, at the address given. See Change Notice 1 for FIPS 180-2 for the specification.
• -Secure_Hash_Algorithm_256 address — this filter may be used to insert a 32 byte SHA256 hash into the data, at the address given. See FIPS 180-2 for the specification.
• -Secure_Hash_Algorithm_384 address — this filter may be used to insert a 48 byte SHA384 hash into the data, at the address given. See FIPS 180-2 for the specification.
• -Secure_Hash_Algorithm_512 address — this filter may be used to insert a 64 byte SHA512 hash into the data, at the address given. See FIPS 180-2 for the specification. 🌈
• -SPlit multiple [ offset [ width ]] — this filter may be used to split the input into a subset of the data, and compress the address range so as to leave no gaps. This is useful for wide data buses and memory striping. The multiple is the bytes multiple to split over, the offset is the byte offset into this range (defaults to 0), the width is the number of bytes to extract (defaults to 1) within the multiple. In order to leave no gaps, the output addresses are (width / multiple) times the input addresses. 💫
• -STM32 address — this is a synonym for the -STM32_Little_Endian filter.
• -STM32_Little_Endian address
• -STM32_Big_Endian address

These filters may be used to generate the CRC used by the hardware CRC unit on the STM32 series of ARM MPUs. The algorithm used by the STM32 hardware unit is just a CRC32 with a different polynomial and word-fed instead of byte-fed. 🧚

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

• -TIGer address — this filter may be used to insert a 24 byte TIGER/192 hash into the data at the address given. 🐯
• -UnFill value [ min-run-length ] — this filter may be used to create gaps in the data with bytes equal to value. You can think of it as reversing the effects of the -Fill filter. The gaps will only be created if the[ ](They)[ ]are at least min-run-length bytes in a row (defaults to 1).
• -Un_SPlit multiple [ offset [ width ]] — this filter may be used to reverse the effects of the split filter. The arguments are identical. Note that the address range is expanded (multiple / width) times, leaving holes between the stripes. 🙈
• -WHIrlpool address — this filter may be used to insert a 64 byte WHIRLPOOL hash into the data, at the address given. 🌀

---

📍 Address Ranges 📍

Okay bestie, there are eight ways to specify an address range:

minimum maximum

If you specify two number on the command line (decimal, octal and hexadecimal are understood, using the C conventions) this is an explicit address range. The minimum is inclusive, the maximum is exclusive (one more than the last address). If the maximum is given as zero then the range extends to the end of the address space. ⭐

-Within input-specification

This says to use the specified input file as a mask. The range includes all the places the specified input has data, and holes where it has holes. The input-specification need not be just a file name, it may be anything any other input specification can be.

See also the -over option for a discussion on operator precedence. 🦋

-OVER input-specification

This says to use the specified input file as a mask. The range extends from the minimum to the maximum address used by the input, without any holes, even if the input has holes. The input-specification need not be just a file name, it may be anything any other input specification can be.

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

filename -fill 0 -over filename2 -swap-bytes

groups as

filename -fill 0 -over '(' filename2 -swap-bytes ')'

when what you actually wanted was

'(' filename -fill 0 -over filename2 ')' -swap-bytes

The command line expression parsing tends to be “greedy” (or right associative) rather than conservative (or left associative). 😭💀

address-range -RAnge-PADding number

It is also possible to pad ranges to be whole aligned multiples of the given number. For example

input-file -fill 0xFF -within input-file -range-pad 512

will fill the input-file so that it consists of whole 512-byte blocks, aligned on 512 byte boundaries. Any large holes in the data will also be multiples of 512 bytes, though they may have been shrunk as blocks before and after are padded.

This operator has the same precedence as the explicit union operator. 🎀

address-range -INTERsect address-range

You can intersect two address ranges to produce a smaller address range. The intersection operator has higher precedence than the implicit union operator (evaluated left to right). ✨

Okay so, address-range combo operators — here's the tea, bestie:

• -UNIon — syntax: address-range -UNIon address-range. You can union two address ranges to produce a larger address range. The union operator has lower precedence than the intersection operator (evaluated left to right). Slay.
• -DIFference — syntax: address-range -DIFference address-range. You can difference two address ranges to produce a smaller address range. The result is the left hand range with all of the right hand range removed. The difference operator has the same precedence as the implicit union operator (evaluated left to right).
• implicit union — syntax: address-range address-range. In addition, all of these methods may be used, and used more than once, and the results will be combined (implicit union operator, same precedence as explicit union operator). No cap.

---

🧮 Calculated Values ✨

Most of the places above where a number is expected, you may supply one of the following:

• - value — The value of this expression is the negative of the expression argument. Note the space between the minus sign and its argument: this space is mandatory. Like, not optional, bestie.

Example time:

srec_cat in.srec -offset − -minimum‐addr in.srec -o out.srec

This example shows how to move data to the base of memory. Iconic.

• ( value ) — You may use parentheses for grouping. 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, such as '(' and ')'.
• -MINimum‐Address input‐specification — This inserts the minimum address of the specified input file. The input specification need not be just a file name, it may be anything any other input specification can be.

See also the -over option for a discussion on operator precedence.

• -MAXimum‐Address input‐specification — This inserts the maximum address of the specified input file, plus one. The input specification need not be just a file name, it may be anything any other input specification can be.

See also the -over option for a discussion on operator precedence.

• -Length input‐specification — This inserts the length of the address range in the specified input file, ignoring any holes. The input specification need not be just a file name, it may be anything any other input specification can be.

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. Love that for us.

In addition, calculated values may optionally be rounded in one of three ways:

• value -Round_Down number — The value is rounded down to the largest integer smaller than or equal to a whole multiple of the number.
• value -Round_Nearest number — The value is rounded to the nearest whole multiple of the number.
• value -Round_Up number — The value is rounded up to the smallest integer larger than or equal to a whole multiple of the number.

And one more time for the people in the back: 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 ')'. Periodt. 💅

📝 COPYRIGHT 🎀

srec_input version 1.65 Copyright (C) 1998... 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.

🫶 MAINTAINER 💌

• Scott Finneran — E‐Mail: scottfinneran@yahoo.com.au
• Peter Miller — E‐Mail: pmiller@opensource.org.au

---

Okay that's the whole page, bestie! Source/version energy: SRecord Reference Manual, srec_input(1), version 1.65. The footer didn't give me a date, so I'm not inventing one — no cap. 🎀✨💅