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.

I2S on McBSP, HELP



Hello

 

I want to run I2S protocol on the McBSP. The DSP is configured as slave and receives a bit clock and frame select. The audio format is 16 bit for left and right channel.

 

Question 1:

How do the McBSP react when the word select is high for 16 bit clock cycles? Does the McBSP resync for every bit clock when word select is high? I don’t find any information about that in the Technical Reference Manual. Or do I have to activate ignore (RFIG/XFIG?

 

Question 2:

How do I synchronize the transmitting and receiving so that the samples for left and right end up correctly? I could end up so the left and right channels are swapped.

  • Marko,

    just wanted to share a MCBSP I2S appnote, it was written for older devices who had a similar version of the mcbsp but I think it will help add more details on this interface details in I2S mode http://www.ti.com/lit/an/spra595/spra595.pdf

     

    regards,

    miguel

     

  • Thank you.

     

    I see they have activated the ignore function:

     

    LOAD_FIELD(&rcr, FRAME_IGNORE , RFIG , 1);

    and

    LOAD_FIELD(&xcr, FRAME_IGNORE , XFIG , 1);

     

    Is this because the word select is high for multiple bit clock cycles?

     

    And I also wonder about the following:

    If the polling method is used to service the transmitter, the CPU should wait for one McBSP
    bit clock (CLKX) before polling again to write the next element in DXR. This is because
    XRDY transitions occur based on bit clock and not CPU clock. The CPU clock is much faster
    and can cause false XRDY status, leading to data errors due to overwrites.

    Does this also effect the FIFO if i enable receive and transmit FIFO?

     

  • Mario,

    sorry for the delay, this email response fell through the cracks on my email..

    Here's some excerpt form the Mcbsp section in the Technical Reference manual that explains on why FRAME IGNORE is used.

    "26.2.7.4.1 Frame Sync Ignore and Unexpected Frame Sync Pulses

    RFIG and XFIG are used to ignore unexpected internal or external frame sync pulses. Any frame sync

    pulse is considered unexpected if it occurs one or more bit clocks earlier than the programmed data delay

    from the end of the previous frame specified by ((R/X)DATDLY). Setting the frame ignore bits to 1 causes

    the serial port to ignore these unexpected frame sync signals.

    In reception, if not ignored (RFIG = 0), an unexpected FSR pulse discards the contents of RSR in favor of

    the incoming data. Therefore, if RFIG = 0, an unexpected frame synchronization pulse aborts the current

    data transfer, sets RSYNCERR in SPCR to 1, and begins the"

     

    I am not very familiar with the FIFO mode and if your second statement affects it.   But practically speaking you likely won't take advantage of the FIFO mode if you use polling methods.  The FIFO mode is typically used for multi buffering data for higher throughput, traditionally used with EDMA.

    I hope this helps in case this was still pending.

    regards,

    miguel