TMS320F280041C: Hex2000 utility binary output file and options selection

Alex,

Do you have page 0 and page 1 in your linker cmd file? If yes, maybe the fill value went in to the hex output of page 1.

Please check.

Thanks and regards,
Vamsi

Hi Vamsi,

Below is *.cmd file. Can you tell me what to do?

MEMORY
{
PAGE 0 :
/* BEGIN is used for the "boot to Flash" bootloader mode */
// Alex BEGIN : origin = 0x080000, length = 0x000002
BEGIN : origin = 0x085000, length = 0x000002
RESET : origin = 0x3FFFC0, length = 0x000002

patch_EST_Angle_run_patchable_address : origin = 0x009000, length = 0x00000e
patch_EST_Dir_run_patchable_address : origin = 0x00900e, length = 0x00000e
patch_EST_Eab_run_patchable_address : origin = 0x00901c, length = 0x00000e
patch_EST_Flux_ab_estFluxDot_patchable_address : origin = 0x00902a, length = 0x00000e
patch_EST_Flux_dq_run_patchable_address : origin = 0x009038, length = 0x00000e
patch_EST_Flux_run_patchable_address : origin = 0x009046, length = 0x00000e
patch_EST_Freq_run_patchable_address : origin = 0x009054, length = 0x00000e
patch_EST_Iab_run_patchable_address : origin = 0x009062, length = 0x00000e
patch_EST_Idq_run_patchable_address : origin = 0x009070, length = 0x00000e
patch_EST_Ls_run_patchable_address : origin = 0x00907e, length = 0x00000e
patch_EST_OneOverDcBus_run_patchable_address : origin = 0x00908c, length = 0x00000e
patch_EST_Rr_run_patchable_address : origin = 0x00909a, length = 0x00000e
patch_EST_RsOnLine_run_patchable_address : origin = 0x0090a8, length = 0x00000e
patch_EST_Rs_run_patchable_address : origin = 0x0090b6, length = 0x00000e
patch_EST_Vab_run_patchable_address : origin = 0x0090c4, length = 0x00000e
patch_EST_Vdq_run_patchable_address : origin = 0x0090d2, length = 0x00000e
patch_EST_runEst_patchable_address : origin = 0x0090e0, length = 0x00000e

// Alex RAMGS1_3 : origin = 0x00E000, length = 0x006000
RAMGS1_3 : origin = 0x00E000, length = 0x005FE0
RAMGS_BOOT : origin = 0x013FF0, length = 0x000004

RAMLS4_7 : origin = 0x00A000, length = 0x002000

// Alex FLASHB0_SA : origin = 0x080002, length = 0x00FFFE /* on-chip Flash */
FLASHB0_SA : origin = 0x085002, length = 0x00AFFE /* on-chip Flash */
FLASHB1_SA : origin = 0x090000, length = 0x010000 /* on-chip Flash */

PAGE 1 :
BOOT_RSVD : origin = 0x000002, length = 0x0000F3 /* Part of M0, BOOT rom will use this for stack */
RAMM0 : origin = 0x0000F5, length = 0x00030B
RAMM1 : origin = 0x000400, length = 0x000400

/* CLA1 : origin = 0x001400, length = 0x000080 */ /* Defined in header cmd file */

RAMGS0_A : origin = 0x00C000, length = 0x002000

RAMLS0_1 : origin = 0x008000, length = 0x001000 /* Can't be used, reserved for FAST object */
RAMLS2_3 : origin = 0x009100, length = 0x000F00 /* */

CLA1MSGRAMLOW : origin = 0x001480, length = 0x000080
CLA1MSGRAMHIGH : origin = 0x001500, length = 0x000080

}

