slave McBSP via CLKR & FSR ?

I'll try to phrase my question a little more precisely by boiling it down to a generic question instead of getting tied up in the details:

My impression of the McBSP is that the Receiver and Transmitter can be used entirely independently.  CLKR, FSR, and DR appear to be completely independent of CLKX, FSX, and DX, at least if configured that way.  I understand that there is only one SRG unit for each pair, so it would not be possible to generate different baud rates for receiver and transmitter, at least not from an internal source.  However, if the McBSP is operating as a slave to external signals, then it would seem that my assumption that the receiver and transmitter are independent would be true.

Can anyone confirm or deny this?

P.S.  As mentioned above, I understand that CLKSTP mode short-circuits some of these signals and disconnects them from the external pins, so I am only assuming that the receiver and transmitter are independent outside the CLKSTP mode.

You should be able to use the receive side independently as you are attempting.  You must have something configured incorrectly.  Please post your code and/or register dump of your McBSP configuration.

MCBSP_Config ads2Config =
{
        MCBSP_SPCR1_DEFAULT,
        MCBSP_SPCR2_DEFAULT,
        MCBSP_RCR1_RMK(
                MCBSP_RCR1_RFRLEN1_OF(0),
                MCBSP_RCR1_RWDLEN1_16BIT
        ),
        MCBSP_RCR2_RMK(
                MCBSP_RCR2_RPHASE_SINGLE,
                MCBSP_RCR2_RFRLEN2_OF(0),
                MCBSP_RCR2_RWDLEN2_16BIT,
                MCBSP_RCR2_RCOMPAND_MSB,
                MCBSP_RCR2_RFIG_NO,
                MCBSP_RCR2_RDATDLY_0BIT
        ),
        MCBSP_XCR1_RMK(
                MCBSP_XCR1_XFRLEN1_OF(0),
                MCBSP_XCR1_XWDLEN1_16BIT
        ),
        MCBSP_XCR2_RMK(
                MCBSP_XCR2_XPHASE_SINGLE,
                MCBSP_XCR2_XFRLEN2_OF(0),
                MCBSP_XCR2_XWDLEN2_16BIT,
                MCBSP_XCR2_XCOMPAND_MSB,
                MCBSP_XCR2_XFIG_YES,
                MCBSP_XCR2_XDATDLY_0BIT
        ),
        MCBSP_SRGR1_RMK(
                MCBSP_SRGR1_FWID_OF(0),
                MCBSP_SRGR1_CLKGDV_OF(0)        // 18 MHz ADS79xx @ 20 MHz
        ),
        MCBSP_SRGR2_RMK(
                MCBSP_SRGR2_GSYNC_SYNC,
                MCBSP_SRGR2_CLKSP_RISING,
                MCBSP_SRGR2_CLKSM_CLKS,
                MCBSP_SRGR2_FSGM_DXR2XSR,
                MCBSP_SRGR2_FPER_OF(0)
        ),
        MCBSP_MCR1_DEFAULT,
        MCBSP_MCR2_DEFAULT,
        MCBSP_PCR_RMK(
                MCBSP_PCR_IDLEEN_RESET,
                MCBSP_PCR_XIOEN_GPIO,
                MCBSP_PCR_RIOEN_SP,
                MCBSP_PCR_FSXM_EXTERNAL,
                MCBSP_PCR_FSRM_EXTERNAL,
                MCBSP_PCR_CLKXM_INPUT,
                MCBSP_PCR_CLKRM_INPUT,
                MCBSP_PCR_SCLKME_BCLK,
                MCBSP_PCR_DXSTAT_0,
                MCBSP_PCR_FSXP_ACTIVEHIGH,
                MCBSP_PCR_FSRP_ACTIVELOW,
                MCBSP_PCR_CLKXP_FALLING,
                MCBSP_PCR_CLKRP_RISING
        ),
        MCBSP_RCERA_DEFAULT,
        MCBSP_RCERB_DEFAULT,
        MCBSP_RCERC_DEFAULT,
        MCBSP_RCERD_DEFAULT,
        MCBSP_RCERE_DEFAULT,
        MCBSP_RCERF_DEFAULT,
        MCBSP_RCERG_DEFAULT,
        MCBSP_RCERH_DEFAULT,
        MCBSP_XCERA_DEFAULT,
        MCBSP_XCERB_DEFAULT,
        MCBSP_XCERC_DEFAULT,
        MCBSP_XCERD_DEFAULT,
        MCBSP_XCERE_DEFAULT,
        MCBSP_XCERF_DEFAULT,
        MCBSP_XCERG_DEFAULT,
        MCBSP_XCERH_DEFAULT
};

