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 I2S Configuration

Other Parts Discussed in Thread: SYSCONFIG

Hello,

I am interfacing to an audio codec using I2S on McBSP2.  This issue that I am running in to is that the codec (which is the master) is clocking 32 bits / phase (64 bits / frame) but the Win CE driver is rendering the audio in 16 bit PCM.

I am trying to determine if there is a way to configure the McBSP so that it will load the transmit shift register when it sees the correct transition on the sync line, shift out the number of bits it is configured for and then pad the least significant bits with 0's until the frame sync transition occurs again. 

Is this possible?

Thanks,

Cam

  • The McBSP can only be programmed to "react" to one edge (rising or falling, not both) of the frame sync.  However, can't you just program the McBSP to do 32-bit transfers?  The DMA would only be putting in 16 bits at a time but the McBSP would output 32 bits at a time (if you configure for 32-bit elements).

  • I tried that, but the it looked like the DMA was transferring to the lower 16 bits of the shift register.  So I would get 16 zeros and then the msb of my data.  But I need the msb of my data first with zeros padded at the end.  I didn't think it was possible to set the CDSA register to DXR + 2 (i.e. not 32 bit aligned).

    I'll give this a try tomorrow and will post my results.

  • 8-, 16-, and 32-bit accesses are allowed for DXR and DRR.  All other McBSP registers only support 32-bit accesses.  So changing the DMA address should be fine.  I expect that will solve your issue though please confirm.

    Best regards,
    Brad

  • I have given this a try and it isn’t working for me.  Although I can hear the audio file scoping it shows that there are data transitions during the second 16 bits of a frame.  I am playing a 1kHz tone, so the consecutive samples shouldn’t vary by much.  What it looks like is happening is that the MCBSP is shifting out 16 bits then grabbing another 16 bits and shifting it out.

     Here are the MCBSP and DMA registers.  Did I configure it correctly as per your suggestion?

     MCBSP2 Reg Dump

    SPCR2    : 00000030

    SPCR1    : 00000080

    RCR2     : 000080a1

    RCR1     : 000000a0

    XCR2     : 000080a1

    XCR1     : 000000a0

    SRGR2    : 0000203f

    SRGR1    : 00000f01

    MCR2     : 00000000

    MCR1     : 00000000

    PCR      : 00004083

    THRSH1   : 0000007f

    THRSH2   : 000003ff

    WAKEUPEN : 00004408

    SYSCONFIG : 00000014

     

    Tx DMA Reg Dump

    CCR      : 0x048C1061

    CLNK_CTRL: 0x00008005

    CICR     : 0x00000028

    CSR      : 0x00000000

    CSDP     : 0x0000E001

    CEN      : 0x00000800

    CFN      : 0x00000002

    CSSA     : 0xB7E7326C

    CDSA     : 0x4902200A

    CSEI     : 0x00000000

    CSFI     : 0x00000000

    CDEI     : 0x00000000

    CDFI     : 0x00000400

    CSAC     : 0x5B63FAFA

    CDAC     : 0x4902200A

    CCEN     : 0x00CFDE9A

    CCFN     : 0x0000DBB2

    COLOR    : 0x00000000

  • I didn't look at every single register, but...

    For RCR1/XCR1, you should have RFRLEN1/XFRLEN1=1, i.e. 2 words per frame for I2S.  Unfortunately I don't think that by itself will fix your problem.  From your description my best guess at what is happening is that perhaps the FIFO is packing the data being sent into it by the DMA.

    Here's one other thing you could do and it's a real hack!  Change your DMA SRC_AMODE to "single-index".  Leave CSEI=0.  This will cause the DMA to transfer an extra 16-bits to the McBSP each time.  So you should get this dummy data being output instead of the next sample.  The dummy data will be ignored by your codec and everything should be good!  (Ugly I know, but I think it ought to work given what you've described.)

     

  • Isn't I2S classified as a dual-phase frame?  If so, I interpret the TRM to say that I have to set xFRLEN1 = 0 which is one word per phase.  Is that incorrect?

    Rather than making the changes to the DMA that you are suggesting, I will modify the driver to write the rendered data to a 32-bit buffer (left shifting the data by 16-bits).

    Thanks Brad.

  • Cam Turner said:
    Isn't I2S classified as a dual-phase frame?  If so, I interpret the TRM to say that I have to set xFRLEN1 = 0 which is one word per phase.  Is that incorrect?

    Sorry, I didn't notice that you have it set as dual-phase.  For some reason the OMAP3 TRM says to implement it this way though I've never done it that way on any other device in the past.  As long as you configured each phase for 32-bit it should be fine.

    The reason dual-phase transfers exists is to support formats that require two different sized element types.  Since I2S has elements of the same size I don't understand why they suggest implementing it that way.

  • Brad Griffis said:

    8-, 16-, and 32-bit accesses are allowed for DXR and DRR.  All other McBSP registers only support 32-bit accesses.  So changing the DMA address should be fine.  I expect that will solve your issue though please confirm.

    Best regards,
    Brad

    Hello Brad,

    According to Paul and SPRUF98M – April 2010 – Revised December 2010 §21.4.2 :
    "The McBSP registers (DRR_REG and DXR_REG) are limited to 32-bit data
    accesses (L4 Interconnect). 16-bit and 8-bit is not allowed and can corrupt
    register content."

    Do you confirm that 8 bits and 16 bits access to DRR_REG/DXR_REG are allowed ?

    Marc

  •  

     

    marc seninge said:

    Do you confirm that 8 bits and 16 bits access to DRR_REG/DXR_REG are allowed ?

    Yes, I confirm that specifically for DXR and DRR you can have 8- and 16-bit accesses.

    In 21.6.1 there is the following note:

    "The McBSP data registers (that is, DXR_REG for data transmit and DRR_REG
    for data receive) support 8/16/32-bit data accesses. All other McBSP registers
    are limited to 32-bit data accesses. 16-bit and 8-bit data accesses are not
    allowed and can corrupt register contents."

    Also, in the "Features" section 21.1.1 the following appears:

    – 32-bit data bus width
    – 32-bit access supported
    – 16- /8-bit access supported only by data registers

     

  • Many thanks for your answer.

    Do you confirm one mistake in §21.4.2 ?

    "                                 CAUTION
    The McBSP registers (DRR_REG and DXR_REG) are limited to 32-bit data
    accesses (L4 Interconnect). 16-bit and 8-bit is not allowed and can corrupt
    register content."

    Marc