srecord-users — This list is for discussion of how to use SRecord.

Re: [srecord-users] STM32 for FLASH CRC ?

[Niall P. <st...@np...>]

On 2026-03-24 06:26, Vytautas wrote:
>   You could:
> - customize STM32H7xx CRC engine so that it would output the result
> matching that of srec_cat
> - tinker a bit with srec_cat CRC calculation by adding additional filters
>
> E.g. check the following srec_cat CRC calculation which includes additional
> filtering:
> $ srec_cat '(' '(' '(' fw.hex -intel -fill 0xff -over fw.hex -intel
> -range-padding 4 ')' -offset - -minimum-address fw.hex -intel ')' -exclude
> 264 268 -exclude 268 270 -exclude 270 292 -length_little_endian 264 4
> -generate 270 289 -repeat_string "$(date +'%F %T')" -fill 0x0 289 292 ')'
> -bit_reverse -crc16_big_endian 268 0x8005 -bit_reverse -o fw.bin -binary
>
> E.g. check the following srec_cat calculation for quick result of a known
> string:
>
> $ echo -n "123456789" | srec_cat.exe - -binary -bit-reverse
> -crc32_big_endian 0x100 -bit-reverse -not -crop 0x100 0x104 -o - -hex_dump
>
> _______________________________________________
> srecord-users mailing list
> sre...@li...
> https://lists.sourceforge.net/lists/listinfo/srecord-users

The STM32H7xx CRC algorithm is mostly cast in silicon so accommodations 
will need to be elsewhere. For now I've patched the -STM32 filter in 
srecord, I wasn't aware of the option to use additional filters and will 
investigate, thanks.

An additional complication is that the CRC hardware works in fairly 
large minimum chunks (128 bytes) so comparing with other standards needs 
another layer.

I've opened an issue on Github to add as a new feature but my C++ coding 
skills are non-existent, may take a little while before something worth 
merging !

      ... Niall

Re: [srecord-users] STM32 for FLASH CRC ?

[Vytautas <vy...@gm...>]

 You could:
- customize STM32H7xx CRC engine so that it would output the result
matching that of srec_cat
- tinker a bit with srec_cat CRC calculation by adding additional filters

E.g. check the following srec_cat CRC calculation which includes additional
filtering:
$ srec_cat '(' '(' '(' fw.hex -intel -fill 0xff -over fw.hex -intel
-range-padding 4 ')' -offset - -minimum-address fw.hex -intel ')' -exclude
264 268 -exclude 268 270 -exclude 270 292 -length_little_endian 264 4
-generate 270 289 -repeat_string "$(date +'%F %T')" -fill 0x0 289 292 ')'
-bit_reverse -crc16_big_endian 268 0x8005 -bit_reverse -o fw.bin -binary

E.g. check the following srec_cat calculation for quick result of a known
string:

$ echo -n "123456789" | srec_cat.exe - -binary -bit-reverse
-crc32_big_endian 0x100 -bit-reverse -not -crop 0x100 0x104 -o - -hex_dump

[srecord-users] STM32 for FLASH CRC ?

[Niall P. <st...@np...>]

Hello,

I'm trying to generate CRCs compatible with the built in CRC computation 
of the FLASH controller of the STM32H7xx (and possibly others). 
Unfortunately it isn't quite the same algorithm as the CRC peripheral 
available in many STM32 micros and so the -STM32 filter doesn't work 
(not that I've been able to get a match between the srec_cat -STM32 
output and either of the FLASH CRC unit nor the peripheral CRC 
calculations either).

We do however have a sw emulation of the FLASH CRC algorithm from AN5507 
so I was thinking it would be nice to have that as another option for 
srec_cat. Has anyone already got this working in a private branch they'd 
care to share ?

I've pulled the latest 1.65 tarball from sourceforge and have started 
trying to hack it in but I'm really not a C++ programmer so any help 
would be appreciated. There doesn't appear to be a current public git 
repo for srecord, found a couple on GitHub but they are at least one 
release behind sourceforge. Is all development handled through this 
mailing list ?

Thanks.

             ... Niall

[srecord-users] Porting to OpenWrt

[Russell S. <ru...@pe...>]

I am trying to port srecord to OpenWrt, a cross-compiling build environment
targeting primarily small devices like wireless routers. My initial
attempts have run into a compilation error. I wonder if anyone familiar
with the code base can offer suggestions on how to adapt it for my purpose.

Here's a link to the compile.txt build log:


https://gist.github.com/RussellSenior/12ff6252f3208fec7bbc7cf0c0861563#file-gistfile1-txt

Thanks for any clues!

-- 
Russell Senior
ru...@pe...

[srecord-users] hex file format not supported ?

[dennis b. <den...@gm...>]

Hello everybody,

I ran into a problem using srec_cat. It looks like my hexfile format is
not supported.

It is an intel hexfile but with a romwidth of 2 bytes.