SECTIONS
{
.TI.ramfunc : LOAD = FLASHB0_SA,
RUN = RAMLS4_7,
LOAD_START(_RamfuncsLoadStart),
LOAD_SIZE(_RamfuncsLoadSize),
LOAD_END(_RamfuncsLoadEnd),
RUN_START(_RamfuncsRunStart),
RUN_SIZE(_RamfuncsRunSize),
RUN_END(_RamfuncsRunEnd),
PAGE = 0, ALIGN(4)

codestart : > BEGIN, PAGE = 0, ALIGN(4)
.text : > FLASHB0_SA, PAGE = 0, ALIGN(4)
.cinit : > FLASHB0_SA, PAGE = 0, ALIGN(4)
.pinit : > FLASHB0_SA, PAGE = 0, ALIGN(4)
.switch : > FLASHB0_SA, PAGE = 0, ALIGN(4)
.econst : > FLASHB0_SA, PAGE = 0, ALIGN(4)

.reset : > RESET, PAGE = 0, TYPE = DSECT
.cio : > RAMLS4_7, PAGE = 0
.stack : > RAMM0, PAGE = 1
.ebss : > RAMGS0_A, PAGE = 1
.esysmem : > RAMGS0_A, PAGE = 1

/* Cla1RegsFile : > CLA1, PAGE = 1 */ /* Defined in header .cmd file*/

.bss_cla : > RAMLS2_3, PAGE = 1

Cla1Prog : > FLASHB0_SA,
RUN = RAMLS4_7,
LOAD_START(_Cla1ProgLoadStart),
RUN_START(_Cla1ProgRunStart),
LOAD_SIZE(_Cla1ProgLoadSize),
PAGE = 0, ALIGN(4)

Cla1Prog2 : > FLASHB0_SA,
RUN = RAMLS4_7,
LOAD_START(_Cla1Prog2LoadStart),
RUN_START(_Cla1Prog2RunStart),
LOAD_SIZE(_Cla1Prog2LoadSize),
PAGE = 0, ALIGN(4)

Cla1ToCpuMsgRAM : > CLA1MSGRAMLOW, PAGE = 1
CpuToCla1MsgRAM : > CLA1MSGRAMHIGH, PAGE = 1

.const_cla : > FLASHB0_SA,
RUN = RAMLS4_7,
RUN_START(_Cla1ConstRunStart),
LOAD_START(_Cla1ConstLoadStart),
LOAD_SIZE(_Cla1ConstLoadSize),
PAGE = 0

.scratchpad : > RAMLS2_3, PAGE = 1

boot_data : > RAMGS_BOOT

patch_EST_Angle_run_patchable_section : > patch_EST_Angle_run_patchable_address, PAGE = 0
patch_EST_Dir_run_patchable_section : > patch_EST_Dir_run_patchable_address, PAGE = 0
patch_EST_Eab_run_patchable_section : > patch_EST_Eab_run_patchable_address, PAGE = 0
patch_EST_Flux_ab_estFluxDot_patchable_section : > patch_EST_Flux_ab_estFluxDot_patchable_address, PAGE = 0
patch_EST_Flux_dq_run_patchable_section : > patch_EST_Flux_dq_run_patchable_address, PAGE = 0
patch_EST_Flux_run_patchable_section : > patch_EST_Flux_run_patchable_address, PAGE = 0
patch_EST_Freq_run_patchable_section : > patch_EST_Freq_run_patchable_address, PAGE = 0
patch_EST_Iab_run_patchable_section : > patch_EST_Iab_run_patchable_address, PAGE = 0
patch_EST_Idq_run_patchable_section : > patch_EST_Idq_run_patchable_address, PAGE = 0
patch_EST_Ls_run_patchable_section : > patch_EST_Ls_run_patchable_address, PAGE = 0
patch_EST_OneOverDcBus_run_patchable_section : > patch_EST_OneOverDcBus_run_patchable_address, PAGE = 0
patch_EST_Rr_run_patchable_section : > patch_EST_Rr_run_patchable_address, PAGE = 0
patch_EST_RsOnLine_run_patchable_section : > patch_EST_RsOnLine_run_patchable_address, PAGE = 0
patch_EST_Rs_run_patchable_section : > patch_EST_Rs_run_patchable_address, PAGE = 0
patch_EST_Vab_run_patchable_section : > patch_EST_Vab_run_patchable_address, PAGE = 0
patch_EST_Vdq_run_patchable_section : > patch_EST_Vdq_run_patchable_address, PAGE = 0
patch_EST_runEst_patchable_section : > patch_EST_runEst_patchable_address, PAGE = 0
}

SECTIONS
{
sysctrl_data : > RAMM1 | RAMLS2_3, PAGE = 1
ctrl_data : > RAMM1 | RAMLS2_3, PAGE = 1
est_data : > RAMGS0_A, PAGE = 1

}

SECTIONS
{
datalog_data : > RAMGS0_A, PAGE = 1
graph_data : > RAMGS0_A, PAGE = 1
}

Alex

Alex,

I will review and get back to you next week (Jan 4th or 5th).

Thanks and regards,
Vamsi

Alex,

I didn't see any flash space in page 1 of your linker cmd file; hence, separate page 1 hex file may not be the issue.

If I understand correctly, you want to fill 0xFFFF for any unused flash locations - is that correct?

If Yes,

(i) You can fill that in your linker command file itself.  Below is the example.  You can do it for all the flash address ranges you defined in the linker cmd file.

    FLASH : origin = 0x090000, length = 0x002000, fill=0xFFFF

    More information can be found in section 8.5.4 The MEMORY Directive in https://www.ti.com/lit/pdf/spru513

(ii) There is another method.  Once you program the flash using CCS, you can download a binary file from CCS memory window.  Click on green button in the memory window (highlighted below in yellow) and export the memory contents in to a binary file; and later you can use that file to program the Flash again.

If you want to use the hex tool method to fill the unused space, then I need to route you to our compiler team.  Let me know.

Thanks and regards,
Vamsi

Alex,

When I saw your configuration to fill 0xFF (in images he added), I thought the intention is to fill the unused locations.  

If you want to know whether or not they are erased un-used locations, you can use the "fill" option in the linker command file to fill with something other than 0xFFFF.  After filling, if the hex output shows the fill configured value, it will be easy for you to match with that of the CCS memory window content.

One more thing: I noticed the entry point in your linker cmd file is not one of those that are listed in the TRM (see below).  Please check.

