Re: [Gumstix-users] SSP2 conflict?

[Schlansker, K. <ksc...@fo...>]

On Mon, 2008-06-16 at 17:36 -0400, Ned Forrester wrote:
> Schlansker, Kyle wrote:
> > I'm trying to implement section 8.4.11 of the processor developer's
> > manual (32-bit i2s emulation using SSP) over the SSP2 port.
> > 
> > I'm configuring the PXA to be in slave mode.  Once I've configured the
> > SSP registers and enabled the serial link by setting the SSE bit, I
> > receive one transmit service request interrupt because the transmit fifo
> > is empty.  I service the interrupt by filling it (which is kind of
> > pointless since I only care about receiving data, not sending it), 
> 
> That is the way SPI works: everything going in is matched by something
> going out.  If you have other means to regulate the, or to otherwise
> keep up with, the flow of data from the external master, then you can
> set the read-without-transmit bit (RWOT).  I see that you do have RWOT
> set in SSCR1, below, so you should have tx interrupts disabled, unless
> you really want to load the tx data fifo (but I gather you don't).

I couldn't decipher if RWOT was valid in slave mode.  I tried disabling
the tx interrupts, but it didn't help.  I still can't seem to get any rx
interrupts.  

> > and
> > then I get no more interrupts.
> > 
> > I've scoped out all of the signals and verified that my clocks are
> > correct and data is being sent.
> > 
> > The SSSR2 register says that the PXA is still "syncing slave
> > signals" (the SSSR2[CSS] bit is set).  I've tried the notes that suggest
> > the master device should not send it's frame sync signal until the CSS
> > bit is clear, but it does not seem to help.
> 
> I routinely ignore that suggestion in TI Synchronous format on a PXA255,
> using an external master that is a fire hose of data, and I don't have
> problems with that.  PSP format might be different.

I figure the CSS bit is the most likely culprit here (or a byproduct of
whatever is going on).  the SSSR2[CSS] bit is clear when SSE is clear,
and then as soon as I set SSE the SSSR2[CSS] bit is set and never
clears!

> > Could there be some conflict with another piece of code that is trying
> > to use the 2nd serial port?  My setup is a Verdex, netCF-vx, and a
> > tweener.
> 
> Seems unlikely, but I don't know for sure.
> 
> > Here's how I'm configuring things:
> > 
> > // configure GPIOs
> > pxa_gpio_mode(GPIO19_SSPSCLK2_IN_MD);
> > pxa_gpio_mode(GPIO14_SSPSFRM2_IN_MD);
> > pxa_gpio_mode(GPIO11_SSPRXD2_MD);
> > pxa_gpio_mode(GPIO13_SSPTXD2_MD);
> > 
> > // disable serial port
> > SSCR0_P(ssp_port) &= ~SSCR0_SSE;
> > 
> > // configure serial registers
> > //SSCR0: 0b0000_0000_0001_0000_0000_0000_0011_1111
> > //SSCR1: 0b0010_0011_1000_0000_0001_0011_0000_0011
> > //SSPSP: 0b0000_0010_0000_0000_0000_0000_0000_0000
> > 
> > SSCR0_P(ssp_port) = 0x0010003f;
> 
> You have PSP format selected.  I have not used that mode.  Is the SSPSP
> register set correctly?  Have you carefully read about every bit?

I've gone through every bit and written in the margins of the dev manual
what setting I should use.  That's not to say that I could be wrong
though...

Here's the output from my dump_regs() function.  It includes the PSP
register state.  On this run I tried your suggestion below of
configuring a framed clock (even though mine really is free-running...I
thought I'd give it a shot):
--------------------------------------------------
[5] SSCR0: 0000_0000_0001_0000_0000_0000_1011_1111
[5] SSCR1: 0011_0011_1000_0000_0001_0011_0000_0011
[5] SSPSP: 0000_0010_0000_0000_0000_0000_0000_0000
[5] SSSR : 0000_0000_0100_0000_1111_0000_0010_0100
[5] SSDR : 1111_1111_1111_1111_1111_1111_0111_1111
[5] SSACD: 0000_0000_0000_0000_0000_0000_0000_0000
--------------------------------------------------

> > SSCR1_P(ssp_port) = 0x23801303;
> 
> Is SSCR1[SCFR] set the way you want.  If the SSP expects a continuous
> clock, and you are gating clock along with frame, it might be confused.
> 
> Likewise, make sure that SSCR1[IFS] is set the way you want.
> 
> > SSPSP_P(ssp_port) = 0x02000000;
> > 
> > // enable serial port
> > SSCR0_P(ssp_port) |= SSCR0_SSE;
> > 
> > 
> > It looks like the GPIOs are set correctly:
> > I'm using GPIO pins 11, 13, 14, & 19:
> > 
> > root@gumstix-custom-verdex:~$
> > cat /proc/gpio/GPIO11 /proc/gpio/GPIO13 /proc/gpio/GPIO14 /proc/gpio/GPIO19
> > 11      AF2     in      clear
> > 13      AF1     out     clear
> > 14      AF2     in      set
> > 19      AF1     in      clear
> 
> Looks right, by my reading of the PXA270 dev man, though I am most
> familiar with PXA255.

Yeah, I'm at a loss.  Given that this was my 2nd backup plan, I think
I'm going to have to bail on the Gumstix and move to the Blackfin and
uClinux.  If you have any ideas on a good way to debug the SSP problem,
I would definitely be willing to give it another shot.  I just don't
know how to proceed without seeing what's going on inside the PXA
hardware.

--
kyle