A snipped from my current hexfile looks like this:
:020000040008F2
:06400000BEEF7FFF000A85
:044004000049B92690
:20400800FFFF000000FC00000000000077AA00000063000500000000000000000000000015
:20401800000000000000000000000000000000000000000000000000000000000000000088
:20402800000000000000000000000000000000000000000000000000000000000000000078

The problem is, that the "length" information in the record is based on
octets (bytes) but the "address offset" is based on 16 bit.
"-intel_hex_16" processes the "address offset" in a correct way but runs
into problem when checking the record (record to short).
"-intel" processes the record correctly but thinks the "address offset"
is based on 8 bits.

I looked at the sources to check if there are more options when using
"-intel" or "-intel_hex_16". Unfortunately there are no options
regarding my problem.

I think it could be easyly done with an additional option e.g.
"romwidth16" within the "-intel" format.
If romwidth16 is given then processing of the "address offsets" should
work like in the "-intel_hex_16" format.
Like this:
         record::address_t address_field =
              2 * record::decode_big_endian(buffer + 1, 2);

As a background:
I'd like to use srec_cat to generate a crc within the hexfile. The
hexfile is generated with "hex2000" which is a tool from Texas
Instruments for their C2000 family of controllers. There are also other
solutions to generate this crc within the hexfile e.g. using the linker
from Texas Instruments. But using srec_cat would be the more general
solution.

Maybe someone can help here.
I would be very glad.

kind regard,
Dennis

Re: [srecord-users] SRecord at 25

[Markus H. <mar...@we...>]

Am Mittwoch, 5. April 2023, 23:44:13 CEST schrieb Scott Finneran via srecord-users:
> [...]
>
> It dawned on me this morning that all of this was quite a while ago. According
> to the logs, just over a quarter century:
>
>      Version 1.1 (1998-Mar-22)
>      First public release.

Thanks for sharing some interesting background, Scott! Nice to read.

25 years ago I didn't even have a proper computer (the family PC
"running" OS/2 with too less RAM) nor any skills.

Markus

[srecord-users] SRecord at 25

[Scott F. <sco...@ya...>]

Hello Everyone,

I just realised that we've recently had a bit of a milestone with SRecord. 
Version 1.1 was release a little over 25 years ago! At the time I worked with 
Peter Miller and we were struggling withe some typical crufty tools used to 
convert the output of a compiler (Motorola SRecords) to what our EPROM 
Programmer would accept (yes, EPROM with the UV windows and metallic stickers).

If I remember correctly, a new board had a bigger address range and so a 
different record type suddenly appeared. The crufty tools silently corrupted 
things and we lost days trying to figure out why modules would suddenly crashed. 
We talked at the bus stop about how it could be fixed and issues prevented in 
the future.

Peter had a LONG commute, boundless energy and a laptop. While writing a 
replacement, he decided to make it generic. In making it generic he started to 
play with some polymorphism patterns which he called filters (similar to a chain 
of responsibility for those who are into that sort of thing)... and SRecord was 
born.

It dawned on me this morning that all of this was quite a while ago. According 
to the logs, just over a quarter century:

     Version 1.1 (1998-Mar-22)
     First public release.

Impressively, SRecord is still growing and apparently still useful. We have a 
new release coming up which fixes a bunch of bugs, improves OS X builds, 
modernises the codebase and actually adds three new file formats! I know Peter 
would be pleased.

My thanks to everyone who has contributed along the way whether it be code, bug 
reports or just downloading and using the work of a guy who genuinely thought 
outside of the box.

Happy Hacking Everyone,

Scott

For those wanting to follow along, the git repo on SourceForge is current but 
most of the development activity these days is over on GitHub.
https://github.com/sierrafoxtrot/srecord

Re: [srecord-users] Git merge questions

[Scott F. <sco...@ya...>]

Thanks Josef & Markus for the responses. Looks like common sense can indeed prevail.

> 
> 1. Squash merges for feature branches Y/N
> 2. Rebasing Y/N
> 3. Adopting a workflow like gitflow
>
1. Use common sense, encourage folks to keep clean PRs. Multiple commits is fine 
but encourage clean separation of issues between them.
2. Rebasing in the PR is definitely my preference too.
3. Gitflow Fashionable but not warranted; certainly not at this scale. Josef's 
link added to the reading list!

Thanks everyone.

Scott

Re: [srecord-users] Git merge questions

[Markus H. <mar...@we...>]

Am Sonntag, 23. Oktober 2022, 11:39:10 CEST schrieb Scott Finneran via
srecord-users:
> Most of my experience with git has been in corporate environments where
> policies are pretty rigid and so before I go merging anything, I was
> wondering whether there were strong feelings on:
>
> 1. Squash merges for feature branches Y/N

I'd only squash-merge if the feature should only consist of one commit.
In case of two or more commits, for me merge or rebase+merge (for a
simpler/cleaner history) both is OK.

> 2. Rebasing Y/N

Interactive rebase is Git's killer feature for me :)

> 3. Adopting a workflow like gitflow

