• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 309 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.

TMS320F28388D: Discrepancies in Hex file format - File not supported for Calibration

Vikram Tathe
Prodigy 175 points
Part Number: TMS320F28388D
Other Parts Discussed in Thread: UNIFLASH

Tool/software:

Dear Team,

We are currently generating a hex file from an .out file using the following command with the hex utility:

Command: hex2000 -I <.out> -o <.hex> -order MS --romwidth=16 --memwidth=16

The resulting hex file appears as follows:

 

However, due to discrepancies in byte count and address size, many hex viewer tools display an error such as "Overlapping Lines." Additionally, the file does not seem in standard Intel hex file format.

 

 

We would appreciate your support on the following points:

  1. File Decoding: How can we decode this hex file to determine the specific values at given addresses? Are there any TI-specific tools that can read and interpret this file format?
  2. Offline Calibration Tool: Is there a tool available that can support offline calibration of this TI generated file, specifically for updating variable values in the hex file using an .A2L file as the database without connecting to ECU?  
    This TI generated file with memwidth = 16 is not supported in standard calibration tools like vCDMStudio and INCA due to this overlapping data issue.

 

We look forward to your guidance and suggestions on these matters.

  • 0
    TI__Guru**** 245120 points

    Here is some relevant background ... For most CPU architectures, each address corresponds to 1 8-bit byte.  This is not true on C28x, where each address corresponds to 1 16-bit word.

    Please search the C28x assembly tools manual for the sub-chapter titled Controlling the ROM Device Address.  While I cannot test to be certain, I'm confident the option --byte will solve your problem.  And this sub-chapter explains why.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 175 points

    Dear 


    Thank you for your response.

    We tried the --byte option as per your suggestion and observations are as below:

    Command 1: hex2000 -I <.out> -o <.hex> -order MS --romwidth=16 --memwidth=16

    This hex file works fine and Uniflash also flashed it successfully.

     

     

    Command 2: hex2000 -I <.out> -o <.hex> -order MS --romwidth=16 --memwidth=16 --byte

    Uniflash is unable to flash this hex file on controller producing an error as "[ERROR] C28xx_CPU1: File Loader: Verification failed: Values at address 0x02C020@Program do not match Please verify target memory and memory map."


    If I open this hex file with --byte option in hex viewer then there is some data at location 0x02C020 which is not the case in hex file without --byte option.

     

    I have attached the command_1 and command_2 hex files, MAP files and .cmd file which is common in both cases.

    Debug_Artifacts.zip

    Requesting you valuable input on this.

    Thanks & Regards,

    Vikram Tathe

  • 0 in reply to Vikram Tathe
    TI__Guru**** 245120 points
    Vikram Tathe said:

    Command 1: hex2000 -I <.out> -o <.hex> -order MS --romwidth=16 --memwidth=16

    This hex file works fine and Uniflash also flashed it successfully.

    This behavior is expected.  Uniflash can explicitly handle the unusual way C28x addresses memory.  It also supports reading the executable (.out) file as input.  Converting to a hex file is not necessary.

    Vikram Tathe said:
    If I open this hex file with --byte option in hex viewer then there is some data at location 0x02C020 which is not the case in hex file without --byte option.

    I am not familiar with this hex viewer and how it works.  I can tell you this data appears in both hex files.  Here is the line from Command_1.hex ...

    Fullscreen
    1
    :2060100003E800000000000000000000000000000000000000000000000000000000000085
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Here is the corresponding line from Command_2.hex ...

    Fullscreen
    1
    :20C0200003E800000000000000000000000000000000000000000000000000000000000015
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    To understand what these lines represent, please search the C28x assembly tools manual for the sub-chapter titled Intel MCS-86 Object Format.  You will see that the only difference is the address field and the checksum.  And both change as --byte is documented to affect them.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 175 points

    Hello 

    Thank you for your support.

    1. The primary issue in this case is that the generated file is not compatible with the Uniflash tool (refer to the error screenshot attached in the previous post).

    We also tried flashing using the example codes provided by TI but encountered the same error during the flash process.

    Could you please try flashing the code using the following command and confirm if it works?
    hex2000 -I <.out> -o <.hex> -order MS --romwidth=16 --memwidth=16 --byte

    2. In addition to that, could you please review cmd file attached in the previous post. If i miss anything please suggest.

    Thanks,

    Vikram Tathe 

  • 0 in reply to Vikram Tathe
    Prodigy 175 points

    Hi George,

    I wanted to follow up on the issues mentioned in the previous post.

    Could you please let me know if you've had a chance to look into it and provide any updates?

    Thanks,

    Vikram Tathe

  • 0 in reply to Vikram Tathe
    TI__Guru**** 245120 points
    Vikram Tathe said:
    please try flashing the code using the following command and confirm if it works?
    hex2000 -I <.out> -o <.hex> -order MS --romwidth=16 --memwidth=16 --byte

    Perhaps I didn't explain it clearly enough, but I already said that Uniflash doesn't work when you use --byte.  For Uniflash input, either do not use --byte, or supply the .out file directly.

    Vikram Tathe said:
    please review cmd file attached in the previous post

    I presume you mean the linker command file c2838x.cmd.  To review that file with any depth requires knowledge of the overall system that I do not have.

    Thanks and regards,

    -George