TMS570LC4357: Arm Hex Utility generates bin file content misalignment issue

Tool/software:

The compiler version is TI v20.2.7.LTS.

After outputting the .out file to a .bin file, when I burn the .bin file to the chip using UniFlash, the firmware does not work properly.

Start analyzing the contents of the bin file:

The ArmHex tool outputs the following relevant parameters for the bin file:

--fill=0xFF --map="xxx.map" --romwidth=32 --diag_wrap=off --binary -o "xxx.bin" "xxx.out"

Add an output mapflie to analyze bin file composition.

Then use the UniFlash tool to burn the.out file to the chip, and then export the flash content and save it as a.bin file. Compare two files using the file comparison tool:

The address of the first difference between the two files here is 0x003b304, and the difference content is as shown in the following figure:

In the preceding figure, the contents of the bin file that can be exported from the flash are on the left, and the contents of the bin file generated by the ArmHex tool are on the right.

Compare the.bin map file with the.out map file.

==================================================================================
.out mapfile:

SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
00000000    00000000    0003b304   0003b304    r-x
  00000000    00000000    00000020   00000020    r-x .intvecs
  00000020    00000020    00000100   00000100    r-- section_image_header
  00000120    00000120    0003b1e4   0003b1e4    r-x .text
0003b320    0003b320    000027d4   000027d4    r--
  0003b320    0003b320    000027d4   000027d4    r-- .const
0003db00    0003db00    00000618   00000618    r--
  0003db00    0003db00    00000618   00000618    r-- __param
0003e120    0003e120    00000048   00000048    r--
  0003e120    0003e120    00000048   00000048    r-- clisection
0003e180    0003e180    000002b8   000002b8    r--
  0003e180    0003e180    000002b8   000002b8    r-- .cinit
08010000    08010000    0002c638   00000000    rw-
  08010000    08010000    0001a8c0   00000000    rw- .bss
  0802a8c0    0802a8c0    00009d76   00000000    rw- .data
  08034638    08034638    00008000   00000000    rw- .sysmem


==================================================================================
.bin mapfile:

OUTPUT TRANSLATION MAP
--------------------------------------------------------------------------------
00000000..ffffffff  Page=0  Memory Width=8  ROM Width=8
--------------------------------------------------------------------------------
   OUTPUT FILES: xxx.bin [b0..b7]

   CONTENTS: 00000000..0000001f   xxx.out(.intvecs)
             00000020..0000011f   xxx.out(section_image_header)
             00000120..0003b303   xxx.out(.text)
             0003b320..0003daf3   xxx.out(.const)
             0003db00..0003e117   xxx.out(__param)
             0003e120..0003e167   xxx.out(clisection)
             0003e180..0003e437   xxx.out(.cinit)

From both map files, you can see that the address of the.text field is 0x00000120 to 0x0003b303, and the address of the following.const field is 0x0003b320 to 0x0003daf3.

The description of the two map files is the same, which means that the range of addresses 0x0003b304 to 0x0003b31 should be filled with 0xFF or other useless data.

However, in the actual bin file content, it can be found that the content of the.const field in the bin file generated by the ArmHex file is continuously written to the address 0x0003b304, resulting in all subsequent content generated the address dislocation.

Therefore, the bin file generated by ArmHex cannot correspond to the mapfile output by oneself and cannot run properly.

I need to provide some technical support to help me solve this problem.