F28069: hex2000, memwidth and HEX parser

How do you generate Intel hex? What options?

Hello Vishwanatha!

Have you seen this manual already (page 43)? 3808.flasher_c2000.pdf.

Regards,

Igor

Hello Igor, Anton,
I use this command to generate hex files:

mcu_image.out
--intel
--image
--order=MS
--romwidth=16
--memwidth=16
--fill=0xFFFF
ROMS
{
    APP_FLASH : origin = 0x3DC000, length = 0x14000, files = { mcu_image_i.hex }
}

Hello  Vishwanatha!

1I think you should just try to boot.

2 And let me ask you what do you justify that use 8-bit addressing is a better solution than the use of 16-bit addressing in your case. At what is the feature of your case?

Regards,

Igor

Hello Igor,
1.  I'll try to boot and post the results.
2.  I want to merge two hex files (of different controllers). To do this, I use the software "srecord".
    When I provide the f28069 hex as input to this, it throws exception as it expects byte addressable data
    (while c2000 hex are word addressable). This is the whole reason I am trying to make it byte addressable.
    
--
Vishwanatha

Vishwanatha Manevarthe said:

2.  I want to merge two hex files (of different controllers). To do this, I use the software "srecord".

Would it be better to embbed another binary with your f28069 software during link stage and then produce one hex file from it?

Hi,

That will help. But I do not know how to accomplish this in CCS4

Vishwanatha

If your binary has different memory sections, it might be complicated.

BTW, just trying to play with your Intel-hex example and mine TI-tagged hex:

hex2000 -memwidth 16 -romwidth 16 -t test.out

Will produce Texas_Instruments_Tagged16 file, but it is not compatible with "srecord" program. I've fixed it:

sed -i 's/ COFFTOTI$//g; s, ,,g' test.t00

To remove trailing "COFFTOTI" and spaces at the end of each line.

Then, I've update header in two steps:

1. Set program ID header length to 13 (0xC): in the string "K0000COFFTOTI" to "K000DCOFFTOTI".

2. Run srec_info to get proper checksum for the file in the first lne:

$ srec_info test.t00 -Texas_Instruments_Tagged16
Format: Texas Instruments SDSMAC (320)
Header: "COFFTOTI"
srec_info: test.t00: 1: checksum mismatch (calculated F1A3, file has F1B7)

K000DCOFFTOTI98000B0000B1021B2042B3063B4084B50A5B60C6B70E7B81087F1B7F
changed to
K000DCOFFTOTI98000B0000B1021B2042B3063B4084B50A5B60C6B70E7B81087F1A3F

$ srec_cat intel.hex -Intel -address-length=2 test.t00 -Texas_Instruments_Tagged16 1>output.hex
$ srec_info intel.hex -Intel
Format: Intel Hexadecimal (MCS-86)
Data:   3F0000 - 3F005F

$ srec_info test.t00 -Texas_Instruments_Tagged16
Format: Texas Instruments SDSMAC (320)
Header: "COFFTOTI"
srec_info: test.t00: 1305: warning: data records not in strictly ascending
    order (expected >= 0x1D8FC, got 0xFFEC)
Data:   00FFEC - 00FFEF
        010000 - 012BBD
        016000 - 01609B
        018000 - 018097
        018100 - 018A03
        018B00 - 01D8FB

And the result:

$ srec_info output.hex
Format: Motorola S-Record
Header: "COFFTOTI"
srec_info: output.hex: 1064: warning: no execution start address record
Data:   00FFEC - 00FFEF
        010000 - 012BBD
        016000 - 01609B
        018000 - 018097
        018100 - 018A03
        018B00 - 01D8FB
        3F0000 - 3F005F

Hi,
Thanks for suggestion.
I tried it but did not succeed. I get this message:

D:\usb\HexEdit>srec_cat.exe test.out -Texas_Instruments_Tagged16 intel_file.hex -intel -o mcu.hex -intel
srec_cat: test.out: 2866: warning: data records not in strictly ascending order (expected >= 0x2A28E, got 0xA290)
srec_cat: test.out: 2874: contradictory 0x00018000 value (previous = 0xFF, this one = 0xC5)

test.out is quite huge

Usually, ".out" extension is for COFF files. What does srec_info.exe test.out -Texas_Instruments_Tagged16 says?