int ADS_init(...)
{
        hMCBSP = MCBSP_open(n, MCBSP_OPEN_RESET);
        MCBSP_config(hMCBSP, &ads2Config);
        MCBSP_start(hMCBSP, MCBSP_SRGR_START, MCBSP_SRGR_DEFAULT_DELAY);
        MCBSP_start(hMCBSP, MCBSP_RCV_START, 0);
        MCBSP_start(hMCBSP, MCBSP_SRGR_FRAMESYNC, 0);
}

Hmmm, I don't see any major issues (yet).  I noticed you're starting SRGR and the frame sync generator in your ADS_init code.  I wouldn't expect it to break things, but it's not necessary if the clock and framesync are being supplied externally.  Try getting rid of those lines just to be sure.

Also, please copy the McBSP registers directly out of memory.  I've had more than a few past experiences where something subtle in the CSL tripped things up.  I'd like to look at the values that actually end up in the registers (hex).

I have tried the code with and without SRGR and the frame sync generator, but it doesn't work either way.  My first inclination was to leave them in reset to save power.  When that didn't work, I turned them on, just in case.

I notice that the SPI Slave mode uses the SRGR to synchronize the internal clock to the external clock, so now I'm wondering if I need to do this outside SPI mode, too.  It would preclude using transmit and receive separately, of course.

As for the registers, I'll go back into CCSv4 and step through the program to get those.  Be right back...

Here you go, the McBSP2 registers, starting at I/O address 0x3000:

00C3 (SPCR2)
0001 (SPCR1)
0044 (RCR2)
0040 (RCR1)
0040 (XCR2)
0040 (XCR1)
8000 (SRGR2)
0000
0000
0000
0000
0000
0000
0000
200F (PCR)
0000 (RCERC)
...  (*CER*)

I think that I already tried turning SRGR2.GSYNC off. Perhaps I should try changing SRGR2.CLKSM from CLKS to INTERNAL? That would prevent independent Xmission...

Brian Willoughby said:

I think that I already tried turning SRGR2.GSYNC off. Perhaps I should try changing SRGR2.CLKSM from CLKS to INTERNAL? That would prevent independent Xmission...

Do you have anything connected to CLKS pin?  I'm not sure exactly how the McBSP is clocked internally, but perhaps if you specify a clock input that doesn't exist that might cause issues.

Try setting SRGR1 = 0x0001 and SRGR2 = 0x2000, i.e. hardware defaults.

These values should not affect the ability to clock xmt and rcv independently.  That capability is determined in the PCR by the CLKXM, CLKRM, FSXM, FSRM values.

Why do you have the transmit side configured as GPIO (XIOEN=1)?

Can you please share what you have hooked up to the transmit and receive sides?  A diagram/schematic of the McBSP hookup would be even better.

Good question.  There is no CLKS pin on the C5506, at least not that I can see.  However, that shouldn't matter, because when SCLKME=1, CLKSM=0 actually selects the CLKR pin, not the CLKS pin.  See the diagram on page 3-2 of the McBSP documentation, and the list on page 7-40 or 8-37.  I really only used "CLKS" because the headers don't have a #define for "CLKR" (perhaps I should submit that as an enhancement request for the CSL).

I can't use the SRGR2 = 0x2000 default because that would select the CLKX pin, but I could disable GSYNC.  I'll try the SRGR1 default and let you know if that helps.  Then again, I guess you're saying that the entire Sample Rate Generator should be disabled and thus none of this has any effect?

