faulty SREC generation

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

faulty SREC generation

Jump to solution
921 Views
rick_kwan
Contributor I

I'm trying to generate a SREC as a post build step, but I'm getting non-hexadecimal characters in the output.  This is using a standard "hello world" example.  The output of the first three lines of the SREC file say:

S0160000726B5F68656C6C6F5F77ph�^6C642E7372656337
S1132000000002004123000011230000812C000085
S113201000000000000000000000000000000000BC

Note the first line; there is an aberrant 4-byte sequence "ph<8e>^", that is, { 0x70, 0x68, 0x8e, 0x5e }.  Re-running the build gives the same exact output.  Changing the "managed linker script" options a bit (e.g., global data placement), I can vary the file output, but the aberrant sequence still shows up in the first line.

The post-build steps I'm using are:

arm-none-eabi-size "${BuildArtifactFileName}"
arm-none-eabi-objcopy -v -O srec "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.srec"
checksum -p ${TargetChip} -d "${BuildArtifactFileBaseName}.srec"

The example I'm compiling is a generic "hello world" for MIMXRT1052xxxxB.  Just to check my sanity; I've generated a new very generic project for the same board so that the project name is now "MIMXRT1052xxxxB_Project", and choosing no special options.  I've modified the post-build steps as above.  This time, I get a slightly different sequence of aberrant bytes:

S01F00004D494D58525431303532z~��7878425F50726F6A6563742E7372656304
S3152020000000002420FD022020450320202D1B202017
S31520200010000000000000000000000000000000009A

In this case, the aberrant sequence is { 0x7a, 0x7e, 0x99, 0x81 }.  I'm attaching a few files for this latter case.

The above cases were generated using MCUXpresso IDE v10.2.1 build 795, running on Windows 10.

I'm considering doing a de-install + re-install of the IDE, or switching to a different machine altogether, running macOS or Linux.  But I wonder if anyone else is seeing what I'm seeing.

1 Solution
772 Views
rick_kwan
Contributor I

Yep. That was the problem.  I didn't realize that 'checksum' was actually writing on top of the file.  Not like the Linux 'sum', 'md5sum', and other variants that I am used to.

View solution in original post

0 Kudos
3 Replies
772 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

Hi Rick,

In addition, this is the example of how to use post-build.

MCUXpresso IDE: S-Record, Intel Hex and Binary Files | MCU on Eclipse 

Besides, MCUXpresso IDE integrates Binary Utilities, we can use it to generate hex/bin/s-record directly.

pastedImage_1.png


Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

772 Views
converse
Senior Contributor V

You are running "checksum" on the .srec file. Checksum only works on binary files. It is therefore checksum that is corrupting your SREC

773 Views
rick_kwan
Contributor I

Yep. That was the problem.  I didn't realize that 'checksum' was actually writing on top of the file.  Not like the Linux 'sum', 'md5sum', and other variants that I am used to.

0 Kudos