>srec_info test.out -Texas_Instruments_Tagged16
Format: Texas Instruments SDSMAC (320)
Header: "COFFTOTI"
srec_info: test.out: 1: checksum mismatch (calculated F0AB, file has F0BF)

Vishwanatha Manevarthe said:

srec_info: test.out: 1: checksum mismatch (calculated F0AB, file has F0BF)

You have to fix checksum in your test.out.

Hi,

as I mentioned in my earlier post, I followed exactly what you mentioned.

I changed the checksum, changed the header length etc. in spite of all the changes, I got the error.

--

Vishwanatha

I changed the checksum, changed the header length etc

As last you've quotted, you still have incorrect checksum. Just repeat a checksum fix step.

srec_cat: test.out: 2874: contradictory 0x00018000 value (previous = 0xFF, this one = 0xC5)

This messages says that you have different bytes in the different sources at the same address 0x18000. You may use "-MULTiple" option to make this error to be a warning.  Probably, first input fills a region with 0xFF values and second input tries to overwrite them with meaningfull data. Pay attention that "-multiple" option may lead to unpredictable result.

Hi,
It is my mistake. I pasted the message that I got before running the commnand.
Here is the actual message:

>srec_info.exe test.out -Texas_Instruments_Tagged16
Format: Texas Instruments SDSMAC (320)
Header: "COFFTOTI"
srec_info: test.out: 2866: warning: data records not in strictly ascending order (expected >= 0x2A28E, got 0xA290)
Data:    00A290 - 00A33B
             00FF00 - 00FFEB
             00FFF0 - 00FFFF
             018000 - 02A28D

>srec_info.exe intel_file.hex -intel
Format: Intel Hexadecimal (MCS-86)
Data:   3F0000 - 3F6FFF

So, you have in test.out at least two records with bytes at 0x18000 address. First occurence were before line 2874.

So, we have:

Were is region 00A298-00A33B in the test.out file?

It should be great to take a look on a MAP file.

Hi,
looking at the test.out, I found that the address 0xC000 repeats in lines 1 and 2874 and the data values are exactly FF and C5.
I am not sure why is this repeating.
[original .out file that I use to load to the controller works perfectly well and also the intel format also works].
Address 0x18000 can not be in the hex file at all as this address is not at all present in the memory map of the controller
(F28069 has user flash from 0x3D8000 to 0x3F7FFF).
This is a mystery for me and am still struggling to merge two hex files !!

meanwhile, I tried this but with failure:

>srec_cat.exe test_image.out -Texas_Instruments_Tagged16 -o test_image_i.out -intel
srec_cat: test_image.out: 2845: warning: data records not in strictly ascending order (expected >= 0x2A062, got 0xA064)
srec_cat: test_image.out: 2853: contradictory 0x00018000 value (previous = 0xFF, this one = 0xC5)

Hi,

I take a look at srecord/memory.cc and srecord/memory/chunk.cc and haven't goot news for you. SRecord is not able to work with word-addressable records.

For exampe, we have two records:

S323003E800000080004000200018000003E40000055C000003E400000000000003F4000FF
S323003E800FAA004000003F40000000FE121E46A044A8428A56764084CF964D5200EC0357

Then, srec_cat will say:

srec_cat: test.srec: 2: contradictory 0x003E800F value (previous = 0x55, this one = 0xAA)

You have two choices:

• Ask SRecord guys to add support for word-addressable records
• Embedd your Intel binary to the TMS COFF.

>srec_info.exe intel_file.hex -intel
Format: Intel Hexadecimal (MCS-86)
Data:   3F0000 - 3F6FFF

What is the target of intel_file.hex was? Is it designed for TMS too or is is just a binary blob? 0x3F_0000 is a FLASHB address. So it is a word-addressable. You can adjust your linker script to include it as a binary blob:

SECTIONS
{
    flash_blob: > FLASHB, PAGE = 1
}

Then create C-file with an array of you blob:

#pragma DATA_SECTION(my_blob, "flash_blob)";
const int my_blob[] = {
   0x00FF, 0xFFFF 0xFF1C, 0x6A00, 0x001C, 0x6A00, 0x001C, 0x6A00, 0x001C, 0x6A00, 0x001C, 0x6A00, 0x001C, 0x6A00, 0x001C, 0x6A00, 0x003A,
   …
}

Then you should have your data @ 0x3F_0000.