• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 450 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Difficulty Getting McBSP Transmit Configured

BHansen
Prodigy 70 points
Other Parts Discussed in Thread: DM3730, SYSCONFIG, TPS65950

I am having trouble configuring the McBSP on a DM3730 to interface with a codec (AD1938). I can't get the McBSP module to transmit any data.

The connections between the DM3730 and the codec are:

   DM3730        Codec

McBSP3_CLKX  <-  BCLK

McBSP3_FSX   <-  LRCLK

McBSP3_DX    ->  DSDATA

McBSP3_DR    <-  ASDATA

(i.e. the McBSP is in slave mode, with bit and frame clocks generated by the codec)


I have tested the McBSP when configured in MASTER mode, and data then goes out McBSP3_DX, so I conclude that the pad configuration is correct.  However, when I run it in SLAVE mode it does not transmit. A scope shows a 48 kHz phase clock input to  _FSX and an approx 12.3 MHz bit clock going to _CLKX, which I expect with the codec's settings of 8 x 32-bit words/frame, 48kHz sampling rate. We are using a LogicPD DM3730 Torpedo development board for the testing.

My guess is that I'm missing something in the configuration registers. The values I'm setting presently (I've tried variations on many of them) are:

    myMcBSP->spcr2 = 0x0300; 
    myMcBSP->spcr1 = 0x0010; 
    myMcBSP->rcr2 = 0x0001;  
    myMcBSP->rcr1 = 0x07A0;       
    myMcBSP->xcr2 = 0x00A1;       
    myMcBSP->xcr1 = 0x07A0;      
    myMcBSP->srgr2 = 0xb0ff;   
    myMcBSP->srgr1 = 0x0100;   
    myMcBSP->mcr2 = 0x00;
    myMcBSP->mcr1 = 0x00;
    myMcBSP->rcera = 0x0F;
    myMcBSP->rcerb = 0x0F;
    myMcBSP->xcera = 0xFF;
    myMcBSP->xcerb = 0xFF;
    myMcBSP->pcr   = 0x058f; 
    myMcBSP->rcerc = 0x00;
    myMcBSP->rcerd = 0x00;
    myMcBSP->xcerc = 0x00;
    myMcBSP->xcerd = 0x00;
    myMcBSP->rcere = 0x00;
    myMcBSP->rcerf = 0x00;
    myMcBSP->xcere = 0x00;
    myMcBSP->xcerf = 0x00;
    myMcBSP->rcerg = 0x00;
    myMcBSP->rcerh = 0x00;
    myMcBSP->xcerg = 0x00;
    myMcBSP->xcerh = 0x00;
    myMcBSP->sysconfig = 0x08;    
    myMcBSP->thrsh2 = 0x00;
    myMcBSP->thrsh1 = 0x00;
    myMcBSP->irqenable = 0x00;
    myMcBSP->wakeupen = 0x00;
    myMcBSP->xccr = 0x1000;       
    myMcBSP->rccr = 0x0800;       
    myMcBSP->sselcr = 0x00;
[then after a delay I take the McBSP out of reset as follows]
    myMcBSP->spcr1 |= (1 << 0);                   
    myMcBSP->spcr2 |= ((1<<7) | (1<<6) | (1<<0) );

Probing the registers with JTAG while stepping through the code shows that:

- XBUFFSTAT (register 0x4902_40B4) starts off at 128 and decrements by one each time I write a new word to DXR, so it looks like the data is getting into the module's queue.

- IRQSTATUS (0x4902_40A0) reads 0x0000_0400 after the McBSP port has been initialized, but before trying to send any data. After running for a while, the value is 0x0000_1410, indicating that the Tx buffer has overflowed (because the test program is continually writing to DXR).

- SPCR2 (0x4902_4010) reads 0x0000_03C7.  XEMPTY bit is set, so there is data in the Tx shift register.

- SPCR1 (0x4902_4014) reads 0x0000_0011. Interestingly, RRDY is *not* set, indicating that there is no data in the receiver despite the fact that codec data is being presented continuously on McBSP3_DR.  This would perhaps suggest that the McBSP's clocking is not working.

I'll keep investigating, but in the meantime does anyone have any suggestions?

Thanks!

Bjarne

  • 0
    Prodigy 70 points

    Further to the above: I found a possibly useful example on http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/t/79759.aspx#291938

    Using the sample code in McBSP_RX_DMA_1.c I do the following:

        /////////////////////////////////////////////////////////////
        // Configure transmitter and receiver
        mcbspSetRxMode(MY_MCBSP, CLK_EXTERNAL, CLKR_SAMPLE_FALL, SYNC_EXTERNAL, SYNC_ACTIVE_HIGH, FULL_CYCLE);
        mcbspSetTxMode(MY_MCBSP, CLK_INTERNAL, CLKX_DRIVE_RISE,  SYNC_INTERNAL, SYNC_ACTIVE_HIGH, HALF_CYCLE, DXENA_OFF, XCLK_FREE, FSX_GATED);
        /////////////////////////////////////////////////////////////
        // Set up frames
        mcbspRxFrameSetup(MY_MCBSP, SINGLE_PHASE, MSB_FIRST, DELAY_1BIT, 8, WORD_32BITS, 1, WORD_8BITS, RIGHT_JUST_ZERO);
        mcbspTxFrameSetup(MY_MCBSP, SINGLE_PHASE, MSB_FIRST, DELAY_1BIT, 8, WORD_32BITS, 1, WORD_8BITS);
        /////////////////////////////////////////////////////////////
        // Program the Sample Rate generator
        mcbspSetupSrg(MY_MCBSP, CLKS, CLKS_RISE, SRG_FREE, 255, 8, 6);    //asking for SRG_SYNC causes no Tx.  Need SRG_FREE
        /////////////////////////////////////////////////////////////
        // Configure loopback
        mcbspLoopback(MY_MCBSP, NO_LOOPBACK);
        /////////////////////////////////////////////////////////////
        // Set the buffer thresholds
        mcbspSetRxThresh(MY_MCBSP, 16);
        mcbspSetTxThresh(MY_MCBSP, 16);
        mcbspDisableTxDma(MY_MCBSP);
        mcbspDisableRxDma(MY_MCBSP);

    This configuration transmits data, but the clock source is CLKS (internal).  When I try specifying CLKX in mcbspSetupSrg(), or when I try to sync to the external clock using  SRG_SYNC, no data goes out.

    Any suggestions?

    Bjarne

  • 0 in reply to BHansen
    Prodigy 70 points

    Checking the PADCONF registers for McBSP3 via JTAG I see:  0x4800_216C = 0x01000100  and 0x4800_2170 = 0x01000100.  That is, the four pins are using mux Mode 0 and have the INPUTENABLE bit set.

    Just noticed a design note on LogicPD's Torpedo SOM schematic (1017879A), sheet 5, "NEED TO SET THE VIF_TRI_EN BIT IN TPS65950 WHEN McBSP3 IS USED EXTERNAL OF THE MODULE".  Looking at the schematic, I see that the McBSP3 (and McBSP2) signals are connected to the codec in the TPS65950, as well as being brought out on external connector J1.  The TPS65950 interface needs to be disabled in order to use the McBSP externally.

    There is a similar thread here: http://e2e.ti.com/support/power_management/pmu/f/43/t/130711.aspx

    By tri-stating the TPS65950 pins sharing the McBSP3 bus (done in the kernel source file .../sound/soc/codecs/twl4030.c) the transmit now works.  Framing is synced to the receive clock and the Tx data is identical to what the DSP is sending out.  There still appears to be a problem with the receive data - looping it back out shows garbled data.

    Bjarne

    [EDIT:]  OK, I sorted out the apparent problem with the Rx data.  It turned out to be a problem with letting the McBSP Tx buffer empty such that it continued sending duplicates of the last valid data word. I was using the Tx data to verify the Rx data, and they didn't look the same.  Keeping the Tx buffer filled with at least a few words fixed this. Implementing a DMA transfer between the buffers, rather than using polling, would have been another way of fixing it.