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.

Ping-Pong McBSP with EDMA on c6657



Hi,

I am trying to achieve ping-pong operation using the TI McBSP driver provided with the MCSDK.

Lets discuss TX for now:

I am trying to achieve this by calling mcbspSubmitChan twice at start of operation time (one for load ping to main transfer channel and the other to get pong buffered in the queue until first is finished), then I would like to call mcbspSubmitChan each time i get a callback to resubmit ping or pong for ping-pong flow.

If I raise a flag in the callback and call mcbspSubmitChan from a background task everything seems to work well. But if I call it from within the callback the proper flow stops and no more callbacks are called (altough i get result that frame was submitted and is pending).

What am I doing wrong?

Also, does this seem like a proper way to perform ping-pong buffering using the TI McBSP API ?

Also, I don't understang the need of mcbspControlChan with Mcbsp_IOCTL_START if calling mcbspSubmitChan starts TX automatically.

 

P.S. EDMA and configuration is done just like it is done in the example project.

  • Alex,

    Which MCSDK version are you using please? And which McBSP example project you are referring to please?

  • Hi Steven,

     

    I'm using mcsdk_2_01_02_06 with pdk_C6657_1_1_2_6, i'm currently trying to bend the DigitalLoopbackExample to my needs.

    I've managed to create a ping-pong transmission using the above mentioned method, but I'm not satisfied with it and I feel that it's a twisted way to achieve it because for pure ping-pong i shouldn't resubmit frames everytime i get the callback, i should just link ping and pong to one another....

    Is threre a way to link/chain the two spare param sets in the driver to each other(without modifying the driver source code), just by using the driver API?

    Also, another question:

    I've notices that the CLKX is deduced by the driver using the source clock and the word+frame length. Is there a way to configure the CLKX without relation to word and frame length (because I want to allow space between end of data to the next frame sync)?

     

    Thanks in advance,

    Alex

  • Alex,

    I checked with the PDK team that the new McBSP LLD with ping-pong transmission example will be available in the next release of MCSDK 2.1.3, which is scheduled later August. Hope you can refer to that example later without hacking the LLD driver.

    You are using CLKX as output and CLKG is the source (table 2-4 in McBSP user guide), is it correct?

    Based on Figure 2-4 in user guide, the CLKG is divided only by CLKGDV from CLKSRG. The frame period and frame width is used for framing signal (FSG), not data clock. It is what we support in McBSP module.  

  • Hi Steven,

    I have the same problem with Mcbsp and EDMA3. I'm using mcsdk_2_01_02_06 with pdk_C6657_1_1_2_6, i'm currently trying to use the DigitalLoopbackExample.

    I have to configure Mcbsp and EDMA3 with ping pong buffering in both direction with a interleaved multislot stream, with external clock and FS.

    In the past I used the CSL 3.00.10.2 to program the same peripherals in a C6455. May I use the same CSL without TI LLD in the new DSP C6655? 

    Otherwise when do you think will be available the new release of MCSDK 2.1.3 that support?


  • I think the McBSP in C6655 supports buffer FIFO, which seems not to be supported in McBSP of C6455. But overall, the McBSP module is very similar between C6455 and C6655 devices.

    You probably could reuse the C6455 CSL for most of the McBSP registers programming. But the base address of the McBSP configuration register space might be different between C6455 and C6655, which needs to noted.

    For the new release of McBSP LLD for C6655, I am checking with MCSDK team for the release date, which is probably slipped to late November. You may want to use current McBSP LLD or the CSL for your development if the new release does not meet your schedule. 

  • Hi steven,

    I use the modified McBSP LLD and now I'm able to set the mcbsp and the EDMA in a ping pong buffering configuration but I have already a problem.

    My mcbsp has to work with a multislot interleaved frame, 8 bit per slot.

    The new McBSP FIFO works on 32 bit element but I'm trying to use the EDMA in AB Sync to separate the multislot stream in several buffers of 8bit elements.

    If I disable the FIFO and change the EDMA src/dst address from FIFO Data to MCBSP DRR/DXR I don't see any data in McBSP DRR/DXR and my system doesn't work anymore. Have you any suggestion?

    thanks in advance

    alex

  • Alex,

    First of all, there are two McBSP ports in C6455. Please double check if you are using the correct registers addresses for your McBSP setup and EDMA setup.

    And after you disable FIFO and update EDMA setup, you may want to check if McBSP could still generate events to EDMA channels (check RRDY/XRDY bits and check if EDMA channel being triggered by REVT/XEVT).

    Maybe you could try the polling method and CPU transfer first to make sure the McBSP RX/TX is still working without FIFO and then add EDMA transfer back after the sanity check.

    And there is one note below figure 2-17 in McBSP user guide saying

    "Maximum frame frequency may not be possible when the word length is 8-bits,
    depending on the clock divide value CLKGDV. The CPU or EDMA may not
    be able to service serial port requests that occur as frequently as every 8-bit
    clocks. This situation can be resolved by allowing additional space between
    words or choosing a slower bit clock (larger CLKGDV value)."

    You may want to check if the problem is related to the bit clock by slowing it down. Hope those could help.

  • Hi Steve,

    I'm using the McBSP with FIFO, 32bit word in a ping pong application and the system is working well. Now we are trying to integrate the McBSPLoopBack application in another project with NDK 2.22.03.20 and bios 6.35.01.29

    We configure the EDMA interrupt with C code:

    CSL_IntcContext context;
    CSL_IntcGlobalEnableState state;
    CSL_IntcEventHandlerRecord Record[5];

    extern CSL_Edma3Handle      hModule;
    CSL_IntcHandle hIntcGlobalEdmaEvt = NULL;
    CSL_IntcObj intcGlobalEdmaObj;

    void Setup_Interrupt()
    {

    CSL_IntcParam vectId;

     CSL_Status IntStat;

        /* Setup the global Interrupt */
        context.numEvtEntries = 5;
        context.eventhandlerRecord = Record;
        CSL_intcInit(&context);

        /* Enable NMIs  */
        CSL_intcGlobalNmiEnable();

        /* Enable Global Interrupts  */
        CSL_intcGlobalEnable(&state);

        /* Opening a handle for the Global Edma Event  */
        vectId = CSL_INTC_VECTID_8;
        Map_SysEvtIDtoGem_tpccEvtID(0,CSL_TPCC_2,CSL_EDMACC_2_GINT,CSL_INTC_EVENTID_GBLEDMA);
        hIntcGlobalEdmaEvt = CSL_intcOpen (&intcGlobalEdmaObj, CSL_INTC_EVENTID_GBLEDMA, &vectId,  &IntStat);

    //Hook the EDMA ISR
        CSL_intcHookIsr(vectId,&edma_isr);

        // Clear the EDMA interrupt
        CSL_intcHwControl(hIntcGlobalEdmaEvt,CSL_INTC_CMD_EVTCLEAR,NULL);

        // Enabling Events
        CSL_intcHwControl(hIntcGlobalEdmaEvt,CSL_INTC_CMD_EVTENABLE,NULL);

        temp_TCC_Tx[0] =  (Xfr_Complete_Code_Mcbsp_Tx[0]-32);
        temp_TCC_Tx[1] =  (Xfr_Complete_Code_Mcbsp_Tx[1]-32);
        temp_TCC_Rx[0] =  (Xfr_Complete_Code_Mcbsp_Rx[0]-32);
        temp_TCC_Rx[1] =  (Xfr_Complete_Code_Mcbsp_Rx[1]-32);

        ipr.region=CSL_EDMA3_REGION_GLOBAL;
        ipr.intrh= (1 << temp_TCC_Tx[0]) | (1 << temp_TCC_Tx[1])|
                   (1 << temp_TCC_Rx[0]) | (1 << temp_TCC_Rx[1]);

        CSL_edma3HwControl(hModule,CSL_EDMA3_CMD_INTR_ENABLE,&ipr);

    }

    so we map the EDMA3_C_GINT to host INT8

    For ETH MAC interrupt, instead, we map MACTXINT (94) to host INT10 and MACRXINT (99) to host INT9 but we use the BIOS CFG.

    If we enable both interrupts, the ETH MAC doesn't work. In particutar, it has problem as we call in EDMA init the CSL_intcInit:

    /* Setup the global Interrupt */
        context.numEvtEntries = 5;
        context.eventhandlerRecord = Record;
        CSL_intcInit(&context);

    In any case, the EDMA interrupt continues to work correctly.

    Have you any suggestion or could you link me to the correct thread in the E2E forum?

    thank you

     

     

  • Alex,

    It might be the issue that both BIOS and CSL are trying to access ISTP register for different interrupt vector table address as mentioned in the thread below:

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/197958/715740.aspx#715740

    You may search "BIOS CSL Interrupt" or "NDK interrupt" in E2E to find more threads regarding to the similar issue.

    It is recommended to use either BIOS or CSL interrupt setup code to configure all the interrupt events in the same project, which you may give a try as well. 

  • Hi Steve,

    In the previous project on a C6655 we are use the McBSP0 with 64 timeslot, 32bit word, and BFIFO in a ping pong application with EDMA3 and the system is working well.

    We have integrated the McBSP application in another project with NDK 2.22.03.20 and bios 6.35.01.29 (with CSL_EDMACC_2_GINT hooked to a ISR) and it works fine.

    Now we would like to increase the timeslot to 128.

    If I increase the timeslot number the EDMA Param seem to be blocked. This problem is due to BFIFO. The R/WNUMEVT in configured to be equal to timeslot but the maximum value for BFIFO is 64 words. The BFIFO introduced a delay between EDMA transfer and MCBSP.

    If timeslot number is equal to R/WNUMEVT the system work fine.

    If timeslot > R/WNUMEVT I can see data output of the MCBSP but with slot shift.

    Otherwise if  timeslot < R/WNUMEVT the EDMA doesn't receive any event from the MCBSP.

    If I try to disable the BFIFO the EDMA doesn't receive any event from the MCBSP

    I've attached a simple project that I use to test MCBSP-EDMA configuration. May you have a look to it and give me a suggestion

    thanks

    alex

    5224.versione 32 bit.rar