--- In l..., "Owen Edwards" wrote:
>
> (Really glad I started this thread; I'm enjoying the lively discussion.)
>
> Turns out the documentation (at least, the UM10139 User Manual I have) is inconsistent; SSEL0 (from the SPI block) is *always* an input, and as you say, generates a mode fault if it is driven active by another master during a transfer (12.2.9). *But*, the SSEL1 from the SSP block is marked as an input in the chip block diagram Fig. 1 and Table 58, but as an I/O in Table 161 (SSP description), and described as an output in 13.3.4 and following. This seems to agree with the fact that there is no mode fault detection for the SSP block, and fits with my (and others) observation that SSEL can be driven by the LPC2148.
>
> I think what Marcus said about some SPI devices needing the SSEL to stay active (low) during multi-byte transfers is relevant. On reading the chapter in detail, the description of CPHA is incomplete; Table 163 describes CPHA's effect on the SCK signal between transfers, but the detailed description makes it clear that it affects whether SSEL is kept asserted between transfers on not. I'd guess that this has caused people to have problems with their SSP/SPI interface, and resort to using GPIO instead.
>
> -Owen

Yup! We have to be clear about which gadget we are talking about. The SPI gadget never drives SSEL. Table 58 "P0.20" also says that SSEL1 is only an input for the SSP device but table 161 says it is a frame synch output, etc.

So, SSEL1 may, or may not, be useful with the SSP gadget but SSEL0 is always an input for the SPI gadget.

I don't think I have ever used SSEL1 as an output. More often than not, multibyte transfers are required and the action of SSEL1 may not be helpful.

Then too, I often have more than one SPI slave so, sooner or later, I have to create slave select signals.

Richard

An Engineer's Guide to the LPC2100 Series

(Really glad I started this thread; I'm enjoying the lively discussion.)

Turns out the documentation (at least, the UM10139 User Manual I have) is inconsistent; SSEL0 (from the SPI block) is *always* an input, and as you say, generates a mode fault if it is driven active by another master during a transfer (12.2.9). *But*, the SSEL1 from the SSP block is marked as an input in the chip block diagram Fig. 1 and Table 58, but as an I/O in Table 161 (SSP description), and described as an output in 13.3.4 and following. This seems to agree with the fact that there is no mode fault detection for the SSP block, and fits with my (and others) observation that SSEL can be driven by the LPC2148.

I think what Marcus said about some SPI devices needing the SSEL to stay active (low) during multi-byte transfers is relevant. On reading the chapter in detail, the description of CPHA is incomplete; Table 163 describes CPHA's effect on the SCK signal between transfers, but the detailed description makes it clear that it affects whether SSEL is kept asserted between transfers on not. I'd guess that this has caused people to have problems with their SSP/SPI interface, and resort to using GPIO instead.

-Owen

--- In l..., "rtstofer" wrote:
>
> There are at least three reasons why the SSEL pin is configured as GPIO if it is used to select slave devices:
>
> 1) SSEL is "Slave Select" and used to select the 2148 as a slave.
>
> 2) When configured as SSEL the pin is an input, never an output. See table 58 "P0.7/SSEL0/PWM2/EINT2" of the User Manual
>
> 3) If the pin is configured as SSEL with the SPI block configured as a master, when SSEL is driven low by an external device there will be a mode fault. See section 12.2.9 of the User Manual
>
> Richard
>
> --- In l..., Marcus Andreotti wrote:
> >
> > Interesting hearing about people having problems with SSEL operation on
> > LPC200 series. I've been using 2103, 2138, 2148 and 2368 and haven't had any
> > problems with SSEL pin operation. I do, however, have to configure SSEL as
> > GPIO when communicating with SSP/SPI devices that needs to be kept selected
> > during message transfers that needs more than one message frame (i.e flash
> > memories), or they will not work as intended.
> >
> > Marcus
> >
> > On Tue, May 19, 2009 at 7:32 PM, Owen Edwards wrote:
> >
> > >
> > >
> > > I'm using the SparkFun Logomatic V2 board to read LIS302 accelerometers
> > > over SPI (using the SSP port), basing my code on the KinetaMap code (also
> > > from SparkFun). Now that I have it working (and have a reasonable
> > > understanding of SPI bus operation), I'm curious why in so many LPC214x
> > > applications using SPI in Master mode (including the Logomatic's and
> > > KinetaMap's access of the SD/MMC card), the SSEL pin is configured and
> > > driven as *GPIO*. I've confirmed that, if you configure either the SPI or
> > > SSP port's SSEL pin as SSEL, when you write data out to the interface, the
> > > peripheral handles SSEL going low during the transfer automatically, so why
> > > add the code complexity and time penalty of driving SSEL separately?
> > >
> > > I understand that there are situations where there are multiple external
> > > devices connected to one SPI bus, so you need multiple SSELx lines, and they
> > > *have* to be done in software (I'm actually handling three LIS302's right
> > > now), but, for example, the SPI port on the Logomatic is *only* connected to
> > > the SD card -- the pins aren't broken out elsewhere -- so why not just let
> > > the SPI block in the LPC2148 handle SSEL operation? What am I missing? I
> > > tried this briefly, and it seemed to work fine, but I'm wondering if there's
> > > a "feature" that I don't know about.
> > >
> > > -Owen
> > >
> > >
> > >
> >
> >
> >
>

There are at least three reasons why the SSEL pin is configured as GPIO if it is used to select slave devices:

1) SSEL is "Slave Select" and used to select the 2148 as a slave.

