• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 2027 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.

putting .lib functions into RAM

WillCode4Beer
Prodigy 145 points
Other Parts Discussed in Thread: TMS320F28335

I’m working with a 28335 FPU processor and CCS5.  I have some intense computations to perform in a brief period of time, so I want to get the math functions and tables into RAM to maximize throughput.

I am utilizing rts2800_fpu32.lib and rts2800_fpu32_fast_supplement.lib.  The latter is loaded first; this is verified in the .map file.

My problem is that I don’t know how to get these .lib functions (_acos, _atan, _isqrt) into RAM.  I have found scant and scattered information about how to use/modify .cmd files.

In sprca75 is verbiage about the FPUmathTables, telling you what to do if you “do not wish to load a copy of these tables into the device” (unclear if that means Flash or RAM) but it says nothing about getting them into RAM.  I tried some experiments with the FPUmathTables directives in the F28335_nonBIOS_flash.cmd file.  This line already existed there in the MEMORY area:

    FPUTABLES      (R) : origin = 0x3FEBDC, length = 0x0006A0     /* Part of Boot ROM */

I added this line to the SECTIONS area:

    FPUmathTables    : > FPUTABLES, PAGE = 0, TYPE = NOLOAD

After building, the map file informed me that all the utilized library functions were mapped to Flash.  The associated tables were also mapped to Flash.

I changed the line in SECTIONS, removing the TYPE = NOLOAD part.

    FPUmathTables    : > FPUTABLES, PAGE = 0

After building, the map file informed me that nothing had changed.  Everything was the same as when the TYPE = NOLOAD part was included.

Finally, I removed the line in the SECTIONS area and built.  I got a warning that said

#10247-D creating output section “FPUmathTables” without a SECTIONS

Now all the tables were mapped to RAM (!) .  The utilized library functions remained in Flash.

SO: 

  1. How do I amend the .cmd file to properly put the utilized library functions in RAM? 
  2. How do I amend the .cmd file to properly put the trig tables in RAM?  (granted, I achieved this, but only by not including it in the .cmd file.  Surely there’s a better, more assertive and correct way.)
  3. Where will I find better documentation about using and changing .cmd files?

 Thanks in advance.

  • 0
    TI__Guru 64440 points

    My suggestion below is more of an initial, interim test since the FPUmathTables are a part of the library file.  Let's forget for the moment that the FPUmathTables are actually in ROM already (ie. pretend the ROM doesn't exist).  You would need to have these loaded into Flash, but then you desire to move them into RAM for performance reasons.  This is available through the following construct in the linker command file.  It also requires some code in your application code during initialization to perform the copy.

    in linker command file
       FPUmathTables       : LOAD = FLASHH,
                          RUN = RAML0,
                          LOAD_START(_FPUmathTablesLoadStart),
                          LOAD_END(_FPUmathTablesLoadEnd),
                          RUN_START(_FPUmathTablesRunStart),
                          PAGE = 0

    in initialization code
       MemCopy(&FPUmathTablesLoadStart, &FPUmathTablesLoadEnd, &FPUmathTablesRunStart);

     

    Again, this will load the FPUmathTables into Flash and then copy to RAM which is where you ultimately want them for your performance needs.

    I certainly acknowledge that this "wastes" non-volatile memory on the FPUmathTables since when we stop ignoring the fact they are in ROM already.  The next step after you verify the above is to figure out how to copy the tables from ROM to RAM.  I want to first make sure we have a path for you in the interim.

  • 0 in reply to BrandonAzbell
    Mastermind 7585 points

    Brandon,

    I think the solution is simple. Since we speak about BOOT-ROM locations, all addresses (table start, length) are fixed and documented in the boot-ROM user guide. All we need to copy these tables from ROM into RAM is a function call of the memcpy - function with the correct parameters in the initial part of main. The destination address could be any RAM-section, where the customer want's to place the table.

     

     

  • 0 in reply to Frank Bormann
    TI__Guru 64440 points

    WillCode4Beer,

    Did the above suggestion provide you a path to implement what you wanted for the interim?

  • 0 in reply to BrandonAzbell
    Prodigy 145 points

    Brandon,

    Sorry I’ve been away from this post for so long.  We made a change to the design that, for the time being, alleviated the need to deal with maximizing throughput.  This freed me up to pursue other project needs, so I have not yet attempted what you’ve suggested.  But this may very well change back, so I will eventually be looking at this again as time allows.

    I have a couple questions: 

    1. You mentioned twice that the tables are in ROM, leaving me with the impression that perhaps that should be sufficient.  My understanding is that in order to achieve zero wait states (maximize throughput), things need to be in RAM.  Am I mistaken about that in this case?  Will moving the tables to RAM improve throughput?
    2. I was also seeking guidance on how to move library functions to RAM for the same reason: achieve zero wait states to maximize throughput.  Is there a way to get library function calls such as _isqrt into RAM, and will that improve throughput?

    WillCode4Beer

  • 0 in reply to WillCode4Beer
    TI__Guru 64440 points

    WillCode4Beer said:

    You mentioned twice that the tables are in ROM, leaving me with the impression that perhaps that should be sufficient.  My understanding is that in order to achieve zero wait states (maximize throughput), things need to be in RAM.  Am I mistaken about that in this case?  Will moving the tables to RAM improve throughput?

    You are correct, that having the routines in RAM has the potential of operating with 0-wait states.  I say "has the potential" because depending which SRAM block you use, you may observe wait states for program fetches versus data fetches.  Details of this is provided in the TMS320F28335 datasheet in Table 3-5.

    ROM accesses are at 1-wait state.

     

    WillCode4Beer said:

    I was also seeking guidance on how to move library functions to RAM for the same reason: achieve zero wait states to maximize throughput.  Is there a way to get library function calls such as _isqrt into RAM, and will that improve throughput?

    There are ways to manipulate where sections are allocated, whether code (ie. .text) or data sections.  This is performed by the use of the linker command file, potential declaration of user defined named sections, etc.  An small example of this for user defined code sections are actually a part of the code examples for the TMS320F28335.  However, it place code which is found in libraries, you would use similar principles but the specifics may be slightly different.

    The C28x Assembly Language Tools User's Guide is a good resource for providing some descriptions on the concept.  For any modifications you may need to perform in C source files, such as creation of named sections via C #pragma directives, the C28x C/C++ Optimizing Compiler User's Guide is the resource to use.