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.

CCS/TMS320F28034: Some questions about bin document created by ccs

Part Number: TMS320F28034


Tool/software: Code Composer Studio

Dear TI engineers,

I have a question about bin document created by ccs7.3. 

I add "${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" & "${CG_TOOL_HEX}" -i "${BuildArtifactFileName}" -o "${BuildArtifactFileBaseName}.hex" -order MS -romwidth 32" in Post-build steps. And add CMD path in Linker command file shown in picture below.

But, there are difference between bin and hex shown in below.I mean the data are not same.Please see 100.7z.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/81/8524.100.7z

When I do not add cmd path, bin and hex seems same. Please see 101.7z.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/81/6866.101.7z

In this way, I could not debug project by ccs. In other words, I could not connect chip shown in picture below. And console shown like these "C28xx: Loader: One or more sections of your program falls into a memory region that is not writable. These regions will not actually be written to the target. Check your linker configuration and/or memory map."

Here are the cmd document. Please see DM28035.7z.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/81/DM28035.7z

So, how should I solve this problem? Looking forward for your reply.

  • The .bin file in the first attachment starts with many bytes filled with 0.  I presume avoiding this block of 0 will fix the problem.  I don't know what causes it.  To investigate this problem, please attach the file Heric_bootload.out (the .out file created by the linker) to your next post.  Just like you did with your other attachments, put it in a .7z file.

    Thanks and regards,

    -George  

  • Hi,

    George,thanks for your reply. Here are the out document. Heric_bootload1 is the large one which fill with 0 and Heric_bootload2 is the right one(I think).

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/81/out.7z

    By the way, the large bin document is not only with 0 in front of it. Also in the middle of bin. I try to build a new project and put the .c , .h, cmd and lib document into it. But it also produce large bin.

    Looking forward for your reply.

  • When tiobj2bin.bat creates the binary file from Heric_bootload1.out, this diagnostic is seen ...

    warning: section Heric_bootload1.out(DataBuff) at 011400h falls in unconfigured
       memory (skipped)

    This is due to a bug already filed against the hex utility hex2000.  The ID is EXT_EP-7767.  You are welcome to follow it at that link.  I added your test case to that entry.  Note customer specific details like a test case are not revealed in the public view of a bug.

    I think the problem starts with this line in the linker command file DM28035.cmd ...

        DataBuff           : > RAML2       PAGE = 1 , fill = 0x00

    Remove the fill = 0x00.  Instead, change your system start code to zero out this range of memory.  That fill changes DataBuff from an uninitialized section to an initialized section.  That's probably not what you want.  I cannot test whether this change will fix the problem.  But I'm confident it will.

    Thanks and regards,

    -George

  • Hi,

    George, thanks for your suggestion. But I still have some doubts.

    1. When I delete "fill = 0x00", there is no warning as "warning: section Heric_bootload1.out(DataBuff) at 011400h falls in unconfigured

       memory (skipped)". I do not know what happened.
    2. The bug you said I do not know how to fix it when I enter the web provided by you. Could you give me some details?
    3. I do not know clearly for "change your system start code to zero out this range of memory".
    Here are the new out document produced by deleting the fill = 0x00.
    So grateful for your reply.https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/81/Heric_5F00_bootload.7z
  • When fill = 0x00 is present, that makes DataBuff an initialized section.  Initialized sections are processed by the hex utility.  In the specific case of the initialized section DataBuff, the hex utility makes an error while processing this section.  This error is what causes the diagnostic about unconfigured memory to appear.  This same error also causes the large block of zero at the beginning of the .bin file.  When fill = 0x00 is not present, DataBuff is an uninitialized section.  Uninitialized sections are ignored by the hex utility.

    I presume the fill = 0x00 is needed for correct execution of the program.  If it is removed, then the memory corresponding to that section needs to be filled with zero some other way.  I suggest you write code, which executes during system startup, to zero out that memory. I presume you know the variable, or variables, reside in the DataBuff section.  Those are the ones which need to be assigned the value 0 before the main execution of the program begins.

    Thanks and regards,

    -George

  • Hi,

    George, thanks for your comment. This question seemed to be solved.

    But I have another question for other project. Here are the warning in this picture. Same command are used in Post-build steps.

    Here are the .out and cmd document. I do not know the reason why these warning appeared.https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/81/002.7z

    Looking forward for your reply.

  • Hi,

    George, I should say sorry for you. I used different command in Post-build steps. 

    When I correct it, It seems no warning. 

    So appreciative for your help.