• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 97 subscribers
  • Views 487 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.

OMAP-L138 flash copy table help

Kaitlyn Opperman
Prodigy 170 points
Other Parts Discussed in Thread: OMAP-L138

Hello,

I am using the OMAP-L138 (DSP C6748) on a custom board, and the CCS5.1 IDE to debug and develop code.  My DSP compiler version is 7.3.1.  I have not been able to get the linker-generated copy tables described in SPRU186V, section 7.8 to work as I expected.  I am working on a multiple stage boot-loader that is able to call several stages of application code.  I have a small AIS image in flash that only sets the PINMUX registers and jumps to the ARM boot code image.  The ARM boot image only wakes the DSP and jumps to the first DSP image.  DSP Image 1performs all the necessary hardware initialization and jumps again to application code.  This is all working fine using the monolithic, instruction dump binary images generated from the respective ARM and DSP compiler tools with the "-b" option.  This has allowed me to develop chained modules of complete programs that simply jump to the next image in the chain when finished processing.

The problem comes when I try to store code in flash that moves itself to RAM to run.  I need everything out of flash in case I need to write to it.  Using the "load" and "run" linker command options works partially, until I have data in the .const section.  If I have constant values, the linker doesn't know how to move this section to RAM.  If I don't move it to RAM, as soon as I try to read flash status, I will loose access to these constants, as the flash status is read at every address once the command is given.

The linker documentation states that a copy table could be used to move code from flash to RAM.  I only need to move the .text and .const sections (I think) since all other uninitialized sections are already linked into the shared RAM.  From a maintainability standpoint, it would be ideal if the copy table functionality were contained fully within the application images that need if instead of having a separate main that would need to be re-linked if the image it was copying was changed.

It is possible to setup the linker command file to create a copy table for this entire application except for the copy table functionality?  Meaning, can I have my main function call a subroutine to copy the table data using the linker symbols, or do I have to make a separate application?

Using the copy table also generates the LOAD placement warning for the .text and .const sections.  Is there any way to build this application into a boot object, and link that entire object to move from flash to RAM?  I have not had any success in using the object created with the -boot option for further linking.

I tried following the general steps in "Combining Executable Files For ROMing", an application note proposal from 2008, reproduced on the Wiki below.
http://processors.wiki.ti.com/index.php/Combining_executable_files 
I have not had success with this method yet, as I am still unclear as to whether the boot code needs its own main, and which symbols are carried over from the application object for this secondary link step.  I will investigate this further first.

The next step I need to try is to turn off all caching by the DSP.  I think this has been the reason for my limited and inconsistent success with run/load sections, as this seems to work with small programs, but not the main application code.

Any further, specific examples or advice on how the DSP interprets copy tables or boot copy tables, would be greatly appreciated.

-Kaitlyn

  • 0
    Prodigy 170 points

    I am trying to convert the ARM steps for creating an embedded boot image using the DSP tools.  Specifically, I am trying to create the "boot code" that will copy an image.  The steps say to use LOAD_START, LOAD_SIZE, and RUN_START in the linker file to create a symbol.  I have looked at the "task.c" and "F28M35H52C1.cmd" files of the SysBios ADC concerto example of how to use this symbol in code.  It looks like the only thing done in the code is to remove the leading underscore, but this has not worked for me.  I am able to pull in assembly symbols using the extern directive, and the compile step seems to be working (boot.obj is created).  However, when I try to link the boot object with the application object, the symbols are still unresolved and there is a warning for the .cmd file about no matching section for the line with the .app_image section.

    Attached is the test program I am using. 0572.SecondBootObject.zip I am running the "build.bat" file from a command prompt within the test program directory on a Windows XP system.

    I know there is the brief mention of the linker address and dimension operators in section 7.5.8.7 of spru186v, and I tried reading section 7.10 for Linking C/C++ Code.  Neither of these sections cover how to troubleshoot undefined symbols.  I have also tried using the -u option i the boot linker file since the Concerto example had used this option, but it does not seem to make a difference; the symbols remain undefined.

    I am still unclear as to whether a linked boot image, a copy table, or a boot table is most appropriate, and when each should be used.  Is there any place with a very simple example of each of these?

    spru186v section 7.8 describes linker-generated copy tables.  Section 7.8.2 sounds closest to part of the ARM steps used, even though the ARM steps create a separate object to link in instead of a copy table.  The command file is similar and should let me use the linker provided symbols in C code to copy.  Unfortunately, this is the error described above, where I cannot figure out how to let the linker define these symbols.  I have very little experience with linkers, so I may be missing a fundamental concept about how symbols are created and used.

    spru186v section 7.8 section 7.8.4 sounds like an alternative method, but I have not been able to create and use a copy table yet.  I need all of my actual code and constants to copy over (.text and .const) to RAM.  Simply using a table directive in the linker file with my .text section does not seem to accomplish this.

    spru186v section 11.10 has an informative description of the flow for an On-Chip Boot Loader for C2621, C671x, C64x using a boot table.  Is this the only case where a boot table is preferred, or is this simply because these are the only models have the built-in EDMA copy?  The sample command files are a helpful start, but I am still unclear on the actual command line entry to use this properly.  I am also unclear on what the positioning of the boot table is used for.  If a separate boot loader is needed to read the boot table entries, where is this extra link information placed relative to the table entries?  The figure in section 11.10.2 shows only table entries and the termination.

  • 0 in reply to Kaitlyn Opperman
    TI__Guru**** 249780 points

    This appears to be a continuation of your earlier thread.  We compiler experts lack the knowledge to help you.  I'll move this thread to the forum for the OMAP-L1xx and other related devices.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 170 points

    I realize (and would expect) you may specialize in Compilers on the "TI C/C++ Compiler - Forum."   However, the official description on the site map is "TI C/C++ compilers, assemblers, linkers, and related tools."  This is the only forum with "linker" in the description, and none mention post-build or format conversions.http://e2e.ti.com/support/w/forums/261.ti-e2e-community-forums-site-map.aspx

    My questions are about the general tool set, and the chaining of outputs from one stage to another.  

    Would it be at all possible for TI to split off a specialized Linker or HexConverter forum so that specialists of those tools may assist?