TMS320F280025C: post build to generate .bin file, the size is too big

John Liu33

Part Number: TMS320F280025C
Other Parts Discussed in Thread: TMS320F280049C, C2000WARE

Part number TMS320F280025C

I have now changed the part from TMS320F280049C to TMS320F280025C, but the resulting *.bin file size is problematic. The *.bin file size for the TMS320F280049C is 69KB, but I used the same process and the new *.bin file size produced using su for the TMS320F280025C is 1040KB.
I have changed the C2000ware tools from C2000ware_3_04_00_00 to 2000ware_4_01_00_00, all other tools are unchanged.

The new *.bin file has a lot of 00s in it. I searched and got the follow link, but that didn't solve my problem. So please help.

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1068860/tms320f28335-ccs-generates-binary-output-in-too-large-size?tisearch=e2e-sitesearch&keymatch=.bin%2525252525252520file#

post build, I use: "${CCE_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/ofd2000" "${CG_TOOL_ROOT}/bin/hex2000" "${CCE_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin"

over 3 years ago

0 Santosh Jha over 3 years ago

TI__Guru 50611 points

Hi John,

Is there similar difference in .out file also out files are about same size?

Thanks & Regards,

Santosh

0 John Liu33 over 3 years ago in reply to Santosh Jha

Prodigy 70 points

Hi Santosh,

Yes, the out file’s size almost same. Follow are the information:

280025
bin file size is 1040KB; from address 0 ~ 0x000F168F are all 00, address 0x000F1690 ~ 0x00103F6C are data,which 75996B, around 74KB
out file size is 364KB
Hex file size is 71KB

280049's bin file size is 68KB; data from address 0x0 ~ 0x00010F4F has 69455B, around 67KB;
out file size is 358KB
Hex file size is 61KB

Thank

0 Santosh Jha over 3 years ago in reply to John Liu33

TI__Guru 50611 points

John,

I am contacting subject matter expert to look into this. Please expect response in a day.

Thanks & Regards,

Santosh

0 George Mock over 3 years ago in reply to Santosh Jha

TI__Guru**** 250440 points

Please attach the map file from the TMS320F280025C build. So the forum will accept it, add the file extension .txt to it.

Thanks and regards,

-George

0 John Liu33 over 3 years ago in reply to George Mock

Prodigy 70 points

Hi George,

Thanks for take look my issue. Attached is the map file with .txt for it.

QifengDS3_280025_20220629_Rev1_V5_T34R22.txt

0 JohnS over 3 years ago in reply to John Liu33

TI__Guru**** 162505 points

John,

George is out today but will reply when he returns tomorrow.

Regards,

John

0 George Mock over 3 years ago in reply to JohnS

TI__Guru**** 250440 points

For general background, please see the article An Introduction to Binary Files. Focus on the discussion about how holes occur, and what you can do to avoid them.

In your case, there is a gap of 0x6a4 words between the end of the section .cinit and the start of the section .text.2. It is likely you can avoid this hole by making changes to the linker command file. For general background on that file, please see the article Linker Command File Primer. One change to consider ... Collapse the three memory ranges for FLASH into one memory range.

Please let me know if these suggestions resolve the problem.

Thanks and regards,

-George

0 John Liu33 over 3 years ago in reply to George Mock

Prodigy 70 points

Hi George,

Thanks for your reply. The main issue is not "a gap of 0x6a4 words between the end of the section .cinit and the start of the section .text.2.". The main issue is 965KB's hole from address 0x0 ~ 0x000F168F, all data of these address are 00. Attached is the file. Please help me to let me know how these hole come from. If this issue is fix, a few hole is not big problem.

The bin file has follow address/data:

address 0 ~ 0x000F168F with 00, which is around 965KB ----Where did these 00s come from?

address 0x000F1690 ~ 0x00103F6B real data, 74KB

Thanks

John

0 George Mock over 3 years ago in reply to John Liu33

TI__Guru**** 250440 points

