• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 101 subscribers
  • Views 570 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.

RE: Integrating Mcbsp with DSPLINK

BABUSUBASHCHANDAR CHANDRA MOHAN
Prodigy 100 points
Other Parts Discussed in Thread: OMAPL138

Hello everyone,

        We are able to do Mcbsp loopback both internally and externally using ccs in windows. The data is being sent from the DSP to the McBSP and looped back.

Now we have to send the data from ARM to DSP and then from DSP to McBSP and also do this integration from Linux, eliminating CCS. Independently, the ARM

to DSP communication (using "tskLoop')  and DSP to McBSP communication (in CCS) is working fine. When we integrate this, some clash happens in the DMA

channels and the communication hangs at the transmit itself.  We need some support on this integration.


We are using FAXLIB libraries for HDLC encoding and decoding. By following the similar way of integrating FAXLIB with DSPLINK, we tried integrating Mcbsp with

DSPLINK.  But that integration does not happen at all.

 

Three things: 1. ARM-DSP communication

           2. McBSP / EDMA  tasks (built in ccs needs to be migrated to linux and integrated with dsplink application)

           3. HDLC init processes.

all these need to be integrated..

 

 

--Thanks and Regards,

BABUSUBASHCHANDAR.

  • 0
    TI__Intellectual 1515 points

    BABUSUBASHCHANDAR CHANDRA MOHAN said:

     When we integrate this, some clash happens in the DMA channels and the communication hangs at the transmit itself.  We need some support on this integration

    Can you please provide more details on the clash?

  • 0 in reply to Shanmuga
    TI__Expert 8150 points

    What device are you using?

  • 0 in reply to Gagan Maur
    Prodigy 100 points

    Hello Gagan,

                We are using omapl138. We are trying to use psp drivers meant for CCS with linux based DSPLINK application. 

     

  • 0 in reply to Shanmuga
    Prodigy 100 points

    Hello Shanmuga,

                    What we infer from ' the application hanging at the first step itself ' is there may be a clash of DMA pool buffers used for inter processor communication and the DMA used for McBSP communication with DSP core.

  • 0 in reply to BABUSUBASHCHANDAR CHANDRA MOHAN
    TI__Intellectual 1515 points

    Dear BABUSUBASHCHANDAR,

     

    BABUSUBASHCHANDAR CHANDRA MOHAN said:

                    What we infer from ' the application hanging at the first step itself ' is there may be a clash of DMA pool buffers used for inter processor communication and the DMA used for McBSP communication with DSP core.

    I am not sure we can infer that way. Can you please check the EDMA configurations used?

  • 0 in reply to Shanmuga
    TI__Intellectual 1915 points

    (details from customer - posted on behalf of them)

     

    To eliminate the integration issue, we once again completely integrated the McBSP application which was working in CCS to the DSPLINK application of Linux. Now, everything is compiled in Linux.  

    After the integration. the hang happens after the ARM issues the first buffer. 
    Also, now we slighlty modified the DSP application to read the buffer from ARM, irrespective of the McBSP data flow. So we expected that, the hang should not happen even if there is any problem with the McBSP. 

    But since the hanging issue persisted, we just commented out the Task functions and added line  by line to identify the cause. 
    While adding SIO_issue(mcbspOutHandle, (Ptr)xmt_buf[count], BUFSIZE, NULL)  the hang happens. 
    We just want to understand if there could be any conflict happening when we do this. 
    regards,
    Padma

  • 0 in reply to govind
    TI__Expert 7290 points

    Govind,

    Generally, the SIO_issue() does not hang, since this is a asynchronous call. It is just the mechanism which provides the buffer to the driver and comes back.

     

    But there are chances of throwing an error, whne number of issue has exceeded the configured value. This normally happen in the environment which calls the SIO_issue() for on a handle from different thread context. So it is better to have a counter just before SIO_isuue() and also at SIO_reclaim(). If this counter exceeds the maximum number of issues, then there is a problem.  The maximum number of issues are provided during the SIO_create(), so it is better to double check the SIO_Attrs.

     

    It would be helpful if you share any error message observed when SIO_issue() hangs?

    Also can you please provide me the DSP PSP version which you are using?

    Thanks and Regards,

    Sandeep K

  • 0 in reply to Sandeep Krishnaswamy
    Prodigy 100 points

    Hello Sandeep,

              Taking the counter you meant here is the timeout attribute of SIO driver, we checked it and it is set to SYS_FOREVER. The things we tried are as follows, 

    * First we tried increasing the number of buffers in DSP side and run the application, it failed and throws "Assertion failed : (DSP_FAILED (status) || ( DSP_SUCCEEDED (status) && (ioInfo->buffer != NULL))"

    * Next we tried increasing the number of buffers in ARM side and run the application, it failed and throws error messages such as "CHNL_issue failed".

    * Only when there is no increase in buffers and plain DSPLINK application it works fine.

    * We just wanted to know whether buffer allocations needed to be done before using any interface at DSP side or not. How we can use an interface with the DSPLINK apllication. 

     

    Thanks and Regards,

    BABUSUBASHCHANDAR.

  • 0 in reply to BABUSUBASHCHANDAR CHANDRA MOHAN
    TI__Expert 7290 points

    Babusubhashchandar,

    BABUSUBASHCHANDAR CHANDRA MOHAN said:
    Taking the counter you meant here is the timeout attribute of SIO driver, we checked it and it is set to SYS_FOREVER

    No, it is not the timeout value. It is like,

    1. Declare a global variable => Eg: Uint32 sio_counter = 0;

    2. Increament the counter, just before the SIO_issue(),

          Eg: sio_counter++;

                 SIO_issue(.....);

    3. decreament the counter,  after the SIO_reclaim(),

          Eg: SIO_reclaim(.....);

                 sio_counter--;

    Whenever you hit to the problem, then please verify the "sio_counter" value.

    BTW, could you please provide the error log message Or the error code returned by the SIO_issue()? Since considering the mismatch in the maximun issue configured and the actual issue, I have suggested the above experiment. The error log may give more insight on the problem.

    Thanks and Regards,

    Sandeep K