• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 817 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DSP/BIOS TConf creates .trace and .args as Initialized?

brian gaddis
Prodigy 40 points

Other Parts Discussed in Thread: UNIFLASH

I am using DSP/BIOS 5.41.10.36 and have noticed when TConf creates the .cmd file the sections .trace and .args are classified as "Initialized" and zero filled.  See below for applicable .cmd contents.

.trace: fill = 0x0 {
           _SYS_PUTCBEG = .;
           . += 0x100;
           _SYS_PUTCEND = . - 1;
        } > L03SARAM PAGE 0

.args: fill=0 {
            *(.args)
            . += 0x4;
        } > L03SARAM PAGE 0

Now when I feed the resulting .out file to hex2000.exe to create hex image file,  I get the following warnings because of this fact...

warning: section .\Debug\MyProject.out(.args) at 0a9fch falls in
   ".\Debug\MyProject.out"   ==> .args
   unconfigured memory (skipped)
   ".\Debug\MyProject.out"   ==> .trace
warning: section .\Debug\MyProject.out.out(.trace) at 0b120h falls in
   ".\Debug\MyProject.out.out"   ==> Bank_Header
   unconfigured memory (skipped)

These sections are "skipped" and my hex file a hex file is created.  The created hex files actually exactly what I wanted (an image of the program code).  These warnings actually come back to get me when I move on to another task.

Unrelated to generating this hex file, I am coming up with a method to program the 28335 via JTAG (Spectrum Digital USB XD510) using SDFlash.  Now when I feed SDFlash the .out file I get a fatal error at 0x0A9FC (.args).  I cannot help but assume this error is caused by this memory being classified as Initialized and that software not being able to program it.

Why is .args and .trace classified as Initialized memory.  Can I somehow override the TConf setting so the .out file classifies .args and .trace as Uninitialized?  Or can I remove these sections from the .out file once it has been created?

Thank you for your assistance.

Brian

  • 0
    TI__Mastermind 45025 points

    Hi Brian,

    Please have a look at the following thread, which details how to set the fill value using a linker command file:

    http://e2e.ti.com/support/embedded/bios/f/355/t/143589.aspx

    Steve

  • 0 in reply to Steven Connell
    Prodigy 40 points

    Thank you for your reply Steve.

    By default the TConf generated cmd file fills the .args and .trace sections with 0's as can be seen by the attached code in my original post.  I am attempting to prevent this filling.  When a fill value is specified, the .out file interprets these memory areas as being initialized.  I am trying to get these area classified as uninitialized.  I do not believe there is any reason for these area to be initialized to 0 (or any other value for that matter).  They are simply areas in RAM which are used at runtime.

    Is there a way to use another linker command file to "override" the TConf generated command file's definition of .args and .trace and remove the "fill" from these areas?  I am encountering issues with another tool detecting initialized RAM areas of my .out file when none exist (except for the .args and .trace which I am attempting to get rid of).

    By the way, I am using the TI28335 with 4.2.4.

    Thanks again

    Brian

  • 0 in reply to brian gaddis
    TI__Mastermind 45025 points

    Hi Brian,

    Unfortunately, the template file that's used to generate that linker command file has the fill values hard coded.

    But, there may be a work around.  My colleague and I were able to get the .trace section to be uninitialized using the following trick:

    1. build a BIOS example project
    2. edit the generated *cfg.cmd linker command file
    3. remove the 'fill = 0' from the .trace and .args directives
    4. save the file
    5. open a DOS shell
    6. copy the output of the linker command from the CCS build output window.  You need to make sure you have quotes, see screen shot below.
    7. paste it into the DOS shell and hit enter to re-run the linker
    8. we then see that .trace is uninitialized in the map file

    But, we also saw that .args was still intitialized... it seems that someone else is causing it to be initialized, perhaps the RTS library, but we're not sure.

    I think at this point you can try this to see if it helps with your issue with the hex2000 tool.

    Steve

  • 0 in reply to Steven Connell
    Prodigy 40 points

    Steve

    I appreciate the effort you and your colleague have put into this issue.  The main failure that had me hung up with the failure with SDFlash.  Apparently SDFlash did not accept these initialized area of SRAM in the .out file.  I think I will get away from SDFlash and move over to UniFlash.  I just found out UniFlash could be a solution for me yesterday.  Apparently other folks are using UniFlash to program F28335's without any issues (their projects also contain the initialized .args and .trace sections).

    Hex2000was never a problem for me.  It simply warned me of these sections but skipped them when generating the hex file (which is fine).  I believe initialized RAM sections causing the warnings in hex2000 is causing the failure in SDFlash.

    I have put a ticket into Spectrum Digital to find out if there is an issue with SDFlash and these initialized sections.  If there is a problem on their end, maybe they can fix it for future releases.