• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 82 subscribers
  • Views 492 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.

TMS320F28379D: Relocatable library

Torsten Robitzki
Expert 2474 points
Part Number: TMS320F28379D


Tool/software:

Hello,

I have a library (F021), that is used by both CPUs of a TMS320F28379D. Both CPUs use the same subset of functions from the library and the library has a load address in flash and a run address in RAM.

Now, to save some flash memory, I want one CPU (CPU2 in my example) to contain the library in flash and copy the library to RAM (as usual). As shared RAM can not be executed by both CPUs (what a pity), one copy of the shared library goes into GS0 (for example) and a second copy will be copied to GS1. Now, as both copies have different run addresses, I have to adjust at least on of the copies.

My current approach is, to link the library two times into an out file, with different run addresses, convert both out files to a hex file and then, use a hand written tool, to create a diff over both hex files. The difference is written as a C array to a text file.. CPU2 will then be linked with one copy of the shared library (with the load address for CPU1 for example) and the C array, that contains the differences between booth versions. During startup, CPU2 copies the shared library to GS0 and GS1 and the applies the differences to GS1.

Question: Is it possible to solve that problem, just using tools provided by TI? I've read all the linker documentation covering the --relocatable option, but have got enough details to see, if that way, would allow me to retrieve a table of code locations in the shared library that would have to be corrected, if the run address of the library will be changed.

best regards and thanks in advance,

Torsten

  • 0
    TI__Mastermind 20420 points

    Hi Torsten,

    Let me look into this and get back to you.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    TI__Mastermind 20420 points

    Hi Torsten,

    I apologize for the delay. I suppose I am a little confused by your question. If your library is located in say a C file and you are wanting to be able to call the same library functions from CPU1 and CPU2 (independently), you can do as you have mentioned and use the linker cmd files for each CPU to allocate the library to different global shared RAMs and each CPU will call the version of the library that it allocates. What is the purpose of the other steps you are mentioning?

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    Expert 2474 points

    Hi Delaney,

    once, you link the library to run from specific, but different RAM locations, the resulting binaries will be slightly different (basically, jumps will be different, as the target addresses will differ). For a 3k byte large library, like the TI flash memory library (F021), there are only 26 differences, when linked statically, to specific addresses.

    I want to safe some flash memory (namely, the 3k from above) and store the required code from the library only once, in the flash memory of one CPU.

    What I'm currently do, is to link the library twice, with two different run addresses, calculate the difference of the resulting libraries, and store the difference, so that they are accessible to my application (by generating some C code). One of the CPUs then have one version of the library stored in flash memory. This CPU then copies the library from flash to RAM for both CPUs (two copies) and then corrects one copy with the difference that were calculated at build time.

    This approach make the build quite complex, as I need to build that diff-tool before and this introduces a dependency between the build for the target platform (TMS320F28379D) and the build for the build platform.

    Ideally, I would stick with the tools provided by TI (hextool, linker, compiler etc.). So, I wonder, if there is a way, to generate some kind of relocatable library and excess the required relocation information at load time to fix the absolve addresses used in a library?

    best regards

    Torsten

  • 0 in reply to Torsten Robitzki
    TI__Mastermind 20420 points

    Hi Torsten,

    Thank you for clarifying. Let me consult another expert and get back to you to see if we have a better solution available.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    TI__Mastermind 20420 points

    Hi Torsten,

    After consulting with the other CLA expert, I understand your question now, my apologies. I don't know of a way to do this using our tools, but I will loop in a compiler expert to see if they know of a way.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    Expert 2474 points

    Hi Delany,

    thanks a lot for your effort. I'm still curious whether there is a TI solution to my problem! :-)

  • 0 in reply to Torsten Robitzki
    TI__Mastermind 20420 points

    Hi Torsten,

    Some additional clarifying questions for you from the compiler expert:

    1. Are you creating two separate .out files, one for each CPU?
    2. If so, is each .out file built from the same combination of source and libraries, but with different build time choices being made. i.e. depending on #if statements?

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    Expert 2474 points

    Hi Delaney,

    yes, two different out files. One for each CPU. This first is just linked to the "shared" library, but the section is marked as "TYPE=DSECT", while the out file for the second CPU contains the actual library, linked for the RUN address of CPU2. CPU2 copies the library then into shared RAM for CPU1 and for CPU2 and in addition applies the changes required to fix the library for the different RUN address of CPU2.

  • 0 in reply to Torsten Robitzki
    TI__Mastermind 20420 points

    Hi Torsten,

    I see, thank you for clarifying.

    Best Regards,

    Delaney

  • +1 in reply to Delaney Woodward
    TI__Mastermind 20420 points

    Hi Torsten,

    Unfortunately, it doesn't look like we have any tools that can do what you are trying to achieve. I would recommend sticking with your current approach.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    Expert 2474 points

    Hi

    thanks for taking the time to look into this!

    best regards

    Torsten