Compiler/TMS320F28062: Partial library inclusion and memory allocation to "Run from RAM"

This looks right ...

Pierre Lorent said:

ramfuncs :
    LOAD = FLASH_RFR,
    RUN = RAML4_5,
    LOAD_START(_RamfuncsLoadStart),
    LOAD_END(_RamfuncsLoadEnd),
    RUN_START(_RamfuncsRunStart),
    LOAD_SIZE(_RamfuncsLoadSize),
    PAGE = 0
{
    --library=usblib.lib (.text)
}

To better understand this linker command file code, please see the wiki article section titled Load at One Address, Run from a Different Address.

Pierre Lorent said:

the linker tells me it now requires 3 times the memory required previously

I cannot explain this memory usage increase based on what is shown here.  Can you demonstrate that the linker is including functions from usblib.lib that are never called?  You can tell by inspecting the linker map file.  For some function that is never called, you will see the function name in the symbol table, and the object file for the never called function appears in the list of files that belong to the output section ramfuncs.  If you see that, I can probably help you.

But there are probably other reasons the memory usage increased.  This method of creating the code ...

Pierre Lorent said:

The library was included in the project by copy-pasting the source code files in the project folders and unfortunately modified to fit with the applications need.

... is quite different from calling functions from a library.  There is no straightforward way to compare them.

Thanks and regards,

-George

Hi, thanks for your help.

 Can you demonstrate that the linker is including functions from usblib.lib that are never called? 

No, it is only a guess based on the fact that it was possible previously to manually relocate the usb library functions from flash to ram using "pragma" while trying to move the whole .lib into it result in a linker failure due to insufficient space ...

Here is the memory usage of this section without any of the usb lib content in it :

The remaining 3800 bytes free corresponds approximately to the space freed when switching from v135 (using sources, run from ram) to v151 (using lib, run from flash). Now when I apply the .cmd with the modification above (I add the {...} to move the library), I get the following error :

If I interpret it correctly this means the library needs 0x6207 - 12.505 = 12.590 bytes to be placed in the run from ram section ... And i doubt v151 includes 3 times more code than v135 to work ... So my conclusion was that some other content is packed in the .lib and is not needed.

I use only the "Bulk Device Class Driver" API as described in the "TivaWare USB library" (pt 2.5) and as there is a lot of other mode for pre-implemented devices (keyboard functions, audio, ...) I guessed this code may be included in the output program without being used ... thus leading to an increased memory usage. I simply don't have any other idea to explain this brutal increase.

For some function that is never called, you will see the function name in the symbol table, and the object file for the never called function appears in the list of files that belong to the output section ramfuncs.  If you see that, I can probably help you.

I will go deeper in the analysis of the .obj related to the usb library and try to see if I can figure out if some are unused but I'm not confident enough with the library structure for now.

This method of creating the code [...] is quite different from calling functions from a library.  There is no straightforward way to compare them.

Sure, I find including directly the library as a package much easier and cleaner than dealing with copied files. But the result was not really what I expected ... ^^

Regards,

Pierre

Based on this discussion (-> link) , It seems I guessed wrong and the linker will not include the unused portions of the library, as suggested.

For testing purpose I have tried to replace the .lib file from the project and insert the source code from the v151 library folders. However, I now have a compilation error and some warnings when doing so ... probably due to conflicts between header files versions.

Is there a preferred way to reuse and include in my current CCS project the source code of the usb library provided by the Control suite ? Is there an easy way to tell the compiler / linker to reuse those files without copying them locally and messing up with the include paths ?

Pierre Lorent said:

Is there a preferred way to reuse and include in my current CCS project the source code of the usb library provided by the Control suite ?

That is not how the library is intended to be used in a project.  So, unfortunately, no one has looked at what is the best way to add the library source code to a project.

Pierre Lorent said:

Is there an easy way to tell the compiler / linker to reuse those files without copying them locally and messing up with the include paths ?

