• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 317 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.

Problem with linking

Dalibor Kuchta
Prodigy 60 points
Other Parts Discussed in Thread: TMS320F28335, TMS320F2812

I use CGTV5.2.4, BIOS 5.41.10.36 and I have one problem during linking of my project for processsor TMS320f2812: I use in my project itself corrected GIO_submit function, I have my changed gio_sbmt.c file included in one of my library pack and this my version overrides original version inside DSP/BIOS pack. This solution normally works if I provide compilation of project for FPU processor (TMS320F28335), but if I use this solution in project for no FPU processor(TMS320f2812), overriden of function is not provided and original version from DSP/BIOS is used, when I used early for compilation old versions CCG 4.1.2. and DSP/BIOS V5.2, overriden also worked for TMS320f2812 processor, but now with versions CGTV5.2.4, BIOS 5.41.10.36  is problem. Does any body know if there is some possibility to force override original function in DSP/BIOS ?  

  • 0
    TI__Mastermind 20805 points

    The only thing I can think of is the link order of the libraries is different.   Can you check the order of the libraries that you are passing to the linker?   You need to make sure that your library is seen by the linker before the BIOS library.   I cannot explain why it would be different for FPU vs non-FPU.    Everything should be the same.   Maybe check the linker project settings for both projects and see the library link order is same for both.   I think that BIOS 5.x uses the --priority linker option which tells the linker to start back at the beginning of the list of libraries every time a new unresolved symbol is discovered.

    What change did you make to GIO?   Is there a bug in GIO that we should know about?

    Thanks,
    -Karl-

  • 0 in reply to Karl Wechsler
    Prodigy 60 points

    Helo Karl,

    you guided me to do some test and I have found the reason. It is linked original BIOS source if it is added libraries directly to directory libraries in CCS. But if library is added to the linking by BuildOption->Linker, then it works OK, so problem is solved.

    To your question about error in GIO layer: I think, that I have already gave some info about it TI suport, but it is already several years ago, so I do not remember exactly. So, correction is in GIO_submit function, your can see part of this function and my 1 added line:

    packet->misc = (Arg)appCallback;

    /* call down into mini-driver */

    while(GIO->SEMPEND(gioChan->syncObj,0)); // my correction !!! - to reset semaphor if posted before

    status = gioChan->fxns->mdSubmitChan(gioChan->mdChan, packet);

    There arisess problem on original source code by this mechanism. The previous submit operation ends on timeout, but after end of line:

    semStat = GIO->SEMPEND(gioChan->syncObj, gioChan->timeout);

    and before completing the line

    if ((status = gioChan->fxns->mdControlChan(gioChan->mdChan, IOM_CHAN_TIMEDOUT, NULL)) != IOM_COMPLETED) {

    is submitied operation done and callback function to GIO layer is called there is posted SEM object.

    Then during the other calling GIO_submit is SEM object already posted from previous operation. This then generate secondery problem in iom driver. It is of-cource done by concrete implementation.

    My solution solves this improper behaviour of GIO in this specific situation.

    Thank you

    Dalibor