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.
Tool/software:
Here are two lines from command1.hex ...
:20004000FE0296412B4276083B3092BE761F05B1BE00960A761F058106006002BE0192A600 :200050007E42600E761F05B1920A90015201600576083B3092BE6F047608293092BE92428B
Here are two lines from command2.hex ...
:2000100022761F76E017241A0100201A03001F76E6170018FDFF0018FEFF1F76E01700CC1D :20003000FFF0A91A000300961F76E617001A0200001A01001F76EC1700CCF0FF0A50009659
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 George Mock,
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 George Mock
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