I can't understand why this gitflow became so famous. Developing on a
"develop" branch and using "master" as a tagging-only branch just
doesn't make sense.

> For me, my choices until now have been:
> 1. Yes. I've been squashing for the usual reasons; mostly an attempt at a
> clean repo history.
> 2. Nope, mostly because I don't trust myself to screw up horribly.
> 3. Kinda leaving this to see how many contributions come in. For now, was
> just planning to merge feature branches and release from master with a tag.

Sounds sensible. No need for a complex workflow model.

Markus

Re: [srecord-users] Git merge questions

[<jt...@us...>]

About
1. Squash merges for feature branches Y/N
2. Rebasing Y/N
3. Adopting a workflow like gitflow

My choices

1. Depends on the PR
Yes if a PR is full of "fix previous commit"

But I do squash & rebase my feature branches to a useful set of commits 
before creating a PR (otherwise there would be dozens of commits).
Hopefully the diff and message of each commit helps in understanding, 
why that specific change was needed. It shall help the reviewer, and 
later any developer, or when searching for bugs
e.g. do preparations/refactoring in a separate commit (non-functional 
change, tests untouched)

2.
For having a linear history I do prefer rebasing. At least before 
creating the PR.
As long as not many old/long parallel branches are merged, a graphical 
log view looks nice.

The Github "squash & merge" is in fact a "squash & rebase & 
ff-only-merge" as far as I read the documentation.
Having an extra merge commit for every single squashed feature branch 
would look strange.

So an alternative is to do a "rebase & merge" and retain the commits. I 
don't think SRecord will reach 10,000 commits anytime soon.

3. Keep it simple as you planned.
I don't expect that SRecord needs release branches to stabilize changes 
before release.
Neither do I expect that you want to do that many maintenance branches 
to backport bugfixes.
Gitflow may be ok for big projects, where steps are automated (e.g. 
bugfixes automatically applied to all newer releases), but definitely 
not for an easily human readable log.
Please see https://www.endoflineblog.com/gitflow-considered-harmful for 
some visual explanations.

Josef

Re: [srecord-users] Release of SRecord 1.65

[Markus H. <mar...@we...>]

Hello Scott,

that are amazing news! Many thanks for all the work you put into
reviving the project.
To be honest, I didn't expect that to happen anymore.
And when reading about the reasons for the absence it seems like not
having been an easy time and we can probably be lucky that you are back
again.
Great also that you invested effort to retain development history.

Markus

[srecord-users] Git merge questions

[Scott F. <sco...@ya...>]

A huge thank you to Josef(jxta), fenugrec and David for highlighting some 
hiccups with release 1.65. Most appreciated of course are the pull requests and 
pointers to features that I missed. Looks like release 1.66 won't be too far away...

Most of my experience with git has been in corporate environments where policies 
are pretty rigid and so before I go merging anything, I was wondering whether 
there were strong feelings on:

1. Squash merges for feature branches Y/N
2. Rebasing Y/N
3. Adopting a workflow like gitflow

For me, my choices until now have been:
1. Yes. I've been squashing for the usual reasons; mostly an attempt at a clean 
repo history.
2. Nope, mostly because I don't trust myself to screw up horribly.
3. Kinda leaving this to see how many contributions come in. For now, was just 
planning to merge feature branches and release from master with a tag.

Any thoughts?

Cheers,
Scott

Re: [srecord-users] Release of SRecord 1.65

[<jt...@us...>]

Hi Scott,

Good to hear that you are back on your way.
Thanks for the effort.

Best Regards, Josef

[srecord-users] Release of SRecord 1.65

[Scott F. <sco...@ya...>]

Hello Everyone,

After a (hopefully forgivable) extended absence, Version 1.65 of SRecord has 
been released and is available on SourceForge.

https://srecord.sourceforge.net/

The source is also  mirrored on GitHub: https://github.com/sierrafoxtrot/srecord

Please see the end of this message for the release notes.

What took so damn long? The answers are challenges both technical and extremely 
personal.

On the personal front, life is very different for me now than when I offered to 
take on maintaining SRecord during Peter's final months. It was a sincere 
promise but then my own world turned upside down. A few years later, I now have 
the capacity and want to deliver on my promise.

On the technical front, SRecord was developed by Peter using a catalog of his 
other amazing tools including Aegis (version control), cook (build system), 
tardy (package manipulator) plus a swag of custom build scripts to auto-generate 
all of the documentation from groff/nroff sources. It's an amazing system; fix a 
typo in a single man page and the system completely rebuilds the software, 
documentation, website and packages including running the regression suite. 
Sadly with Peter's passing, these tools also fell behind in terms of maintenance 
meaning that to support SRecord in the original manner, I'd need to support 
three or more other packages much larger in scale than SRecord itself.

These systems have/had a fiercely loyal userbase but only one core developer. 
This in itself limited the ability of a wider community to contribute to SRecord.