John Liu33 said:
The main issue is 965KB's hole from address 0x0 ~ 0x000F168F,

I don't understand how that happened.

John Liu33 said:
Attached is the file.

I don't see any attachment. Moreover, it would not help much if I had the binary file. Instead, please submit the .out file that is created by the linker. Please zip it up, then attach that zip file to your next post.

Thanks and regards,

-George

0 John Liu33 over 3 years ago in reply to John Liu33

Prodigy 70 points

Hi George,

Is it possible the 280025 problem? We used almost same cmd file as 280049, and 280049 does not have this issue.

Thanks

John

0 John Liu33 over 3 years ago in reply to George Mock

Prodigy 70 points

Hi George,

Sorry I can not sent my out file from here.

Thanks

John

0 John Liu33 over 3 years ago in reply to John Liu33

Prodigy 70 points

DS3_testcase.zipHi George,

I attached the out file as you request.

Thanks

John

0 George Mock over 3 years ago in reply to John Liu33

TI__Guru**** 250440 points

Thank you for submitting the .out file created by the linker.

It appears you have discovered a new bug in tiobj2bin. The analysis is not complete. But I'm mostly sure about that much. I'll get back to you.

Thanks and regards,

-George

0 John Liu33 over 3 years ago in reply to George Mock

Prodigy 70 points

Hi George,

Thanks for the message, is there an update today?

Thanks

John

0 George Mock over 3 years ago in reply to John Liu33

TI__Guru**** 250440 points

I apologize for this taking so long. I expect to get back to you tomorrow.

Thanks and regards,

-George

+1 George Mock over 3 years ago in reply to George Mock

TI__Guru**** 250440 points

I can confirm there is a bug in tiobj2bin. If the system is C28x, built for EABI, and at least one section has a different load and run address, then it is possible the load address for such a section may be computed incorrectly, and this eventually leads to the binary file being wrong. In your particular case, the binary file starts with a large number of bytes with value 0. That is but one way the problem may present itself.

The rest of this post describes a workaround. It is inconvenient, but unavoidable.

Use the hex utility hex2000 to create the binary file. To do that, image mode must be used, which means a ROMS directive must be supplied in a command file. This ROMS directive tells hex2000 the range of memory from the executable .out file (created by the linker) to convert to binary. This range of memory is where all the initialized sections (like .text and .const) reside. All the uninitialized sections (like .stack and .bss) are ignored.

Expressed in pseudo code, this is what the ROMS directive looks like ...

ROMS {
all_mem: o = lowest initialized address, l = highest initialized address - lowest initialized address
}

There are two ways to go about getting those initialized addresses.

The first way I describe is to get those addresses from the MEMORY directive of the linker command file. The advantage of this method is that it is more robust. As your build changes, you do not need to modify the ROMS directive. The disadvantage of this method is that the binary file will be longer than strictly necessary. It will end with some amount of bytes of zero that are not needed.

The second way I describe is to get those addresses from the map file generated by the linker. The advantage of this method is that the resulting binary file is exactly as long as needed, and no longer. The disadvantage is that you need to change the ROMS directive any time your build changes.

The first way ...

I don't have your linker command file, but I do have these lines from your linker map file, and they have the same information.

  BEGIN                 00083020   00000002  00000002  00000000  RWIX
  FLASH_BANK0_SEC1_2_3_ 00083040   00003fc0  00003911  000006af  RWIX
  FLASH_BANK0_SEC7_8_9_ 00087000   00005000  00005000  00000000  RWIX
  FLASH_BANK0_SEC11_12_ 0008c000   00004000  0000048e  00003b72  RWIX

These are all the memory ranges that contain initialized sections. Here are the contents of the first three columns.

Name of the memory range
Start address
Length

Based on that you compute:

lowest initialized address = 0x00083020
highest initialized address = 0x0008c000+0x00004000 = 0x00090000
For the length, subtract those two: 0x00090000 - 0x00083020 = 0x0000cfe0