Thanks and regards,
Vamsi

The entry point from boot ROM is 0x00080000 to my custom bootloader which jumps to main application located at 0x00085000. It does work and it is NOT a problem. I do use saving memory to a binary file for now but I thought that the utility would do the job without this extra step.

I think you have misunderstanding what the problem with HEX2000 utility is. Filling option has nothing to do with the problem. I don't care if unused locations are filled or not as long as a motor is spinning. The file that HEX2000 utility creates does not spin a motor and it is different then the one in the micro's memory. At address 0x85002 memory has 0xFFFF and binary file has 0x761B and so on. If entry point address is causing this problem then I will change it. Just tell me exactly what and where to change. 

Alex

Alex,

Sure, if that is the entry location from your custom bootloader to your application, then it is fine.  The entry-point note has nothing to do with the binary discussion; I mentioned it as I noticed it.  

Regarding the binary output:  Binary file contains only one section and gets loaded at the address provided.  Hence, if you don't fill the unused locations with some value, the binary data of second section onwards will be loaded at wrong address.  I thought you are aware of this and hence you filled 0xFs.  Hope you understand now on why I gave that suggestion.

Thanks and regards,
Vamsi

I spoke to our compiler team now.  

They suggested to use tiobj2bin instead of hex2000 utility to create a binary file: See http://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_project-management.html?highlight=tiobj2bin#pre-and-post-build-steps 

I assigned this post to our compiler team - they can help you if you have further questions.

Thanks and regards,

Vamsi

http://software-dl.ti.com/ccs/esd/documents/sdto_cgt_an_introduction_to_binary_files.html 

The project name is is07_speed_control_sensored. I want the same name for the binary file. What exact text do I put in the post-build box?

Alex

Alex,

Hope your question on the 0xFs is now closed.

Our compiler team will help you further.

Thanks and regards,

Vamsi

Aleksandr Labunskiy said:

The project name is is07_speed_control_sensored. I want the same name for the binary file. What exact text do I put in the post-build box?

The recommended text is ...

"${CCS_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/ofd2000" "${CG_TOOL_ROOT}/bin/hex2000" "${CCS_INSTALL_ROOT}/utils/tiobj3bin/mkhex4bin"

This is an invocation of a Windows batch file.  The first part is the name of the batch file.  The rest are the arguments to the batch file.  The second argument names the binary file.  Right now, you end up with name_of_project.bin.  Is that good enough?

Thanks and regards,

-George

Hi George,

This is the result of the command:

“C:/ti/ccs920/ccs/utils/tiobj2bin/tiobj2bin� “is07_speed_control_sensored.out� “is07_speed_control_sensored.bin� “C:/ti/ccs920/ccs/tools/compiler/ti-cgt-c2000_20.2.4.LTS/bin/ofd2000� “C:/ti/ccs920/ccs/tools/compiler/ti-cgt-c2000_20.2.4.LTS/bin/hex2000� “C:/ti/ccs920/ccs/utils/tiobj2bin/mkhex4bin�
makefile:256: recipe for target 'post-build' failed
process_begin: CreateProcess(NULL, “C:/ti/ccs920/ccs/utils/tiobj2bin/tiobj2bin� “is07_speed_control_sensored.out� “is07_speed_control_sensored.bin� “C:/ti/ccs920/ccs/tools/compiler/ti-cgt-c2000_20.2.4.LTS/bin/ofd2000� “C:/ti/ccs920/ccs/tools/compiler/ti-cgt-c2000_20.2.4.LTS/bin/hex2000� “C:/ti/ccs920/ccs/utils/tiobj2bin/mkhex4bin�, ...) failed.

gmake[2]: [post-build] Error 2 (ignored)

Any ideas?

Alex

Something went wrong when you pasted in the post build command and the system response.  I can't see it clearly.  Please try it again.  In the Console view in CCS, use the Copy Build Log icon to save everything to a text file. Be sure to use the file extension .txt. Then attach that text file to your next post.

Thanks and regards,

-George

Hi George,

I tried. The result is the same. This website does not let me attach the file.

Do you have a windows10 computer? Does it work on that computer? Do I need to remove quotation marks?

Alex

For details on attaching a file to a forum post, please see this FAQ.

The quotation characters might be the problem.  Please see if this forum thread is helpful.

Thanks and regards,

-George

Aleksandr Labunskiy said:

I deleted all quotation marks before I made my last post and it did work.

The command George pasted contained smart-quotes, as does the command in the CCS User's Guide in 6.1.3.4. Pre and Post Build Steps, rather than the "standard" quote ASCII code 34 (decimal).

I had previously reported a similar issue in CCS/TM4C129ENCPDT: Smart quotes used in some GEL examples, for which https://sir.ext.ti.com/jira/browse/EXT_EP-10170 was raised to correct the use of quotes in the CCS User's Guide documentation.

Thank you to Chester for explaining the problem.  

Chester Gillon said:

The command George pasted contained smart-quotes

That has been fixed.  

Chester Gillon said:

as does the command in the CCS User's Guide

That will be fixed soon.

Thanks and regards,

-George