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.

McBsp SIO_reclaim error



We are using the SIO to interface to the McBSP drivers. In a SWI we are attempting to write data to the McBSP. We issue the command SIO_ready() to see if there are any buffers ready to reclaim, and if true, we use SIO_reclaim to reclaim the buffers. The problem is, is that SIO_reclaim is returning with the error -9, IOM_ENOTIMPL. How is this even possible? We are not issuing a control command, we are just trying to reclaim an empty buffer. Please assist.

Weare using the McBSP PSP drivers 1.30.01 with BIOS 5.41.09.

  • Jeremiah,

    Could you please provide us following info:

        1. Are using any EVM or the custom board? Please mention the platform.

        2. Have you tried with the McBSP sample application, which comes along with the PSP? 

        3. Please verify, whether the program execution is hitting the function Mcbsp_localSubmitIoctl() in the McBSP driver (Mcbsp_ioctl.c), since other than this function no where the  driver is returning the IOM_ENOTIMPL.

        4. The issue which you have observed is on the slave side or Master side?

    Thanks and Regards,

    Sandeep K

  • We are using a custom board based around the C6748.

    The McBSP sample applications are useless as written. Only useful as an introductory examples to the McBSP and SIO.

    Will try later today to place a break point at Mcbsp_localSubmitIoctl.

    The Mcbsp is operating in a slave mode. An external source is creating the CLK and FSR signals.

  • We have finally had a chance to try putting a breakpoint on both locations that IOM_ENOTIMPL can be returned. While we are running, this error is returned, but neither of the breakpoints are hit. This leads me to believe that the error is happening in the SIO layer.

  • Jeremiah,

    Yes, as you have mentioned, other than the Mcbsp_localSubmitIoctl() in Mcbsp_ioctl.c, the driver is not at all returning the IOM_ENOTIMPL. So the SIO layer might be returning the IOM_ENOTIMPL.

    To confirm this, can you please call the SIO_reclaim() directly without checking the buffer by using the SIO_ready()?

    Regards,

    Sandeep K

  • Jeremiah --

    I looked into this today, and the problem is in the DIO module.   The DIO module is used to map the SIO module to the IOM driver.  The DIO module has

    SIO return codes are SYS return codes.  DIO is returning a timeout error.  SYS_ETIMEOUT is -9.   There's a problem with SEM semaphores when called from SWI threads.   If the SEM is posted by an ISR, the SEM post is queued up and the count does not change until the kernel runs.  Unfortunately, the kernel run after all SWIs have been processed.  I suspect that your SWI is running as a result of the ISR that is posting the posting the semaphore within the driver.  And, when you call SIO_reclaim() from the SWI, the SIO code calls DIO_tskReclaim() and this calls SEM_pend() on a semaphore who's count hasn't yet been incremented.   Since you are probably calling with timeout=0, this semaphore returns immediately with "unavailable".

    Good news is that it is possible to use the SIO module without tasks, as you are trying to do.   To do this, you should set the mode of the driver's useCallbackFxn parameter to 'true' in the .tcf/tci file.

    /*
     *  Add instance of DIO object to use the configured codec. This is the device
     *  SIO streams use.
     */
    var dioCodec = bios.DIO.create("dioAudioIN");
    dioCodec.deviceName = prog.get("audio0");
    dioCodec.useCallBackFxn = true;
    dioCodec.chanParams = prog.extern("audioChanParamsIN");

    var dioCodec = bios.DIO.create("dioAudioOUT");
    dioCodec.deviceName = prog.get("audio0");
    dioCodec.useCallBackFxn = true;
    dioCodec.chanParams = prog.extern("audioChanParamsOUT");


    You can hook up the SIO/DIO/driver to post the SWI for you by using the SIO_Attrs.callback field when you create the stream.

        sioAttrs       = SIO_ATTRS;
        sioAttrs.nbufs = NUM_BUFS;
        sioAttrs.align = BUFALIGN;
        sioAttrs.model = SIO_ISSUERECLAIM;
        sioAttrs.callback = (DEV_Callback *)&callback;

        mcasp_chanparam[0].edmaHandle = hEdma[0];
        mcasp_chanparam[1].edmaHandle = hEdma[0];
       
        callback.fxn = (Fxn)SWI_andnHook;
        callback.arg0 = (Arg)&swiEcho;
        callback.arg1 = (Arg)0x1; /* This sets the IOM_INPUT mode */

        /* open the I/O streams */
        outStream = SIO_create("/dioAudioOUT", SIO_OUTPUT, BUFSIZE, &sioAttrs);:

     

    You can use 'SWI_andnHook' API toclear single bit and trigger the SWI when both input and output are ready.


    I've attached an updated example (based on example from the PSP) that shows how to use SIO with a SWI.

    BTW, If you set the callback mode to 'true' you should be able to use your existing code since this removes the problematic SEM_pend() from the code path that is causing you problems.  If you set cb to 'true', you must set sioAttrs.callback to a valid callback function (can be a simple noop in your case if you want to use your code as is).

    Regards,
    -Karl-

     

     

  • Zip file with updated test files.

     

    7450.sio-swi.zip