Stumped by SPI problem

Started by nonuckingfumber February 8, 2007
I have been going round in circles for a few hours with a problem on
the SPI port on an LPC2106.

When I do an SPI transfer there is no clock out, but the interupt for
end of transmission occurs on time as if the SPI is really clocking
the data, I have checked this by varying the SPCCR and I get correct
time variations. My pclk is 30MHz and I am using a value of 30 in the
SPCCR for a 1MHz clock.

The SCK remains at 0V, allthough there is a tiny level shift at the
end of the transmission period as if something is changeing in the pin
ccts (The 0V is actually slightly lowwer when the clk should be present).

I have tried changing the pin to GPIO via PINSEL0 and using IOSET to
force the line high, which it does with no problem so I assume the
problem is not electrical.

My SPCR value is 0xA0. PINSEL0 is 0x20051555.

AFAIK there is nothing else which affects the SCK pin.

Ideas anybody?

An Engineer's Guide to the LPC2100 Series

--- In l..., "nonuckingfumber" wrote:
>
> I have been going round in circles for a few hours with a problem on
> the SPI port on an LPC2106.
>
> When I do an SPI transfer there is no clock out, but the interupt for
> end of transmission occurs on time as if the SPI is really clocking
> the data, I have checked this by varying the SPCCR and I get correct
> time variations. My pclk is 30MHz and I am using a value of 30 in the
> SPCCR for a 1MHz clock.
>
> The SCK remains at 0V, allthough there is a tiny level shift at the
> end of the transmission period as if something is changeing in the pin
> ccts (The 0V is actually slightly lowwer when the clk should be
present).
>
> I have tried changing the pin to GPIO via PINSEL0 and using IOSET to
> force the line high, which it does with no problem so I assume the
> problem is not electrical.
>
> My SPCR value is 0xA0. PINSEL0 is 0x20051555.
>
> AFAIK there is nothing else which affects the SCK pin.
>
> Ideas anybody?
>

Is your Slave select pulled up high?

regards,
Charles
--- In l..., "charlesgrenz" wrote:

> Is your Slave select pulled up high?
>

No. SSEL is set as GPIO as the SPI is only used in master mode. Is
that allowed?
--- In l..., "nonuckingfumber" wrote:
>
> --- In l..., "charlesgrenz" wrote:
>
> > Is your Slave select pulled up high?
> > No. SSEL is set as GPIO as the SPI is only used in master mode. Is
> that allowed?
>

Than you need to pull it up high for the 2106.

regards,
Charles
--- In l..., "charlesgrenz" wrote:
>
> --- In l..., "nonuckingfumber" wrote:
> >
> > --- In l..., "charlesgrenz" wrote:
> >
> > > Is your Slave select pulled up high?
> > >
> >
> > No. SSEL is set as GPIO as the SPI is only used in master mode. Is
> > that allowed?
> > Than you need to pull it up high for the 2106.
>

Free virtual beer to you Charles.....it works.

But I am curious, is this just a quirk of the 2106? On all the micros
I have used SS is irrelevant when you are in master mode, or at least
you can exclude it (why waste a pin?). Trying to solve this problem I
have been through all the LPC SPI docs I can find and there is no
reference to the SS needing to be inactive in master mode. In this app
note,
http://www.nxp.com/acrobat_download/various/MACC06001_LPC2000_SPI.pdf
the SS pin is actually configures as GPIO to generate the CS for the
peripheral (but the chip is an LPC213x).
--- In l..., "nonuckingfumber" wrote:
>
> --- In l..., "charlesgrenz" wrote:
> >
> > --- In l..., "nonuckingfumber" wrote:
> > >
> > > --- In l..., "charlesgrenz"
wrote:
> > >
> > > > Is your Slave select pulled up high?
> > > >
> > >
> > > No. SSEL is set as GPIO as the SPI is only used in master mode. Is
> > > that allowed?
> > >
> >
> > Than you need to pull it up high for the 2106.
> > Free virtual beer to you Charles.....it works.
>
> But I am curious, is this just a quirk of the 2106? On all the micros
> I have used SS is irrelevant when you are in master mode, or at least
> you can exclude it (why waste a pin?). Trying to solve this problem I
> have been through all the LPC SPI docs I can find and there is no
> reference to the SS needing to be inactive in master mode. In this app
> note,
> http://www.nxp.com/acrobat_download/various/MACC06001_LPC2000_SPI.pdf
> the SS pin is actually configures as GPIO to generate the CS for the
> peripheral (but the chip is an LPC213x).
>