So, when I finally had the ability and bandwidth to spend time on SRecord, I 
decided to simply move it away from aegis, cook et. al. This of course was 
anything but simple. This process failed a couple of times leaving a result so 
far below the standard Peter set and I shamefully just abandoned the work. Plus, 
the idea of throwing away the history of SRecord development representing years 
of Peter's efforts just didn't sit right.

So, after a few failed attempts and the time afforded by a global pandemic, I 
stepped back and tried to set a few goals:
1. Retain as much of the development history for posterity.
2. Gather together bug fixes and patches maintained by folks such as those 
reading this. Add some of the additional bits such as doco or tests where gaps 
existed.
3. Adopt relatively modern tools to encourage contributions.
4. Have a windows build as a first-class-output including (gasp) an installer. I 
don't use Windows for development but plenty of embedded software engineers do 
for various reasons.
5. Retain as much of the underlying tooling such as generated documentation as 
possible. Many (and I mean MANY) of the SRecord downloads are actually for the 
file format documentation in the reference manual.
6. Get the damn thing out the door and stop being paralysed by imposter syndrome.

I think I've managed to hit those goals to some degree or another. This included 
cobbling together a minimally functional aegis system and porting the full 
history to a git repo tagging each release rather than each changeset as a 
compromise. For anyone wanting a trip along memory lane, git log is your friend.

So, I present SRecord 1.65. The changelog has a list of functional differences 
including some great community contributions.

