Re: SPI for the 1000th time... :-(
> hello everyone
> I was reading through most of the SPI related topics but its still
> very confusing to me... :-/
> I have two LPC2368/78 with one being the SPI master and one being the
> SPI slave.
> the SPI slave LPC always gets a "slave abort" AND a "read overrun". I
> guess its related to the SSEL discussion and I really don't know what
> to do with that pin...
You can't just ignore the SSEL pin - it frames the transactions. In
effect it tells the slave when a message starts and when it ends.
Read again the section of the user manual that discusses SPI and
particularly those references to SSEL.
Also note under slave operation that you need to put the transmit data
in the SPI data register BEFORE the master asks for it. At the next
layer up, the master usually sends some kind of command byte and
perhaps an address byte and expects to receive valid data when it
clocks out a 3d dummy byte. There may not be a lot of time between
receiving the address byte and having to send the result to determine
just what needs to be in the SPI data register and getting it there.
The two ends may need to agree on a delay between the master clocking
the address (or command) and then clocking in the result.
Unlike I2C, the slave can't delay the clocking.
"If the Px.y/SSEL/... pin is assigned the SSEL function in Pin Function
Select Register 0, the SSEL signal must always be inactive when the SPI
controller is a master."
however, on page 371 there's written:
"When a device is set up to be a slave, its I/Os are
only active when it is selected by the SSEL signal being active."
the way I understand those 2 statements, they exclude each other... :-/
my guess would be that the first one means "if a master is idle, the
SSEL signal must be inactive" - but there's that "always" which is
> From: l...
> [mailto:l...]On Behalf
> Of d.holzwarth
> Sent: Wednesday, October 24, 2007 12:02 AM
> To: l...
> Subject: [lpc2000] Re: SPI for the 1000th time... :-(
> well, what's confusing me is the statement on page 373 of the
> "If the Px.y/SSEL/... pin is assigned the SSEL function in
> Pin Function
> Select Register 0, the SSEL signal must always be inactive
> when the SPI
> controller is a master."
> however, on page 371 there's written:
> "When a device is set up to be a slave, its I/Os are
> only active when it is selected by the SSEL signal being active."
> the way I understand those 2 statements, they exclude each
> other... :-/
> my guess would be that the first one means "if a master is idle, the
> SSEL signal must be inactive" - but there's that "always" which is
> kinda confusing...
As I understand this from past discussions, the SSEL is not used
when in master mode, but must be tied to an inactive state for
the SPI to work at all. In some older variants of the LPC series,
the SSEL can not be used as GPIO, and it must be tied to the
inactive state, and another GPIO pin used as the CS output.
Probably the SSEL in master mode could be used in a multi-master
system to detect collisions, or to at least avoid any contention
if another device tried to use the bus (but I don't have anything
to back this up, it is just a hunch).