These addresses are all in terms of 16-bit words. On C28x, each address corresponds to one 16-bit word, and not one 8-bit byte. In binary mode of hex2000, however, addresses are counted in terms of 8-bit bytes. Thus, we have to multiply these values by 2. Put it all together, and it forms this ROMS directive.

ROMS {
   all_mem: o = 0x106040, l = 0x19fc0
}

To create the binary file issue a command similar to ...

hex2000 -q -b -image -o binary_file.bin roms_directive_file.txt final_executable_file.out

The second way ...

Get the addresses of the sections from the map file. Scan through the part of the map file titled SECTION ALLOCATION MAP. Ignore any sections marked UNINITIALIZED, or DSECT, or where the length is 0. In your specific case, here is the one with the lowest address ...

codestart 
*          0    00083020    00000002

The second to last number is the address, and the last number is the length.

Here is the one with the highest address ...

.const     0    0008c000    0000048e

The computations are the same as the first way, but the length of the highest initialized section changes things.

lowest initialized address = 0x00083020
highest initialized address = 0x0008c000+0x0000048e = 0x0008c48e
For the length, subtract those two: 0x0008c48e - 0x00083020 = 0x0000946e

Remember to multiply those values by two for the ROMS directive ...

ROMS {
   all_mem: o = 0x106040, l = 0x128dc
}

The hex2000 command is the same as before.

Thanks and regards,

-George

0 John Liu33 over 3 years ago in reply to George Mock

Prodigy 70 points

Hi George,

Thanks so much for your time to find the issue and give suggestion to work around. But I am newer to TI DSP system. I do not know how to use the ROMS{}, where should I put this ROMS{}? I tried follow steps:

1. generate a txt file: roms_directive_file.txt with follow:
ROMS {
all_mem: o = 0x106040, l = 0x19fc0
}

2. modify Build\post-build steps

from
"${CCE_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/ofd2000" "${CG_TOOL_ROOT}/bin/hex2000" "${CCE_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin"

to "${CCE_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/ofd2000" "${CG_TOOL_ROOT}/bin/hex2000" "${CCE_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin" "roms_directive.txt"

and I got follow message:

Building secondary target: "DS3_testcase.bin"
Invoking: C2000 Hex Utility
"C:/ti/ccs1100/ccs/tools/compiler/ti-cgt-c2000_21.6.0.LTS/bin/hex2000" --memwidth=16 --romwidth=16 --diag_wrap=off --binary -o "DS3_testcase.bin" "DS3_testcase.out"
Translating to Binary format...
"DS3_testcase.out" codestart ==> codestart
"DS3_testcase.out" .TI.ramfunc ==> .TI.ramfunc
"DS3_testcase.out" .text.1 ==> .text.1
"DS3_testcase.out" .cinit ==> .cinit
"DS3_testcase.out" .text.2 ==> .text.2
"DS3_testcase.out" .const ==> .const
Finished building secondary target: "DS3_testcase.bin"

"C:/ti/ccs1100/ccs/utils/tiobj2bin/tiobj2bin" "DS3_testcase.out" "DS3_testcase.bin" "C:/ti/ccs1100/ccs/tools/compiler/ti-cgt-c2000_21.6.0.LTS/bin/ofd2000" "C:/ti/ccs1100/ccs/tools/compiler/ti-cgt-c2000_21.6.0.LTS/bin/hex2000" "C:/ti/ccs1100/ccs/utils/tiobj2bin/mkhex4bin" "roms_directive.txt"
C:/ti/ccs1100/ccs/utils/tiobj2bin/mkhex4bin failure occurred. Giving up.

'roms_directive.txt' is not recognized as an internal or external command,
operable program or batch file.

**** Build Finished ****

so how do I use the ROMS{}, and where I put roms_directive.txt?

Thanks

John

0 John Liu33 over 3 years ago in reply to John Liu33

Prodigy 70 points

Hi George,

After reading the TI documentation over the weekend, I found information about ROMS{} and it works now. Problem solved now.

Thanks a lot!

John

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F280025C: post build to generate .bin file, the size is too big