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.
