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 external clock shift timeslot

Hello

We are working on c6654  and wehave implemented a mcbsp driver that trigered by edma. The clock of Mcbsp is external.  The application receives data in the correct timeslot but the transmition takes place one timeslot later. Could you please give to us any hint or attach any document?

Thank you

  • Hello Giorgos,

    This might be due to configuration issue. Are you using TI provided example or your custom code ?

    What is the RFRLEN1 and XFRLEN1 value ?

    Regards,
    Senthil
  • Hello,

    The value is 3f in  both of the cases

    Thank you

  • Hello,
    We have noticed that the transmission wave starts before the frame sync pulse
    Best regards
    George
  • Hi,

    Thanks for your update.

    Are you clocks and frmesync are driven by C6654 or by the sample rate generator?

    If the clocks and framesync are defined as output signals then the sample rate generator is used to create clock and framesync with CLKS as an input to the sample rate generator. In case, the core C6654 is driving the clock and framesync then the sample generator is not used and no input for CLKS too is needed. In general, it is easier to program the audio codec to generate these signals and to use CLKR/X and FSR/X signals on the C6654 as inputs. May be, you could try this inorder to avoid transmission starts before FS pulse.

    You can also refer the McBSP example project in PDK directory of C6657. The PDK is part of MCSDK released for Keystone I devices.

    Path: ..\ti\pdk_C6657_1_1_2_6\packages\ti\drv\exampleProjects\MCBSP_DigLpbkExampleProject

    MCSDK download: http://software-dl.ti.com/sdoemb/sdoemb_public_sw/bios_mcsdk/latest/index_FDS.html

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    --------------------------------------------------------------------------------------------------------

  •  Hello,

    We use CLKR/X and FSR/X signals on the C6654  .

    Please find in the attachment the wave that show the problem that we have.

    Actually you can see blue line that data transmission starts almost 8 clocks earlier that the frame pulse.  We have configured 32 8bit only transmission in order to be clear where the problem is represented.

    From MCBSP configuration we cannot find something can cause this behaviour or to delay  the data transmission more that 3 bits.

  • Hello,

    Any update to this issue?

  • Hi,

    I think, there should be messup happened in McBSP configuration in the source code.

    Could you please share the source code of McBSP configuration?

    Did you refer the McBSP reference example project in PDK directory of C6657. The PDK is part of MCSDK released for Keystone I devices.

    Path: ..\ti\pdk_C6657_1_1_2_6\packages\ti\drv\exampleProjects\MCBSP_DigLpbkExampleProject

    May be, you could benchmark the above example to validate the McBSP configuration.

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    --------------------------------------------------------------------------------------------------------

  • Hello,
    Please find the configuration of the MCBSP.
    Yes we have gone through the examples under pdk 6657
    1. Confing MCBSP
    mcbsp->spcr = 0x0;
    mcbsp->pcr = 0;
    mcbsp->rcr = 0x00013F00; //1 bit data delay, 64-timeslots
    mcbsp->xcr = 0x00013F00;
    mcbsp->rcere0 = 0xFFFF_FFFF
    mcbsp->rcere1 = 0xFFFF_FFFF
    mcbsp->xcere0 = 0xFFFF_FFFF;
    mcbsp->xcere1 = 0xFFFF_FFFF;
    Task_sleep( 1 );
    mcbsp->spcr |= 0x10000;
    Task_sleep( 1 );
    mcbsp->spcr = mcbsp->spcr & (~0x10000);
    2.Edma configuration

    3.PCM_hwStartMcBSP
    mcbsp->pcr = 0x00000080;
    mcbsp->srgr = 0x0;
    mcbsp->spcr = 0x3100B1
  • Hello,
    Any update?

    Moreover, is any case to start the transmission before the frame sync comes?

    We have noticed this behaviour in the wave that we have sent and it is strange

    After some experiments   that we set xreset when we open a channel, we are waiting for two cycles to avoid sync error and then we enable the transmitter,  we notice that  data transmission starts in a random time slot. 

    We use an external device for the clock and frame sync. Why xrst affect the timeslot synchronization?

    In our design we have not GPIO hardwired to frame sync. Is any any possibility to synchronize xrst with frame sync in this case?

     


    Thank you

  • Hi,

    What i understand from your McBSP configuration is, your XRDY and RRDY bits of SPCR are not ready even though the serial port transmitter and receiver are enabled. Also, XINT and RINT are generated by XSYNCERR and RSYNCERR bits which indicates there is Tx. and Rx. synchronization error eventhough, XSYNCERR and RSYNCERR bits of SPCR showing 0. I think, kindly write a 1 to XSYNCERR and RSYNCERR bits of SPCR which would set the error condition and would be suited for testing purpose.

    In my opinion, there is synchronixation error detected in both Tx. and Rx which is why XINT and RINT are generated respectively because of XSYNCERR and RSYNCERR. Kindly check the status of XINTM and RINTM bits of SPCR and validate whether XINT and RINT are generated due to a new framesync pulse generation but not due to XYNCERR/RSYNCERR.

    Also, i do observe that, frame-synchronization logic as well sample rate generator is reset and it is not taken out of reset which indicates frame sync is not generated by the sample rate generator. Is my understanding correct? are you using programmed values for FSG.

    As well, i see the FREE bit of SPCR is disabled which would take effect of SOFT bit of SPCR which i think, you are aware of and SOFT bit of SPCR is configured as 0 where soft mode is disabled which indicates serial port clock would stop immediately during emulation halt which would abort any transmissions.

    I would recommend you to validate the McBSP general initialization procedure on section 2.12.1 from keystone McBSP user guide below:

    http://www.ti.com/lit/ug/spruhh0/spruhh0.pdf

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    --------------------------------------------------------------------------------------------------------

  • Hello,
    We have done all the steps expect of the step 8 because in our design there is no pin multiplexing.
    Is any other way to take the value of the frame sync ?
    Best regards
    George
  • Hi,

    I think, you have to debug the code through breakpoints on the desired place where you fetch the FSX and FSR values and take the McBSP and EDMA register dump. With this, please validate the cause of the problem where it originates from?

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    -------------------------------------------------------------------------------------------------------

  • Hello,

    We skip the step 4 and step 6b (wait two PCM cycles for synchronization) delay and the transmission correctly starts when the frame sync comes

    Best regards

    George

  • Hi,

    Thanks for your update.

    Thanks & regards,
    Sivaraj K