Thanks for the beer!

Glad that resolved the issue. You should check the errata sheets for
each processor. If I remember correctly this is the only processor
(and the first one out of production) that had this particular problem.

regards,
Charles
charlesgrenz wrote:
> each processor. If I remember correctly this is the only processor
> (and the first one out of production) that had this particular problem.

Nope, the LPC2114/2124/2212/2214 also have it, and it is also mentioned
in the user manual:

"Note: LPC2114/2124/2212/2214 configured to operate as SPI master MUST
select SSEL functionality on an apropriate pin and have HIGH level on
this pin in order to act as a master."

-- Page 163, 2004 May 03 version of the user manual.

Compare this to a fresher device:

"On the LPC2131/2/4/6/8 (unlike earlier Philips ARM devices) the SSEL0
pin can be used for a different function when the SPI0 interface is only
used in Master mode. For example, pin hosting the SSEL0 function can be
configured as an output digital GPIO pin and used to select one of the
SPI0 slaves."

-- Page 151, 2005 June 24 version of the LPC2138 user manual.

So it is a known, and documented fact, which makes it a feature,
not a bug or problem :-)

Sam
--- In l..., Sam Laur wrote:
>

>
> So it is a known, and documented fact, which makes it a feature,
> not a bug or problem :-)
>
> Sam
>

Given that it detracts from functionality without adding anything I
would say that it is a characteristic rather than a feature ;-)

In my LPC2104/5/6 UM I have now found an indirect reference to the
characteristic under the mode fault flag description. Either I am
deficient or LPC documentation is not particularly good. The choice is
yours ;-)
--- In l..., "charlesgrenz" wrote:

> Glad that resolved the issue. You should check the errata sheets for
> each processor. If I remember correctly this is the only processor
> (and the first one out of production) that had this particular problem.
>
> regards,
> Charles
>

I did check the errata sheets and there were a couple of SPI issues,
but not this one. I did however eventuly find an oblique reference to
it under the description of the mode fault flag. I had not read this
because I **know** what a mode fault is and I **know** you don't get
them in master only mode :-)))))
--- In l..., Sam Laur wrote:
>
> charlesgrenz wrote:
> > each processor. If I remember correctly this is the only processor
> > (and the first one out of production) that had this particular
problem.
>
> Nope, the LPC2114/2124/2212/2214 also have it, and it is also mentioned
> in the user manual:
>
> "Note: LPC2114/2124/2212/2214 configured to operate as SPI master MUST
> select SSEL functionality on an apropriate pin and have HIGH level on
> this pin in order to act as a master."
>
> -- Page 163, 2004 May 03 version of the user manual.
>
> Compare this to a fresher device:
>
> "On the LPC2131/2/4/6/8 (unlike earlier Philips ARM devices) the SSEL0
> pin can be used for a different function when the SPI0 interface is only
> used in Master mode. For example, pin hosting the SSEL0 function can be
> configured as an output digital GPIO pin and used to select one of the
> SPI0 slaves."
>
> -- Page 151, 2005 June 24 version of the LPC2138 user manual.
>
> So it is a known, and documented fact, which makes it a feature,
> not a bug or problem :-)
>
> Sam

I'm using the LPC2210, and the current docs say the same thing, that
SSEL0 can be used for other purposes when using the SPI in Master mode.
Unfortunately for my latest project, that has turned out to be FALSE.
SPI0 will not generate ANY external signals (CLK, MOSI) if the pin
hosting SSEL0 is set to any other function, though my transmit
interrupt fires as if it is working correctly.

I would appreciate if anyone out there using the '2210 could attempt
to reproduce my results.

I submitted it to NXP today, I'll let you know when I hear back from them.

--Gene