I'm using XIOEN=1 because, theoretically, I'd like to be able to utilize the spare transmit side of McBSP2 as GPIO.  It also seems like a good way to make sure that the transmit side is not doing anything.

My circuit is actually quite configurable, with about a dozen jumpers available to change the transmit and receive.  Basically, I have each McBSP connected to an ADS7951 such that if I want the McBSP to be master, then I connect CLKX, FSX, and DX as outputs, with DR as an input.  When I want the McBSP to be slave, I connect CLKR, FSR, and DR as inputs, with DX as the only output.  It's really not a very complicated circuit.  At the moment, McBSP1 is wired and configured as a master, with McBSP2 wired and configured as a slave.  I'll see if I can put together a schematic, but this is spread across a couple of boards and thus multiple CAD documents.

Brian Willoughby said:

Good question.  There is no CLKS pin on the C5506, at least not that I can see.  However, that shouldn't matter, because when SCLKME=1, CLKSM=0 actually selects the CLKR pin, not the CLKS pin.

Your earlier post shows PCR = 0x200F, which equates to SCLKME=0. 

Brian Willoughby said:

I can't use the SRGR2 = 0x2000 default because that would select the CLKX pin, but I could disable GSYNC.  I'll try the SRGR1 default and let you know if that helps.  Then again, I guess you're saying that the entire Sample Rate Generator should be disabled and thus none of this has any effect?

I believe you should use SRGR2 = 0x2000.  What do you mean it would "select the CLKX pin"?

I think your issue may be the simple fact that you have chosen to clock the McBSP off a non-existent clock (CLKS).  By programming SRGR1/2 to their initial values you'll be clocking the McBSP (internally) from an internal clock.  Please try this out.  It is not related to the clocking of data, but rather to clocking the internal logic of the McBSP.  The data clocking is configured in the PCR, which you have specified to be external.

Good catch!  I fixed PCR, but it still doesn't work.

Now that you mention the internal McBSP clocking, it raises a question: What should that clock frequency be?  I'm running a CLK of 18 MHz, with a 16-bit word rate of 1 MHz.  Do I have to make sure that the internal McBSP clock is above any particular minimum frequency?  Is there a maximum?

Also, earlier I think it was said that I shouldn't need to start the Sample Rate Generator.  Does this have any affect on the internal McBSP clock?

For reference, I still don't get data, and now my registers are as follows:

00C1 SPCR2
0001 SPCR1
0040 RCR2
0040 RCR1
0040 XCR2
0040 XCR1
2000 SRGR2
0001 SRGR1
0000 MCR2
0000 MCR1
0000 RCERA
0000 RCERB
0000 XCERA
0000 XCERB
2087 PCR

Again: I can get this to circuit work in SPI slave mode, but it requires that I use CLKX and FSX as inputs. I keep flipping back to this mode to confirm that my ADS7951 is still talking to McBSP2 correctly. In other words, it really seems like I should be able to get this to work without CLKSTP, and by using CLKR and FSR as my inputs.  At the moment, I have jumpers installed so that CLKX and CLKR are the same, with FSX and FSR also the same.  For the shipping product, I'd prefer not to install those jumpers.

I'm glad you added that last note.  I don't think this is possible in the SPI mode.  (Sorry, must have missed that or forgotten somewhere along the line.)

Here's a quote from Section 6.2 of the McBSP Guide:

The transmit clock signal (CLKX) corresponds to
the serial clock signal (SCK) of the SPI protocol, while the transmit
frame-synchronization signal (FSX) is used as the slave-enable signal (SS).
The receive clock signal (CLKR) and receive frame-synchronization signal
(FSR) are not used in the clock stop mode because these signals are internally
connected to their transmit counterparts, CLKX and FSX.

I am turning off CLKSTP, which means that I'm not in SPI mode.  I'm only trying to get CLKR and FSR working in "normal" mode, not SPI mode.

I only mentioned that I am able to get SPI slave mode to work via CLKX and FSX so that you know the signals are compatible with the McBSP and that I'm not having problems with the other end of the serial link.

Do you think that I should be able to get this working without using SPI mode?

I think it should work when you're not using SPI mode, but I'm about out of suggestions.