Receiving data on McBSP4 as slave

So what you are suggesting is to ignore the mcbsp kernel library and do everything manually?

Yes, I've been through everything related to the McBSP in the TRM multiple times.  I'm actually in the process of going through all the register initialization manually due to a number of discrepancies I found between what the provided mcbsp library does and what the TRM says.  Hopefully it will make a difference.

OK, after trying any reasonable setup combination for a slave receiver I can come up with, I still am unable to get the McBSP4 to clock in anything (DRR bit in spcr1 never set).  In my kernel module, I mapped the appropriate pad config registers into sysfs so that I could manually verify their state at test time.  The mapping is as previously stated;

CONTROL_PADCONF_GPMC_NCS3 = 0x01020000    // [31:16] IEN PD DIS Mode=2, mcbsp4_clk
CONTROL_PADCONF_GPMC_NCS5 = 0x00180102    // [15:0]  IEN PD DIS Mode=2, mcbsp4_dr
                                          // [31:16] gpmc_ncs4
CONTROL_PADCONF_GPMC_NCS7 = 0x01000018    // [15:0]  gpmc_ncs7
CONTROL_PADCONF_MCBSP4_CLKX = 0x4104011c  // [15:0]  gpio_152
                                          // [31:16] gpio_153
CONTROL_PADCONF_MCBSP4_DX = 0x0100000c    // [15:0]  gpio_154
                                          // [31:16] IEN PD DIS Mode=0, mcbsp4_fsx

I have verified that the appropriate signals clk, fs, and data are all present on the intended lines.

Per the suggestion of TI support, I have stopped using the mcbsp kernel lib initialization and followed the TRM initialization procedure to the letter.

set sysconfig => 0x030A to issue global reset
set pcr => 0x201 per section 21.5.1.5.2.1.1
set xccr => 0x9801 per section 21.5.1.5.2.1.2
set spcr1 => 4000 per section 21.5.1.5.2.1.3
section 21.5.1.5.2.1.4 skipped because only applies to mcbsp1
set mcr1 => 0 per section 21.5.1.5.2.1.5
set rcr2 => 0x80A1 per section 21.5.1.5.2.2.1
set rcr1 => 0xA0 per section 21.5.1.5.2.2.2
sections 21.5.1.5.2.2.3 - 21.5.1.5.2.2.7 already completed as part of earlier steps
set rccr => 0x800 per section 21.5.1.5.2.2.8
set thrsh1 => 0 per section 21.5.1.5.2.2.8
set srgr1 => 0x1F01 per section 21.5.1.5.2.2.8
set srgr2 => 0 per section 21.5.1.5.2.3.1
set spcr2 => 0x200
set spcr1 => 0x4001 to enable the receiver

I have alternately followed the initialization procedure in Figure 21-58 of the TRM with the same result.

A slave I2S interface should be the simplest thing in the world to setup as most everything is dictated by the master.  Pretty much all the slave needs to worry about is the word size and phase length.  As long as the clock and framesync are present, I should get something clocked in, even if it is garbage.  If there is a problem with the frame sync polarity relative to the clock or edge problems, I should be getting a frame sync error, but I get nothing.  I've done this on half-a-dozen different processors and never had any issues.  If someone could give me a hint with respect to what I'm missing on this processor, I would greatly appreciate it.

Oops, sorry, I should have double-checked my text above before hitting post.  When I stated that the DRR bit in SPCR1 was never set, I was actually referring to the RRDY bit.

Hi Biser,

After spending some more time looking at the impacts of CLKXM in figure 21-26 of the TRM, can you confirm for me that a slave interface (where clock and frame sync are sourced externally on CLKX and FSX pins, respectively) is not possible with McBSP4.

I say this because in order to get the CLKX signal into the receiver, CLKXM needs to be set to 1 which will also enable the clkx_int output buffer thus loading the original signal and making it unusable.

Thanks,

Gary

Hi Gary,

I am looking into this issue and should have some feedback soon.

Regards,

Melissa

Hi Gary,

Can you try changing the value of CLKXM and EXTCLKGATE to "0"?  

Also, the following forum post shows one customer's 4-pin McBSP configuration for a slave receiver.  See their settings posted on Feb 23.  (Note there is no functional difference between the AM35x and AM37x McBSPs.)

http://e2e.ti.com/support/arm/sitara_arm/f/791/t/165965.aspx

Regards,

Melissa