• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 432 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F2812: Undocumented behavior of Hex2000

Pierre Lando
Prodigy 10 points

Part Number: TMS320F2812

Hello,

Since the latest version of hex2000, I’ve noticed a new warning when using the combination:

--boot --binary

The tool now reports:

warning: binary output requires IMAGE and ROMS directives

However, this raises a question:

  • If I switch from --binary to another format like --ascii, the warning disappears.
  • The generated content appears functionally identical (raw binary vs ASCII-encoded hex values), just represented differently.

So I’m wondering:

  1. Is this warning expected behavior with newer versions of hex2000?
  2. Is there now a strict requirement to define `IMAGE` and `ROMS` directives specifically for binary
    output, even when the memory mapping is already well-defined by the --boot linker command?
  3. Why does this requirement not apply to ASCII output, even though both formats ultimately represent the same data?

From a practical standpoint, the binary output seems valid and usable despite the warning, which makes this change a bit confusing.

Any clarification on the rationale behind this warning and the recommended way to handle it would be appreciated.

While looking for documentation, it appear that the --boot --binary combination is not documented in spru513 while used in the sprujh3 user guide under section 4.1 in the "USB Bootloading:" paragraph.

Thanks.

  • 0
    TI__Guru 59360 points

    Hi, Allow me to get back on this by tomorrow

  • 0 in reply to Nilabh Anand
    TI__Intellectual 2605 points

    Hi Pierre,

    Your inquiry has now been forwarded to and received by the TI compiler tools group.

    I am currently looking into your question about the "binary output requires IMAGE and ROMS directives" warning to understand when the hex2000 started emitting the warning and why.

    In the meantime, can you provide a reproducible example that demonstrates the generation of the warning, along with the command-line that you used to invoke the hex2000 utility?

    Thanks and Regards,

    Todd Snider

  • 0 in reply to Todd Snider
    Prodigy 10 points

    Hi Todd,

    Here the modifiers used to invoke hex2000 (It's generated by CCS from my settings and unchanged since 2010):
    --entrypoint=0x3F8000 --boot --gpio8 --binary

    The full command line look like this (from the logs):
    "C:/ti/ccs2031/ccs/tools/compiler/ti-cgt-c2000_25.11.0.LTS/bin/hex2000" --entrypoint=0x3F8000 --boot --gpio8 --binary -o "firmware.bin" "firmware.out"
    Please note that the CCS version is actually 20.5.0.28__1.11.0

    You can find a reproducible example here: github.com/.../CCS_1642298
    A github action showing the issue is available here: https://github.com/Orace/e2e/actions/runs/25485974484/job/74781518541
    Under the 'Build with CSS' section, line 40: "warning: Output format option --binary requires --image and a ROMS directive to avoid ignoring holes in memory."

    About the when and why:
     - Since C2000 25.11.0.LTS: https://software-dl.ti.com/codegen/esd/cgt_public_sw/C2000/25.11.0.LTS/README.html#hex-utility-warning-for---binary-without---image
     - For me it look's like an unhandled edge case.

    Regards,
    Pierre Lando.

  • 0 in reply to Pierre Lando
    TI__Intellectual 2605 points

    Hi PIerre,

    Is there a .out file in that CCS_1642298 git hub repository somewhere?

    ~ Todd

  • 0 in reply to Todd Snider
    Prodigy 10 points

    Hi Todd,

    No, the ".out" file is not committed to the repository.

    It is generated during the build and ignored by ".gitignore".

    The repository only contains the minimal CCS project required to reproduce the issue.

    The GitHub action now produce it as an artifact, you can find it here https://github.com/Orace/e2e/actions/runs/25522991189/artifacts/6866804720

    This should allow you to run hex2000 directly without rebuilding the project locally.

    Regards,

    Pierre Lando

  • 0 in reply to Pierre Lando
    TI__Intellectual 2605 points

    Hi Pierre,

    I got a 404 error when I tried to access the link you provided above. Could you attach the .out file to this forum thread?

    ~ Todd

  • 0 in reply to Todd Snider
    Prodigy 10 points

    firmware.zip here it is hopefully.

  • 0 in reply to Pierre Lando
    TI__Expert 5130 points

    Hi Pierre,

    25.11.0.LTS includes the warning noted in the readme, as you've observed:

    warning: Output format option --binary requires --image and a ROMS directive to avoid ignoring holes in memory.

    This was always the behavior of the hex utility with respect to binary format and memory holes, but there was no prior diagnostic or documentation outlining this behavior, so the warning was added.  SPRU513 (spru513aa.pdf) was also updated to reflect this behavior (See section on Binary Object Format (--binary Option)).  Please also refer to this article: An Introduction to Binary Files for a bit more background on binary format and reducing holes.

    While looking for documentation, it appear that the --boot --binary combination is not documented in spru513 while used in the sprujh3 user guide under section 4.1 in the "USB Bootloading:" paragraph.

    I'm not sure I follow your question with respect to using --boot. 

    -Alan

  • 0 in reply to Alan Phipps
    Prodigy 10 points

    Hi Alan,

    My understanding is that in this case:

    - "--boot": selects a specific boot image format, which is different from the binary object format referenced in the article you linked earlier.

    - "--binary": only selects how the payload data are encoded (raw bytes instead of ASCII hex).

    The boot format described in SPRU513AA (page 306) is not a flat memory dump. It contains:

    - a header

    - the entry point

    - a sequence of blocks with explicit sizes and target addresses

    Because of this block-oriented structure, the generated boot image already preserves discontinuities between sections. There is therefore no ambiguity caused by “holes in memory” as there would be in a plain binary memory dump.

    This is also consistent with the fact that "--boot --ascii" produces no warning.

    Since "--boot --ascii" and "--boot --binary" generate the exact same boot image structure, differing only in payload encoding (ASCII hex / raw bytes), I would expect the warning behavior to be identical in both cases.

    So unless I am missing something, the warning about binary output and memory holes does not really apply to the boot image generated by "--boot".

    Regards,

    Pierre

  • 0 in reply to Pierre Lando
    TI__Expert 5130 points

    HI Pierre, thank you for clarifying your question. 

    Our expert on the hex utility is out until Thursday this week, and so I will make sure to get an answer to you when he returns.

    -Alan

  • 0 in reply to Alan Phipps
    TI__Guru**** 253380 points

    Thank you for notifying us of this problem, and for submitting a test case.  I am able to reproduce the same behavior.

    Pierre Lando said:
    Because of this block-oriented structure, the generated boot image already preserves discontinuities between sections.

    I agree.  So I filed EXT_EP-13428 to request the hex utility to be changed to not emit this warning when both these options are used: --binary --boot.  You are welcome to follow it with that link.

    If you add the option --display_error_number, you can see the ID number for this diagnostic ...

    warning #21134-D: Output format option --binary requires --image and a ROMS
   directive to avoid ignoring holes in memory.

    To tell hex2000 to not emit this particular diagnostic, add the option --diag_suppress=21134.

    Thanks and regards,

    -George