CCS/RM44L520: .hex file endianness

Jan Menzel

Part Number: RM44L520
Other Parts Discussed in Thread: SEGGER, UNIFLASH

Tool/software: Code Composer Studio

Hi All!

I'm developing an application using an RM44L520 (little endian) and CCS 9.0.1.00004. As debugging hardware I'm using a Segger J-Link. Now I've reached a first milestone and wont to share the results. Therefore I enabled the ARM Hex Utility with the options --romwidth=32 --intel. The resulting hex-file starts with the following line:

:20000000EA007A75EAFFFFFEEA00125BEAFFFFFEEA007C0DEA007DB2E51FF1B0E51FF1B00E

Decoded the reset vector is 0xea 0x00 0x7a 0x75. If I load this file into a hex-editor (HxD) it shows the correct 32-bit word 0xea007a75. However, when I import this file into Seggers external flash utility, they seem to interpret the data as byte stream and convert it into little endian 32bit words. Then the reset vector has swapped bytes 0x757a00ea. Obviously this code does not run once flashed.

If I readback the flash that I programmed while debugging, the byte order is correct...

Can anyone tell me where the problem is and how I can solve it? Thank You

Jan

over 6 years ago

0 JohnS over 6 years ago

TI__Guru**** 162305 points

Jan,

This seems like something that you may need to contact Segger about. I am not familiar with their flash programming utility.

1) Does UniFlash program the .out correctly?

2) Does UniFlash program the .hex correctly?

If the answer to both 1 and 2 is yes then you will need to contact Segger.

If the answer to 1 is yes but 2 is no then we will need to take a look at how the .hex is being generated.

You can get UniFlash from dev.ti.com/uniflash

Regards,

John

0 Jan Menzel over 6 years ago in reply to JohnS

Prodigy 100 points

Hi John!

Many thanks for your quick response. I've tried Uniflash and it surprised me, that it can be used with Seggers J-Link. I can successfully program the .out file and get the same errors using the .hex file. The .out is programmed with correct byte order and the .hex has swapped byte order. So its the same problem as with Seggers J-Flash. The .hex file, armhex generates, has the wrong byte order.

Jan