• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 271 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F280025: CCS - C2000 Hex utility - Output format issue (BIN / HEX/ SREC)

Cinqueonce Mattia
Prodigy 55 points
Part Number: TMS320F280025

Hi,

I'm developing a firmware for the device TMS320F280025.

My current CCS version is "12.2.0.00009 ".

I've faced a strange behavior.

I'm using the CCS example "flashapi_ex1_programming" and it can be correctly compiled.

The issue is related to the output generated.

If I change the output format in ""BUILD / C2000 Hex Utility / Output Format Option" I get the following result:

  • BIN
    FW correctly generated, attached in the zip "flashapi_ex1_programming.bin"
    Here below the settings:
  • HEX
    FW NOT correctly generated, attached in the zip "flashapi_ex1_programming.hex"
    Here below the settings:
  • SREC
    FW NOT correctly generated, attached in the zip "flashapi_ex1_programming.srec"
    Here below the settings:

Here below the general settings in "BUILD / C2000 Hex Utility / General Options".

The firmware generated are in the zip attached.

fw_generated.zip

I noticed that the HEX and SREC fw compiled are missing one byte yes and one byte no.

You can check it by opening the file, but I try to show it better here below:

The same happens with the SREC file.

It looks like the file are cropped.

Is there a reason for this bug?

Is there an option in the compiler to get the HEX/SREC file with the same data as BIN file?

Regards,

  • 0
    TI__Guru 50511 points

    Hi,

    I am forwarding the thread to CCS team. Please expect response by tomorrow.

    Regards, Santosh

  • 0 in reply to Santosh Jha
    TI__Guru**** 244120 points

    The likely fix is to add the option --romwidth=16.  To understand why, please see this forum post.  Though ignore the parts about the length of the line.  That is not a concern here.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 55 points

    Hi George,

    Is this a workaround to use "-romwidth=16" or an intentional thing that at default it should be preset?

    Otherwise I add that line as you can see:

    The two files are different at the bottom:

    Actually this is not a big deal because I can continue with my work, this was just my curiosity.

    Best regards

  • +1 in reply to Cinqueonce Mattia
    TI__Guru**** 244120 points
    Cinqueonce Mattia said:
    Is this a workaround to use "-romwidth=16"

    No.  The default is inherited from the predecessor toolchain for C28x, which started in the mid 1980s.  At that time, a default of --romwidth=8 made sense.  It does not make sense today.  But we have learned, over the years, that changing a long standing default creates more problems than it solves.

    Thanks and regards,

    -George