I presume your code is organized as a CCS project.  If so, you ought to consider linking the source files to the project, instead of copying them.  Please read more on this topic in the wiki article section Adding or linking source files and folders to project.

Thanks and regards,

-George

That is not how the library is intended to be used in a project.  So, unfortunately, no one has looked at what is the best way to add the library source code to a project.

Sure, I'm just trying to find a way to be able to debug my project using the source of the library. The reason of all this is I have issues regarding enumerations and cannot understand where it comes from. Being able to work directly on the code of the library may help to trace the code and verify if some operations are not performed properly.

Referring back to your first reply

For some function that is never called, you will see the function name in the symbol table, and the object file for the never called function appears in the list of files that belong to the output section ramfuncs.  If you see that, I can probably help you.

 I found out this from the map file :

.text      0    003e8003    0000581e     

                  003e8003    000015fb     usblib.lib : usbhostenum.obj (.text)
                  003e95fe    00000855                : usbdenum.obj (.text)
                  003e9e53    0000083c     driverlib.lib : usb.obj (.text)
                  003ea68f    0000061c     F2806x_DefaultIsr.obj (.text:retain)
                  003eacab    00000556     Init.obj (.text)

Note that this was obtained when not trying to relocate to "run from ram". It seems the usbhostenum module is contained in the final .text section. However, I only use the library to communicate as a slave device on the usb port, not as a host. So I think this whole block should not be needed in my application.

This would explain a fraction of the increase of the memory footprint. Do you have any idea why it is included ?

Pierre Lorent said:

It seems the usbhostenum module is contained in the final .text section. However, I only use the library to communicate as a slave device on the usb port, not as a host. So I think this whole block should not be needed in my application.

I am not familiar with this library.  So I can only make general comments.

The linker brings usbhostenum.obj in from the library because other code calls a function that is defined in that file. You can see the names of those functions later in the map file.  Look for the table that starts ...

GLOBAL SYMBOLS: SORTED BY Symbol Address 

page  address   name                            
----  -------   ----

Those functions are the symbols which are in the address range 0x003e8003 to 0x003e95fd.  If your code calls just one of those functions, then the entire file is brought into the link.  Is there one large function there?  Or many functions?  Are you sure none of those functions are ever called?  

Thanks and regards,

-George

Hi,

From the map file :

The USB0HostIntHandler() function is the biggest one and seems unused as I only need device mode and thus use USB0DeviceIntHandler() instead. As for the whole module, the direct calls seems not to include host functions but I will need much more manual research to verify if there is no function calls from anywhere in the fraction of the library I use. 

(Note that USBHostResume() is not in usbHostEnum.obj but in usb.obj even if its name contains "host")

I am not familiar with this library.  So I can only make general comments.

I think I will need to ask to someone familiar with the lib for this ... :/

Thanks anyway and don't hesitate if you have any additional tips.

Based on the source code, I also identified 2 modules including the source code responsible to react to interrupts. This fits in the available space. I adapted the .cmd file to relocate only those 2 modules : 

   {
       --library=usblib.lib <usbdenum.obj usbdhandler.obj> (.text)
   }

Is it valid and usefull to remove the ".(text)" such that fetching constants will also be faster ? Resulting in :

   {
       --library=usblib.lib <usbdenum.obj usbdhandler.obj>
   }

The usb library also requires defining constant structures for descriptors, etc ...  Could it be preferable to relocate them to RAM too to improve the reaction time ?

Pierre Lorent said:

Is it valid and usefull to remove the ".(text)" such that fetching constants will also be faster ? Resulting in :

   {
       --library=usblib.lib <usbdenum.obj usbdhandler.obj>
   }

From the simple viewpoint of linker command file syntax, it is valid.  This code means all the sections from those files will be placed in the output section created here.  I lack the expertise to answer important questions like: Is it valid from a hardware perspective?  Will it run faster?

For those questions, I recommend you start a new thread in the C2000 forum.  Either they can help you, or they know who can.

Thanks and regards,

-George