AnsweredAssumed Answered

faulty SREC generation

Question asked by Rick Kwan on Oct 2, 2018
Latest reply on Oct 7, 2018 by ZhangJennie

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.

Outcomes