But where we've landed:
- SRecord is now Maintained in a git repo including ported history at both 
SourceForge and GitHub (https://github.com/sierrafoxtrot/srecord)
- It has a mostly new Build and config system is cmake (replacing both cook and 
autoconf. Please note that the old Makefile was generated by cook using info 
from aegis; it was never intended for human consumption.
- It builds on Linux and Windows (the latter under MSYS2). Both are native builds.
- Documentation builds out of cmake. Test suite runs on both platforms.
- It creates binary installers for both platforms (TGZ, deb, rpm for Linux; NSIS 
installer and zip for windows).
- The project is still held at SourceForge but is mirrored at GitHub. I suspect 
more patches will come in via the latter.
- The SourceForge website is updated but the style is maintained and still built 
out of the repo.
- All bug fixes (including a couple of new ones) and features (via marcows) are 
merged. I've augmented with doco and tests where there were gaps.

I'm posting this hoping that it is well received. Meanwhile, I have plenty of 
new features in mind which I'll post details and calls for help to the list 
separately.

Meanwhile, enjoy and I await the bug reports, pull-requests and patches.

Happy Hacking,

Scott Finneran


Version 1.65 (2022-Oct-09)

• HP64000 absolute file format contributed by fenugrec. Supports file input, 
tests and documentation.

• Patch by dg1yfe as pulled from github via marcows. Updated man page for 
srec_ppb. Updated PPB output to match checksum range for output. Updated tests 
for PPB write and read including files containing holes. Tweaked patch to handle 
multi-line and arbirtary ascii before SOH. Added test for prolog stripping.

• Added NSIS installer build for Windows

• Verbose srec_info as suggested by Thomas. Display basic info on the proportion 
of input files which data/holes.

• Bug fix from xiretza for COE generation falsly detecting holes in input.

• Remove dependencies on boost moving to std shared_ptr and static_assert. 
Remove doc references to boost.

• Full Windows build, test and packaging supported under MSYS2. Build 
documentation updated to cover Windows and windows web page deprecated.

• Fixed buffer overflow in four packed code output generator.

• Markus Heidelberg <mar...@we...> contributed a patch to fix a bug 
that he also found with the -generator which resulted in an endless loop.

• Completely new build and config system to replace Aegis, Cook and autoconf 
with cmake & git. Integration with cpack to generate linux and windows packages. 
Integration with ctest to sustain the regression test suite. Development history 
migrated to git.

Re: [srecord-users] Srecord on mac

[<eri...@zf...>]

Hi Jan,

I don't have a Mac but just a quick guess:
Maybe you want to have a look at my first answer to Glenns problem in January 2015 .
It was also related to "-" not being "-" when copying from somewhere ...
http://sourceforge.net/p/srecord/mailman/message/33261198/

Best regards,
Erik


-----Ursprüngliche Nachricht-----
Von: Jan Szymanski [mailto:Jan...@ut...] 
Gesendet: Sonntag, 30. August 2015 02:42
An: sre...@li...
Betreff: [srecord-users] Srecord on mac

Hi,


When trying to build Srecord on Macbook Pro (OS X Yosemite 10.10.5)


I have the following error:

JANs-MacBook-Pro:srecord-1.64 janszymanski$ make libtool --mode=compile --tag=CXX g++  -g -O2 -I. \
        -c srec_cat/arglex3.cc -o srec_cat/arglex3.lo
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: unknown option character `-' in: --mode=compile
Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT] [-no_warning_for_no_symbols]
Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name] [-compatibility_version #] [-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table <filename>] [-seg_addr_table_filename <file_system_path>] [-all_load] [-noall_load]
make: *** [srec_cat/arglex3.lo] Error 1
JANs-MacBook-Pro:srecord-1.64 janszymanski$

Any advice how to fix it, please?

Regards

Jan



UTS CRICOS Provider Code: 00099F
DISCLAIMER: This email message and any accompanying attachments may contain confidential information.
If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of the University of Technology Sydney.
Before opening any attachments, please check them for viruses and defects.

Think. Green. Do.

Please consider the environment before printing this email.
------------------------------------------------------------------------------
_______________________________________________
srecord-users mailing list
sre...@li...
https://lists.sourceforge.net/lists/listinfo/srecord-users

[srecord-users] Srecord on mac

[Jan S. <Jan...@ut...>]

Hi,


When trying to build Srecord on Macbook Pro (OS X Yosemite 10.10.5)


I have the following error:

JANs-MacBook-Pro:srecord-1.64 janszymanski$ make
libtool --mode=compile --tag=CXX g++  -g -O2 -I. \
        -c srec_cat/arglex3.cc -o srec_cat/arglex3.lo
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: unknown option character `-' in: --mode=compile
Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT] [-no_warning_for_no_symbols]
Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name] [-compatibility_version #] [-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table <filename>] [-seg_addr_table_filename <file_system_path>] [-all_load] [-noall_load]
make: *** [srec_cat/arglex3.lo] Error 1
JANs-MacBook-Pro:srecord-1.64 janszymanski$

Any advice how to fix it, please?

Regards

Jan



UTS CRICOS Provider Code: 00099F
DISCLAIMER: This email message and any accompanying attachments may contain confidential information.
If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or
attachments. If you have received this message in error, please notify the sender immediately and delete
this message. Any views expressed in this message are those of the individual sender, except where the
sender expressly, and with authority, states them to be the views of the University of Technology Sydney.
Before opening any attachments, please check them for viruses and defects.

Think. Green. Do.

Please consider the environment before printing this email.

[srecord-users] Deprecated warning when creating constant and checksum

[Günther J. <gue...@je...>]

Hi,

we use creating constants and checksums in our project makefiles like
this:
srec_cat -generate $$(($(APPLICATION_END) - 2)) \
           $(APPLICATION_END) -l-e-constant $(MAGIC_NUMBER) 2 \
           $@ -Intel -fill 0xFF 0x0 $$(($(APPLICATION_END) - 4)) \
           -l-e-checksum-neg $$(($(APPLICATION_END) - 4)) 2 2 \
           -crop $$(($(APPLICATION_END) - 4 )) $(APPLICATION_END) \
           $@ -Intel -o $@ -Intel

We use different clients and starting with srecord 1.60 the option
-l-e-constant is deprecated:
>> srec_cat: warning: option "-Little_Endian_CONSTant" is deprecated, 
>> please use "-CONSTant_Little_Endian" instead

So now our problem: Versions before 1.60 don't know -const-l-e and there
is no possibility to use a option both versions understand. The
deprecation warning is rather anoying, but it works. The deprecation of
this options is not announced in the changelog. The "problem" is
introduced in srecord/arglexx.cc in function tolen_next:

            // little endian deprecated variants
            assert(!starts_with(tp->name, "-Little_Endian_"));
            if (ends_with(tp->name, "_Little_Endian"))
            {
                std::string name3 =
                    "-Little_Endian_" +
                    std::string(tp->name + 1, strlen(tp->name) - 15);
                if (compare(name3.c_str(), arg.c_str()))
                {
                    hit[nhit++] = tp;
                    deprecated_warning(name3.c_str(), tp->name);
                }
            }

Would it be possible to remove this deprecation warning as i don't see a
reason for this? Anyway: srecord is a great tool! Keep on rocking!

Best regards
  Günther Jena

Re: [srecord-users] Motorola to Binary conversion

[Glenn H. <ghe...@ap...>]

Hi Alin,

I didn't do anything special to install using home brew. I didn't see any tests run during the install. I can provide the console if needed. 

   ... Glenn

Sent from my mobile. 

> On Jan 23, 2015, at 8:50 AM, Alin Pilkington <api...@mo...> wrote:
> 
> Hi Glenn...I'm shamed that I still haven't completed what I told Scott I would do which is to document the approach for building srecord on os x.   I got it all working using MacPorts but I see you used Home-Brew.  How easy was it using Home-Brew to build and run the tests (the test suite comes with the distribution)?  Were you able to run the test suite and did they all pass? 
> 
> Thanks (and sorry for this being of topic from your original email). 
> 
> Alin 
> 
> 
> 
> From:        Glenn Henshaw <ghe...@ap...> 
> To:        sre...@li..., 
> Date:        01/22/2015 05:33 PM 
> Subject:        [srecord-users] Motorola to Binary conversion 
> 
> 
> 
>   I ran into an issue with record to binary conversion. The examples in the manual don’t seem to work. This is with version 1.64D001 built through home-brew on MacOS.
> 
>  The fixed case below fails.
> 
> $ srec_cat bin/file.s19 −offset - 0x08020000 -o bin/file.bin -binary
> srec_cat: offset: -motorola address multiple 134348800 not understood (do you
>    need parentheses to group the expressions differently?)
> 
>  As does the recommended:
> 
> $ srec_cat bin/mintakaDFU.s19 −offset − −minimum-addr bin/mintakaDFU.s19 -o bin/mintaka.bin -binary
> srec_cat: offset: open: No such file or directory
> 
> Could someone provide some pointers as to how to do this conversion? I’ve tried a number of bracketing permutations to no avail.
> 
>    … Glenn
> —
> Glenn Henshaw
> 
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> https://urldefense.proofpoint.com/v2/url?u=http-3A__p.sf.net_sfu_gigenet&d=AwIGaQ&c=ByDrzdYw8tO08sJlHDO_Vg&r=0ruxWdUrQWu5AuA2vwVZemoe_Pb_zXQr1QkcXotDhG0&m=9tAi5DFRhHaPgnGVd_nfsSWswo1ihp9AJ4YWUfIB090&s=XFynUYPWQd62AnO10tv83IQQoOPt7OlLr4T3OUlsQEg&e= 
> _______________________________________________
> srecord-users mailing list
> sre...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_srecord-2Dusers&d=AwIGaQ&c=ByDrzdYw8tO08sJlHDO_Vg&r=0ruxWdUrQWu5AuA2vwVZemoe_Pb_zXQr1QkcXotDhG0&m=9tAi5DFRhHaPgnGVd_nfsSWswo1ihp9AJ4YWUfIB090&s=qNjH8YHn6HW-xcW-5E2mRjzQjeTKNrXLo6aY2ZBek5s&e= 
> 

Re: [srecord-users] Motorola to Binary conversion

[Scott F. <sfi...@ip...>]

I have my own shame list of things I haven't gotten to on SRecord. Mostly due to
having too much day job and not enough days.

Anything you guys can do to move the state of SRecord on the Mac forward is
really appreciated.

Cheers,
Scott

On 24/01/15 03:50, Alin Pilkington wrote:
> Hi Glenn...I'm shamed that I still haven't completed what I told Scott I
> would do which is to document the approach for building srecord on os x. I
> got it all working using MacPorts but I see you used Home-Brew.  How easy
> was it using Home-Brew to build and run the tests (the test suite comes
> with the distribution)?  Were you able to run the test suite and did they
> all pass?
> 
> Thanks (and sorry for this being of topic from your original email).
> 
> Alin
> 
> 
> 
> From:   Glenn Henshaw <ghe...@ap...>
> To:     sre...@li...,
> Date:   01/22/2015 05:33 PM
> Subject:        [srecord-users] Motorola to Binary conversion
> 
> 
> 
>    I ran into an issue with record to binary conversion. The examples in
> the manual don’t seem to work. This is with version 1.64D001 built through
> home-brew on MacOS.
> 
>    The fixed case below fails.
> 
> $ srec_cat bin/file.s19 ?offset - 0x08020000 -o bin/file.bin -binary
> srec_cat: offset: -motorola address multiple 134348800 not understood (do
> you
>      need parentheses to group the expressions differently?)
> 
>    As does the recommended:
> 
> $ srec_cat bin/mintakaDFU.s19 ?offset ? ?minimum-addr
> bin/mintakaDFU.s19 -o bin/mintaka.bin -binary
> srec_cat: offset: open: No such file or directory
> 
>   Could someone provide some pointers as to how to do this conversion? I’ve
> tried a number of bracketing permutations to no avail.
> 
>      … Glenn
> ?
> Glenn Henshaw
> 
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> https://urldefense.proofpoint.com/v2/url?u=http-3A__p.sf.net_sfu_gigenet&d=AwIGaQ&c=ByDrzdYw8tO08sJlHDO_Vg&r=0ruxWdUrQWu5AuA2vwVZemoe_Pb_zXQr1QkcXotDhG0&m=9tAi5DFRhHaPgnGVd_nfsSWswo1ihp9AJ4YWUfIB090&s=XFynUYPWQd62AnO10tv83IQQoOPt7OlLr4T3OUlsQEg&e=
> 
> _______________________________________________
> srecord-users mailing list
> sre...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_srecord-2Dusers&d=AwIGaQ&c=ByDrzdYw8tO08sJlHDO_Vg&r=0ruxWdUrQWu5AuA2vwVZemoe_Pb_zXQr1QkcXotDhG0&m=9tAi5DFRhHaPgnGVd_nfsSWswo1ihp9AJ4YWUfIB090&s=qNjH8YHn6HW-xcW-5E2mRjzQjeTKNrXLo6aY2ZBek5s&e=
> 
> 
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> srecord-users mailing list
> sre...@li...
> https://lists.sourceforge.net/lists/listinfo/srecord-users
> 

Re: [srecord-users] WG: Motorola to Binary conversion

[Glenn H. <ghe...@ap...>]

  That was it. Apparently a few unicode characters snuck unto the command line when I cut and pasted from my text editor. I’m a happy camper now...
    … Glenn
—
Glenn Henshaw


> On Jan 23, 2015, at 5:40 AM, eri...@zf... wrote:
> 
> Sorry, my first answer went to Glenn directly! Now again to the list as it should be ...
> 
> Hi Glenn,
> 
> I didn't try it myself, just having a quick view on your commandline :
> I do sometimes have trouble copying "code" form somewhere (Word Doc, html) into my DOS Box (sorry, only Win7 over here:-) the reason: out of "--" some platforms convert to a long dash which then is not understood by the shell.
> You might try again deleting all "-" or "--" etc. and adding them manually again, this usually helps me.
> 
> Best regards,
> Erik
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Glenn Henshaw [mailto:ghe...@ap...]
> Gesendet: Freitag, 23. Januar 2015 02:33
> An: sre...@li...
> Betreff: [srecord-users] Motorola to Binary conversion
> 
>  I ran into an issue with record to binary conversion. The examples in the manual don’t seem to work. This is with version 1.64D001 built through home-brew on MacOS.
> 
>  The fixed case below fails.
> 
> $ srec_cat bin/file.s19 −offset - 0x08020000 -o bin/file.bin -binary
> srec_cat: offset: -motorola address multiple 134348800 not understood (do you
>    need parentheses to group the expressions differently?)
> 
>  As does the recommended:
> 
> $ srec_cat bin/mintakaDFU.s19 −offset − −minimum-addr bin/mintakaDFU.s19 -o bin/mintaka.bin -binary
> srec_cat: offset: open: No such file or directory
> 
> Could someone provide some pointers as to how to do this conversion? I’ve tried a number of bracketing permutations to no avail.
> 
>    … Glenn
> —
> Glenn Henshaw
> 
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> srecord-users mailing list
> sre...@li...
> https://lists.sourceforge.net/lists/listinfo/srecord-users
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> srecord-users mailing list
> sre...@li...
> https://lists.sourceforge.net/lists/listinfo/srecord-users

Re: [srecord-users] Motorola to Binary conversion

[Alin P. <api...@mo...>]

Hi Glenn...I'm shamed that I still haven't completed what I told Scott I 
would do which is to document the approach for building srecord on os x. I 
got it all working using MacPorts but I see you used Home-Brew.  How easy 
was it using Home-Brew to build and run the tests (the test suite comes 
with the distribution)?  Were you able to run the test suite and did they 
all pass?

Thanks (and sorry for this being of topic from your original email).

Alin



From:   Glenn Henshaw <ghe...@ap...>
To:     sre...@li..., 
Date:   01/22/2015 05:33 PM
Subject:        [srecord-users] Motorola to Binary conversion



  I ran into an issue with record to binary conversion. The examples in 
the manual don’t seem to work. This is with version 1.64D001 built through 
home-brew on MacOS.

  The fixed case below fails.

$ srec_cat bin/file.s19 ?offset - 0x08020000 -o bin/file.bin -binary
srec_cat: offset: -motorola address multiple 134348800 not understood (do 
you
    need parentheses to group the expressions differently?)

  As does the recommended:

$ srec_cat bin/mintakaDFU.s19 ?offset ? ?minimum-addr 
bin/mintakaDFU.s19 -o bin/mintaka.bin -binary
srec_cat: offset: open: No such file or directory

 Could someone provide some pointers as to how to do this conversion? I’ve 
tried a number of bracketing permutations to no avail.

    … Glenn
?
Glenn Henshaw

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
https://urldefense.proofpoint.com/v2/url?u=http-3A__p.sf.net_sfu_gigenet&d=AwIGaQ&c=ByDrzdYw8tO08sJlHDO_Vg&r=0ruxWdUrQWu5AuA2vwVZemoe_Pb_zXQr1QkcXotDhG0&m=9tAi5DFRhHaPgnGVd_nfsSWswo1ihp9AJ4YWUfIB090&s=XFynUYPWQd62AnO10tv83IQQoOPt7OlLr4T3OUlsQEg&e= 

_______________________________________________
srecord-users mailing list
sre...@li...
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_srecord-2Dusers&d=AwIGaQ&c=ByDrzdYw8tO08sJlHDO_Vg&r=0ruxWdUrQWu5AuA2vwVZemoe_Pb_zXQr1QkcXotDhG0&m=9tAi5DFRhHaPgnGVd_nfsSWswo1ihp9AJ4YWUfIB090&s=qNjH8YHn6HW-xcW-5E2mRjzQjeTKNrXLo6aY2ZBek5s&e= 

[srecord-users] WG: Motorola to Binary conversion

[<eri...@zf...>]

Sorry, my first answer went to Glenn directly! Now again to the list as it should be ...

Hi Glenn,

I didn't try it myself, just having a quick view on your commandline :
I do sometimes have trouble copying "code" form somewhere (Word Doc, html) into my DOS Box (sorry, only Win7 over here:-) the reason: out of "--" some platforms convert to a long dash which then is not understood by the shell.
You might try again deleting all "-" or "--" etc. and adding them manually again, this usually helps me.

Best regards,
Erik


-----Ursprüngliche Nachricht-----
Von: Glenn Henshaw [mailto:ghe...@ap...]
Gesendet: Freitag, 23. Januar 2015 02:33
An: sre...@li...
Betreff: [srecord-users] Motorola to Binary conversion

  I ran into an issue with record to binary conversion. The examples in the manual don’t seem to work. This is with version 1.64D001 built through home-brew on MacOS.

  The fixed case below fails.

$ srec_cat bin/file.s19 −offset - 0x08020000 -o bin/file.bin -binary
srec_cat: offset: -motorola address multiple 134348800 not understood (do you
    need parentheses to group the expressions differently?)

  As does the recommended:

$ srec_cat bin/mintakaDFU.s19 −offset − −minimum-addr bin/mintakaDFU.s19 -o bin/mintaka.bin -binary
srec_cat: offset: open: No such file or directory

 Could someone provide some pointers as to how to do this conversion? I’ve tried a number of bracketing permutations to no avail.

    … Glenn
—
Glenn Henshaw

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
srecord-users mailing list
sre...@li...
https://lists.sourceforge.net/lists/listinfo/srecord-users

[srecord-users] Motorola to Binary conversion

[Glenn H. <ghe...@ap...>]

  I ran into an issue with record to binary conversion. The examples in the manual don’t seem to work. This is with version 1.64D001 built through home-brew on MacOS.

  The fixed case below fails.

$ srec_cat bin/file.s19 −offset - 0x08020000 -o bin/file.bin -binary
srec_cat: offset: -motorola address multiple 134348800 not understood (do you
    need parentheses to group the expressions differently?)

  As does the recommended:

$ srec_cat bin/mintakaDFU.s19 −offset − −minimum-addr bin/mintakaDFU.s19 -o bin/mintaka.bin -binary
srec_cat: offset: open: No such file or directory

 Could someone provide some pointers as to how to do this conversion? I’ve tried a number of bracketing permutations to no avail.

    … Glenn
—
Glenn Henshaw

[srecord-users] Motorola S-record termination record S9 with S3 data record

[<eri...@zf...>]

Hello Scott, hello everybody,

first of all thanks for your effort maintaining SRecord, don't know what we did
without!
I was shocked to read that the original author Peter just left us some
months ago, using srec_cat will keep him and his work in remembrance!!
Thanks, Peter !

I just discovered a strange behaviour of srec_cat
(at least strange in my eyes, maybe I'm wrong! ):

When modifing a file in Motorola S-Record format which contains
S3 data records
S7 end record containing 0 (zero) as execution start address
(using srec_cat) after modification
the S7 record is converted into a S9 record.

Obviously this is done because of the execution start address being zero
(which of course can be represented in a 16bit address ;-) )
The way I read the Motorola S-Record format description (in the srecord manual)
the decision "S7 or S9" is not defined by the execution start address value
but by the type of data records used before.

Technically speaking I don't actually know why S9 record should not be combined
with S3 records in this case but some tool reading our S-Records complains
"Data and end-record in the Motorola S file do not match!",
others just ignore this ...

Can anyone confirm this ? I checked this with Version 1.62, 1.64 and 1.33,
they all behave alike.

I don't actually know where to check/read the "true" description of the
Motorola S-record format,
I doubt there is such a place, I always uses the srecord manual instead :-)


