LP-EM-CC2340R5: The bin output from OAD build is different every time

Part Number: LP-EM-CC2340R5

Tool/software:

Hello.

When you build the SDK sample program "basic_ble_oad_onchip", xx_v1.bin and xx_v2.bin are output.

This bin file is different every time I build it, and I don't understand why that is. What's different?
I think there is a bin output setting in the post-build steps, does this have anything to do with it?

The SDK is simplelink_lowpower_f3_sdk_8_20_00_119.

  • Hello Kei,

    Thanks for reaching out. May I ask what are the differences you see when building the image? You are correct, the bin file is passed through the imgtool executable during the post build steps to generate the header.

    BR,

    David.

  • Hello David,

    In the example, the post-build steps are configured to build with the following settings:

    ${CG_TOOL_HEX} -order MS --memwidth=8 --romwidth=8 --intel -o ${ProjName}.hex ${ProjName}.out
    ${CG_TOOL_ROOT}/bin/tiarmobjcopy ${ProjName}.out --output-target binary ${ProjName}_noheader.bin --remove-section=.ccfg
    ${COM_TI_SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR}/tools/common/mcuboot/imgtool sign --header-size 0x100 --align 4 --slot-size 0x44000 --version 1.0 --pad-header --key ${COM_TI_SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR}/source/third_party/mcuboot/root-ec-p256.pem ${ProjName}_noheader.bin ${ProjName}_v1.0.bin
    ${COM_TI_SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR}/tools/common/mcuboot/imgtool sign --header-size 0x100 --align 4 --slot-size 0x44000 --version 2.0 --pad-header --key ${COM_TI_SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR}/source/third_party/mcuboot/root-ec-p256.pem ${ProjName}_noheader.bin ${ProjName}_v2.0.bin

    Does the difference in the bin files mean they were processed with imgtool?bin.zip
    For reference, I will share the actual output bin file.

  • Hello Kei,

    Could you please highlight the difference between the _v1 build 1 and _v1 build 2 binary files? I don't seem to see any.

    BR,

    David.

  • Hello David,

    sorry.
    It was sent by mistake.
    Please refer to here.

    bin_fix.zip

  • Hello Kei,

    I see the difference is in the last bytes, part of which is the generated CRC. I think the tool (img tool) that parses the hex file into bin files during the post build steps is introducing the bytes previous the the CRC. I will came back to you on this. In the meantime, may I understand the use case or if this is blocking somehow your progress?

    BR,

    David.

  • Hello David,

    Thank you for your confimation.

    My way of using it is to write this bin file to a device and then get the FW checksum within the device.
    We obtain the FW checksum and communicate it to the release destination.

    If the checksum is different every time a build is performed, it may become impossible to identify the firmware being used, so we would like to consider operation while keeping this mechanism in mind.

  • Hello Kei,

    I see, may I ask if the checksum should also include the CRC of the image?

    BR,
    David.

  • Hello David,

    I believe it is okay to include CRC in the calculation.
    The purpose is to measure the integrity of the device.

    David, does this mean that the difference between the bin files is the CRC and other data generated by the image tool?

  • Hello Kei,

    The difference is the CRC (32 bytes) plus the rest of the bytes (another 32 bytes) that I highlighted in the previous answer. I am figuring out how are those generated by imgtool. The CRC will be different if anything in the image changes, which again, are those previous 32 bytes as I can see by comparing both bin file images.

    BR,

    David.