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.

TMS320F28384S: CM - Issue with Intel HEX format generation with ArmHex.

Part Number: TMS320F28384S

Hello,
which are the correct command line options to make ArmHex generate a single .hex file in intel format, from CM .out file?

I tried to use --romwidth=32 and --intel.
In this way I have obtaind a single .hex file, but there is something strange inside.

In particular I have allocated a CRC16 constant variable at address 0x200008:

CMBANK0_RESETISR : origin = 0x00200000, length = 0x00000008 /* Boot to Flash Entry Point */
CMBANK0_CRC : origin = 0x00200008, length = 0x00000004 /* CRC */
CMBANK0_SECTOR0 : origin = 0x0020000C, length = 0x00003FF4

.crc : > CMBANK0_CRC

#pragma DATA_SECTION(crc, ".crc")
#pragma RETAIN(crc)
const uint16_t crc = 0x1234;

Looking at the map file everything is ok:

.crc 0 00200008 00000002
00200008 00000002 main_bootl.obj (.crc:retain)

00200008 crc

But if I look inside the .hex file, the data in the "crc" record seems to be in big-endian format.

:0400080000001234AE

My surprise comes because we do the same thing also on STM32 projects, developed with STM32CubeIDE and GCC toolchain.
In this case the data in the .hex file records are in little-endian:

:04820000FAA10000DF

Is there something that I am doing wrong, or simply ArmHex generates a .hex file with endianess opposed respect the one generated with the GCC tool?
In this last case it would be very annoying, because we use a custom tool to read the hex files for crc verification and other conversion operations.

Thank you,
Carlo