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: Issue with Hex File Generation using C2000 Hex Utility

Part Number: TMS320F28388D
Other Parts Discussed in Thread: UNIFLASH,

Tool/software:

Dear Team
We are using the C2000 Hex Utility for generating hex files. However,  We have observed a discrepancy in the output when using different commands for hex file generation, which is causing compatibility issues with third-party tools and flashing software.
The two command options are:
  1. Hex Generation Command Option 1 : -order MS -romwidth 16 -q --memwidth=16   -> Option which work for uniflash but for not VcdmStudio
  2. Hex Generation Command Option 2 : -order MS -romwidth 16 -q --memwidth=8   -> Option which work for vcdmstudio but for not uniflash
When we use the first command, the hex file is generated successfully but the parameters required for calibration are not visible in third-party tools such as INCA and VCDM Studio. As a result, we are unable to update the parameter values in the hex file (Offline Calibration).
On the other hand, when we use Command 2, the hex file is generated successfully and the parameters used for calibration are displayed correctly in the third-party tools. We are able to update the parameter values in the hex file without any issues. However, we are unable to flash the file in the microcontroller using Uniflash tool, which throws an error. 
Could you please help us understand the difference between these two commands and why Command 1 is not generating a hex file compatible with offline calibration? Additionally, why is Command 2 not generating a hex file compatible with Uniflash flashing software?
Attached are the Command 1 and Command 2 artifacts: Hex file, map file, out file, linker file, a2l file.
  • Here are two lines from command1.hex ...

    Fullscreen
    1
    2
    :20004000FE0296412B4276083B3092BE761F05B1BE00960A761F058106006002BE0192A600
    :200050007E42600E761F05B1920A90015201600576083B3092BE6F047608293092BE92428B
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Here are two lines from command2.hex ...

    Fullscreen
    1
    2
    :2000100022761F76E017241A0100201A03001F76E6170018FDFF0018FEFF1F76E01700CC1D
    :20003000FFF0A91A000300961F76E617001A0200001A01001F76EC1700CCF0FF0A50009659
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Now I repeat the first few characters of each line from command1.hex, with some characters in bold ...

    :200040
    :200050

    Compare that to command2.hex ...

    :200010
    :200030

    The characters in bold are the lower 16-bits of the address for the data on that line.  On the C28x CPU, each address corresponds to 1 16-bit word, and not 1 8-bit byte.  This is different from nearly all other CPUs, where each address corresponds to 1 8-bit byte.  In command1.hex, addresses are counted the same way as the C28x CPU does, where each address corresponds to 1 16-bit word.  In command2.hex, addresses are counted the more typical way, where each address corresponds to 1 8-bit byte.  You can see that here by noticing that addresses in command1.hex advance by 0x10 per line, while addresses in command2.hex advance by 0x20 per line.  This is the case even though all the lines have the same amount of data.

    While I cannot test to be certain, it is a good guess that the third-party tools presume each address corresponds to 1 8-bit byte.  

    Here is one solution to consider.  Uniflash supports the ELF object file produced by the linker.  For Uniflash, do not use the hex file.  Use the .out file instead.  Only use the hex file for the third-party tools.

    Thanks and regards,

    -George

  • Hello ,

    Thank you for the prompt response and the detailed explanation.

    The use case is to update the variable/parameter values in the hex file (Offline calibration). Once the values are updated in the hex file, the same file needs to be flashed in the ECU so that the ECU will use the updated parameter values.

    The VCDMStudio tool team confirmed that they support only 8-bit addressing.

    Is there any workaround so that the existing third-party tool (byte addressing supported tools like VCDM Studio) can calibrate the parameters and that file can be flashable into the ECU?

    Or, as an alternative, could you please suggest a supported calibration tool for the TMS320F28388D microcontroller?

    Thanks,

    Vikram

  • It appears you misunderstand the solution I described.

    The use case is to update the variable/parameter values in the hex file (Offline calibration). Once the values are updated in the hex file, the same file needs to be flashed in the ECU

    Instead of using the hex file (built with --memwidth=8) to flash the ECU, use the .out file instead.

    Thanks and regards,

    -George

  • Hello 

    Thanks you for your reply. 

    I do not want to recompile the code again.

    the third-party tools do not support .out files for offline calibration.

    I want to flash the calibrated file into the ECU. If I use the .out file for flashing and the .hex file for offline calibration, the code can be flashed the first time. However, how can I flash the calibrated firmware file?

    Do I need to convert the calibrated hex file into an out file? If yes, how can I convert it?

    Example.

    • I have a source code where a variable (calibratable) var = 10. I compile the code with the option memwidth = 8, which generates both an out file and a hex file (through the hex utility).

    • I use the .out file for flashing and the .hex file for a third-party tool used for calibration.

    • I update the variable var = 20 and export or save the updated hex file.

    • How can I convert the updated hex file back to an out file so that it can be flashed into the ECU?

    Workflow:

    Thanks

    Vikram