Thanks for you time !

Best regards,
Erik

P.S.
You can also see a similar behaviour by generating S-Record files via srec_cat:

srec_cat.exe -generate 0x80000000 0x80000010 -repeat-string "Erik" -o small.s19 -Execution_Start_Address=0x80000000
-> will generate S7 record
the same commandline with -Execution_Start_Address=0x00000000
-> will generate an S9 record
although in both cases S3 data records are generated.

Re: [srecord-users] [PATCH 4/4] Fix -crop up to the last address

[Markus H. <mar...@we...>]

Am Freitag, 17. Oktober 2014, 19:22:31 schrieb Scott Finneran:
> On 17/10/14 18:47, Markus Heidelberg wrote:
> > Am Samstag, 16. August 2014, 18:30:23 schrieb Scott Finneran:
> >> This is a great collection of patches Markus (and some good pointers to others).
> >> I'll get them integrated once my day job settles back to a manageable level.
> >
> > Still hard at work?
> > I think I have to setup a Windows build to avoid the cumbersome workarounds at
> > my day job :)
> 
> Sadly yes, making progress slowly and also looking at how to neatly handle the 
> edge of address ranges to the interval class itself rather than the code that 
> make use of them.

But modifying the interval class doesn't release the user from looking
for arithmeic overflows, so I see nothing wrong with the patches.

Maybe the class can be improved in some way, but I'd consider it to be a
separate step, even more when having little time.

Markus