• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 53 subscribers
  • Views 536 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.

Optimization problem

Stan Pan
Prodigy 40 points

Other Parts Discussed in Thread: TMS320DM6446

Hi,

we are developing application for TMS320DM6446, using both arm and dsp cores. DSP binary contains code from simulink model and small wrapper using dsplink for communication with arm processor (master). Recently we had problems with execution of binary for dsp,. Normally application running on arm core uses IPC (dsplink) to activate single iteration of algorithm running on dsp and than waits for results to start new cycle. Problem is that sometimes dsp blocks execution when starting second iteration. It is enough to call calculation routine only once as a part of dsp binary inicialization phase, and dsp will block during second iteration.
So now I'm trying to switch from older compiler 6.0.21 to a newer one. It seems that result depends on optimization level, when set to -o0 or -o1, compiler generates working binary, when using higher optimization level (-o2) something goes wrong and dsp binary no longer works as expected. This behaviour seems to be same for several tested compiler releases (6.1.23, 7.2.12, ...).
You can find the project files within my profile, I know that this is probably not the best test case, but it is not easy to come with something smaller, as this problematic behavior disappears and reappears unexpectedly, while extending the simulink model.

Best regards

Stan

 

  • 0
    TI__Guru* 84285 points

    Most likely you're going to have to be a bit more specific about what the proximal symptom is.  What do you mean by "blocks execution?"  Is one iteration grabbing a semaphore and failing to release it?  Is it running forever unexpectedly?  Is it failing to set some guard variable?  In other words, exactly how do you know that the program is not working as expected?

    You should try release branch 7.4.x, even 7.2.x is pretty old.

  • 0 in reply to Archaeologist
    Prodigy 40 points

    This is the part which is causing problems:
      Alg_Calculations_initialize(); 
      Alg_Calculations_step(); // something goes wrong here 
      while (1) {
        MSGQ_get(...); // wait for a message from arm
        MSGQ_put(...); // notify arm cpu that we are finished...
      }
    Execution of the program is blocked within the infinite loop after 1 iteration (arm cpu receives 1 notification). This happens only when Alg_Calculations_step() is called, when commented out, messages are exchanged between arm and dsp without errors. In order to observe this, optimization level has to be set to -o2, with -o1 program works as expected.  

    I get same symptoms with 7.4.2.

  • 0 in reply to Stan Pan
    TI__Guru* 84285 points

    I'm sorry, I don't know anything about any of those functions, so there's not much that can be done for you here on the compiler forum.  From what you've said, I assume the problem is that MSGQ_get waits forever for a message from ARM that never comes.  The next step is to figure out whether the ARM is actually sending the message.  I will assume that it does, which seems likely given the conditions of the bug.  Then the question is, why did the DSP miss the signal?  Did the signal come at a time when the DSP was not ready to handle it?  Was the interrupt handler installed at the time?  Did the signal get propagated to the DSP, or was it lost somewhere?  Did the MSGC_get function actually receive the message and discard it?  Did it receive the message and fail to return?  Are these functions part of a library?  Do you compile the bodies of these functions when you compile your program?

  • 0 in reply to Archaeologist
    Prodigy 40 points

    MSGQ_get and  MSGQ_put are functions from DSPLink, other two functions contains custom code generated by simulink. Indeed dsp remains blocked when calling MSGQ_get(). I cannot say that for sure, but the reason why this function is blocked forever is caused by memory corruption after calling Alg_Calculations_step(). 
    DSPLink files are just linked, but all other functions are compiled. The reason why I think this is compiler related problem is different behaviour when object file containing  almost solely Alg_Calculations_step() function is produced using -o2 option (program blocks) and -o1 option (program runs smoothly). 

  • 0 in reply to Stan Pan
    TI__Guru* 84285 points

    What leads you to believe that there is memory corruption?

  • 0 in reply to Archaeologist
    Prodigy 40 points

    Ok it wasn't compiler problem. It was related to the size of the stack, once TSK stack size was changed (increased) application works again...
    Thank you for your patience...