2) When configured as SSEL the pin is an input, never an output. See table 58 "P0.7/SSEL0/PWM2/EINT2" of the User Manual

3) If the pin is configured as SSEL with the SPI block configured as a master, when SSEL is driven low by an external device there will be a mode fault. See section 12.2.9 of the User Manual

Richard

--- In l..., Marcus Andreotti wrote:
>
> Interesting hearing about people having problems with SSEL operation on
> LPC200 series. I've been using 2103, 2138, 2148 and 2368 and haven't had any
> problems with SSEL pin operation. I do, however, have to configure SSEL as
> GPIO when communicating with SSP/SPI devices that needs to be kept selected
> during message transfers that needs more than one message frame (i.e flash
> memories), or they will not work as intended.
>
> Marcus
>
> On Tue, May 19, 2009 at 7:32 PM, Owen Edwards wrote:
>
> >
> >
> > I'm using the SparkFun Logomatic V2 board to read LIS302 accelerometers
> > over SPI (using the SSP port), basing my code on the KinetaMap code (also
> > from SparkFun). Now that I have it working (and have a reasonable
> > understanding of SPI bus operation), I'm curious why in so many LPC214x
> > applications using SPI in Master mode (including the Logomatic's and
> > KinetaMap's access of the SD/MMC card), the SSEL pin is configured and
> > driven as *GPIO*. I've confirmed that, if you configure either the SPI or
> > SSP port's SSEL pin as SSEL, when you write data out to the interface, the
> > peripheral handles SSEL going low during the transfer automatically, so why
> > add the code complexity and time penalty of driving SSEL separately?
> >
> > I understand that there are situations where there are multiple external
> > devices connected to one SPI bus, so you need multiple SSELx lines, and they
> > *have* to be done in software (I'm actually handling three LIS302's right
> > now), but, for example, the SPI port on the Logomatic is *only* connected to
> > the SD card -- the pins aren't broken out elsewhere -- so why not just let
> > the SPI block in the LPC2148 handle SSEL operation? What am I missing? I
> > tried this briefly, and it seemed to work fine, but I'm wondering if there's
> > a "feature" that I don't know about.
> >
> > -Owen
> >
> >
> >
>
>

Only problem with SSEL.That's all.Otherwise SPI module works without any
problem.J

From: l... [mailto:l...] On Behalf Of
Marcus Andreotti
Sent: Tuesday, May 19, 2009 5:29 PM
To: l...
Subject: Re: [lpc2000] SPI / SSP driving SSEL signal as Master in LPC2148
applications

Interesting hearing about people having problems with SSEL operation on
LPC200 series. I've been using 2103, 2138, 2148 and 2368 and haven't had any
problems with SSEL pin operation. I do, however, have to configure SSEL as
GPIO when communicating with SSP/SPI devices that needs to be kept selected
during message transfers that needs more than one message frame (i.e flash
memories), or they will not work as intended.

Marcus

On Tue, May 19, 2009 at 7:32 PM, Owen Edwards >wrote:

> I'm using the SparkFun Logomatic V2 board to read LIS302 accelerometers
> over SPI (using the SSP port), basing my code on the KinetaMap code (also
> from SparkFun). Now that I have it working (and have a reasonable
> understanding of SPI bus operation), I'm curious why in so many LPC214x
> applications using SPI in Master mode (including the Logomatic's and
> KinetaMap's access of the SD/MMC card), the SSEL pin is configured and
> driven as *GPIO*. I've confirmed that, if you configure either the SPI or
> SSP port's SSEL pin as SSEL, when you write data out to the interface, the
> peripheral handles SSEL going low during the transfer automatically, so
why
> add the code complexity and time penalty of driving SSEL separately?
>
> I understand that there are situations where there are multiple external
> devices connected to one SPI bus, so you need multiple SSELx lines, and
they
> *have* to be done in software (I'm actually handling three LIS302's right
> now), but, for example, the SPI port on the Logomatic is *only* connected
to
> the SD card -- the pins aren't broken out elsewhere -- so why not just let
> the SPI block in the LPC2148 handle SSEL operation? What am I missing? I
> tried this briefly, and it seemed to work fine, but I'm wondering if
there's
> a "feature" that I don't know about.
>
> -Owen
>

Interesting hearing about people having problems with SSEL operation on
LPC200 series. I've been using 2103, 2138, 2148 and 2368 and haven't had any
problems with SSEL pin operation. I do, however, have to configure SSEL as
GPIO when communicating with SSP/SPI devices that needs to be kept selected
during message transfers that needs more than one message frame (i.e flash
memories), or they will not work as intended.

Marcus

On Tue, May 19, 2009 at 7:32 PM, Owen Edwards wrote:

> I'm using the SparkFun Logomatic V2 board to read LIS302 accelerometers
> over SPI (using the SSP port), basing my code on the KinetaMap code (also
> from SparkFun). Now that I have it working (and have a reasonable
> understanding of SPI bus operation), I'm curious why in so many LPC214x
> applications using SPI in Master mode (including the Logomatic's and
> KinetaMap's access of the SD/MMC card), the SSEL pin is configured and
> driven as *GPIO*. I've confirmed that, if you configure either the SPI or
> SSP port's SSEL pin as SSEL, when you write data out to the interface, the
> peripheral handles SSEL going low during the transfer automatically, so why
> add the code complexity and time penalty of driving SSEL separately?
>
> I understand that there are situations where there are multiple external
> devices connected to one SPI bus, so you need multiple SSELx lines, and they
> *have* to be done in software (I'm actually handling three LIS302's right
> now), but, for example, the SPI port on the Logomatic is *only* connected to
> the SD card -- the pins aren't broken out elsewhere -- so why not just let
> the SPI block in the LPC2148 handle SSEL operation? What am I missing? I
> tried this briefly, and it seemed to work fine, but I'm wondering if there's
> a "feature" that I don't know about.
>
> -Owen
>

Dnia 19-05-2009, wto o godzinie 07:32 +0000, Owen Edwards napisał(a):
> I'm using the SparkFun Logomatic V2 board to read LIS302
> accelerometers over SPI (using the SSP port), basing my code on the
> KinetaMap code (also from SparkFun). Now that I have it working (and
> have a reasonable understanding of SPI bus operation), I'm curious why
> in so many LPC214x applications using SPI in Master mode (including
> the Logomatic's and KinetaMap's access of the SD/MMC card), the SSEL
> pin is configured and driven as *GPIO*. I've confirmed that, if you
> configure either the SPI or SSP port's SSEL pin as SSEL, when you
> write data out to the interface, the peripheral handles SSEL going low
> during the transfer automatically, so why add the code complexity and
> time penalty of driving SSEL separately?
>
> I understand that there are situations where there are multiple
> external devices connected to one SPI bus, so you need multiple SSELx
> lines, and they *have* to be done in software (I'm actually handling
> three LIS302's right now), but, for example, the SPI port on the
> Logomatic is *only* connected to the SD card -- the pins aren't broken
> out elsewhere -- so why not just let the SPI block in the LPC2148
> handle SSEL operation? What am I missing? I tried this briefly, and it
> seemed to work fine, but I'm wondering if there's a "feature" that I
> don't know about.
>

User Manual says that SSEL is input pin.
>
--
Albert

On Tue, May 19, 2009 at 1:02 PM, Owen Edwards wrote:

> I'm using the SparkFun Logomatic V2 board to read LIS302 accelerometers
> over SPI (using the SSP port), basing my code on the KinetaMap code (also
> from SparkFun). Now that I have it working (and have a reasonable
> understanding of SPI bus operation), I'm curious why in so many LPC214x
> applications using SPI in Master mode (including the Logomatic's and
> KinetaMap's access of the SD/MMC card), the SSEL pin is configured and
> driven as *GPIO*. I've confirmed that, if you configure either the SPI or
> SSP port's SSEL pin as SSEL, when you write data out to the interface, the
> peripheral handles SSEL going low during the transfer automatically, so why
> add the code complexity and time penalty of driving SSEL separately?
>
> I understand that there are situations where there are multiple external
> devices connected to one SPI bus, so you need multiple SSELx lines, and they
> *have* to be done in software (I'm actually handling three LIS302's right
> now), but, for example, the SPI port on the Logomatic is *only* connected to
> the SD card -- the pins aren't broken out elsewhere -- so why not just let
> the SPI block in the LPC2148 handle SSEL operation? What am I missing? I
> tried this briefly, and it seemed to work fine, but I'm wondering if there's
> a "feature" that I don't know about.
>

>> Are you sure that the SSEL line is driven automatically? Some time ago we
tried to configure the PIN as SSEL on 2148, somehow it did not work. We had
to configure it as GPIO and control separately.

-Ashwin

My experience working with SPI module of LPC2220 is that SSEL pin never
works as SSEL. You need to configure the same as GPIO and control the chip
select yourself. Although data sheet specifies something else, practically
SSEL does not work. We had invested a lot of time identifying the cause.

Regards,

Himanshu Patel

From: l... [mailto:l...] On Behalf Of
Owen Edwards
Sent: Tuesday, May 19, 2009 1:03 PM
To: l...
Subject: [lpc2000] SPI / SSP driving SSEL signal as Master in LPC2148
applications

I'm using the SparkFun Logomatic V2 board to read LIS302 accelerometers over
SPI (using the SSP port), basing my code on the KinetaMap code (also from
SparkFun). Now that I have it working (and have a reasonable understanding
of SPI bus operation), I'm curious why in so many LPC214x applications using
SPI in Master mode (including the Logomatic's and KinetaMap's access of the
SD/MMC card), the SSEL pin is configured and driven as *GPIO*. I've
confirmed that, if you configure either the SPI or SSP port's SSEL pin as
SSEL, when you write data out to the interface, the peripheral handles SSEL
going low during the transfer automatically, so why add the code complexity
and time penalty of driving SSEL separately?

I understand that there are situations where there are multiple external
devices connected to one SPI bus, so you need multiple SSELx lines, and they
*have* to be done in software (I'm actually handling three LIS302's right
now), but, for example, the SPI port on the Logomatic is *only* connected to
the SD card -- the pins aren't broken out elsewhere -- so why not just let
the SPI block in the LPC2148 handle SSEL operation? What am I missing? I
tried this briefly, and it seemed to work fine, but I'm wondering if there's
a "feature" that I don't know about.

-Owen

I'm using the SparkFun Logomatic V2 board to read LIS302 accelerometers over SPI (using the SSP port), basing my code on the KinetaMap code (also from SparkFun). Now that I have it working (and have a reasonable understanding of SPI bus operation), I'm curious why in so many LPC214x applications using SPI in Master mode (including the Logomatic's and KinetaMap's access of the SD/MMC card), the SSEL pin is configured and driven as *GPIO*. I've confirmed that, if you configure either the SPI or SSP port's SSEL pin as SSEL, when you write data out to the interface, the peripheral handles SSEL going low during the transfer automatically, so why add the code complexity and time penalty of driving SSEL separately?

I understand that there are situations where there are multiple external devices connected to one SPI bus, so you need multiple SSELx lines, and they *have* to be done in software (I'm actually handling three LIS302's right now), but, for example, the SPI port on the Logomatic is *only* connected to the SD card -- the pins aren't broken out elsewhere -- so why not just let the SPI block in the LPC2148 handle SSEL operation? What am I missing? I tried this briefly, and it seemed to work fine, but I'm wondering if there's a "feature" that I don't know about.

-Owen