LPC175x using SPI and SSP0 at the same time

lpcware · ‎06-15-2016

Content originally posted in LPCWare by graynomad on Mon Sep 19 02:47:30 MST 2011
Hi,

I want to use the LPC175x and need all three "SPI" ports, namely SPI, SSP0 and SSP1.

However I just spotted this in the manual

Quote:
Remark: SSP0 is intended to be used as an alternative for the SPI interface, which is included as a legacy peripheral. Only one of these peripherals can be used at the any one time.

Surely this can't mean one OR the other. They have separate regs and pins and are shown separately in the block diagram.

Please tell me I can use all three ports independently.

______
Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by graynomad on Wed Sep 21 09:23:32 MST 2011
Yep so I see, then I can't explain it.

______
Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Wed Sep 21 08:30:09 MST 2011

Quote:

... Microwire mode?

Don't think so:

// Set DSS data to 8-bit, Frame format SPI, CPOL = 0, CPHA = 0, and SCR is 12
 LPC_SSP0->CR0 = 0x0B07;

// Set DSS data to 8-bit, Frame format SPI, CPOL = 0, CPHA = 0, and SCR is 12
 LPC_SSP1->CR0 = 0x0B07;

lpcware · ‎06-15-2016

Content originally posted in LPCWare by graynomad on Wed Sep 21 08:21:07 MST 2011
Hmm, I'll see your scope pic and raise you a logic analyser pic.

[IMG]http://www.robgray.com/temp/emul8or-protocol.png[/IMG]

That clearly shows no start bits. They are definitely there on your Xpresso so I can only assume that it's an LPC quirk as I said before. (My trace is of two AVRs talking to each other).

Notice on my pic the middle trace comes in low and goes out high, it just depends on the last bit of the last byte.

I'll have to track down a spec but even the LPC data sheet doesn't show that start bit...hang on, the Microwire format goes tri-state between bytes and it does seem to have a start bit.

Given the slow rise time on that signal maybe that's the story, were you in Microwire mode?

Either way it's not something I can depend on.

I just spotted this in the DS for CPOL=0,CPHA=1 mode.

Quote:
For continuous back-to-back transfers, the SSEL pin is held LOW between successive data words and termination is the same as that of the single word transfer.

So that seems to be two modes that allow SSEL to stay low effectively forever so I think I'm OK. Trouble is I'm designing a PCB based on "thinking it's OK" :(

Maybe I should buy an Xpresso and find out for sure.

______
Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Wed Sep 21 07:47:27 MST 2011
Asked my scope :eek:

http://www.flickr.com/photos/58892165@N08/

That's a LPCXpresso1114 sending 0x55, 0xAA, 0xFF, 0xFF from ssp0 to ssp1 :)

[COLOR=Blue]SCK = BLUE[/COLOR]
[COLOR=Red]MOSI = RED[/COLOR]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by graynomad on Wed Sep 21 06:45:22 MST 2011

Quote:
always starting with a negative edge before frame is transmitted

Now it's my turn for a :eek:

With every SPI I've seen the MOSI/MOSI lines are only valid on the appropriate clock edge of which there are 8 per byte. In between bytes they just sit at whatever level the last bit was, or if the system has multiple slaves they go tri-state.

Maybe this is an LPC quirk but it sure ain't standard to have a "start" bit before every byte. Short of doing what we're talking about I can't any point in having one as you (normally) have SS and always have SCK to sync on there's no need for a start bit.

______
Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Wed Sep 21 06:23:04 MST 2011
Don't know which MOSI you are trying to read, my 2MHz standard MOSI is always starting with a negative edge before frame is transmitted :eek:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by graynomad on Wed Sep 21 05:51:51 MST 2011
I'm reasonably happy to generate an ASEL, it's more hands-on than I'd like as the processor has to deal with stuff for every frame, but if that's what you gotta do then that's what you gotta do.

But how can I get a reliable falling edge off MOSI, it could be transmitting 0xFFs or indeed any pattern.

______
Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Wed Sep 21 00:35:24 MST 2011
An easy approach could be generating SSEL signal by detecting MOSI:

#1 Use a working SPI SLAVE to read MOSI with original SSEL. Don't connect MISO, of course. If this slave is receiving correct data:

#2 Disconnect SSEL. Connect MOSI to EINT. Read this EINT (falling edge) and switch a simple GPIO output low for a few µs. This output is our new
(artificial) SSEL signal (ASEL :) ) and is now connected to sniffer SSEL. Now your sniffer is reading MOSI :eek:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by graynomad on Mon Sep 19 16:51:49 MST 2011

Quote:
Are you just trying to read 2 MOSI signals

Essentially that's the case, although is a MOSI and a MISO with one master and (potentially) no SSEL. Even when there is an SSEL as I mentioned I've never seen a device that will pulse it between bytes, normally it's asserted, X bytes are transferred, then it's de-asserted.

Quote:
That's not too difficult

In the AVR world I come from I would agree, I'm just trying to come to grips with the LPC architecture, there's a lot to digest.

The more I get into it the more I like it but CPOL and CPHA seem to change the mode of operation and I find that quite bizarre. With them at 00, 01 or 10 you seem to need the SSEL pulse between frames. At 11 you don't.

What has that got to do with polarity and phase?

So anyway all I want to do is monitor two lines for storage and protocol analysis.

My understanding is that if I use CPOL = 1 and CPHA = 1 I get the non-SSEL-pulse mode I want, but bad luck if I want to change the clock polarity as that puts me back into a SSEL-pulse-required mode.

If that's the case I need an external XOR gate to (optionally) invert the clock signal.

Anyway forget my rant, I'm a newb at LPCs and I know on other forums I contribute to that I often have to tell someone to drop their preconceived ideas about [B]how[/B] to do something and just get them to say [B]what[/B] they want to do.

So if you can tell me how to monitor the two lines that would be great.

______
Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Mon Sep 19 09:10:53 MST 2011
I still don't understand what you are trying to do :confused:

Are you just trying to read 2 MOSI signals from 2 masters (without any own ssp function) ?

That's not too difficult, so i think i'm wrong :eek:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by graynomad on Mon Sep 19 09:09:01 MST 2011
Sorry, crossed posts there.

This is a protocol sniffing app and it's likely that there is no master SSEL, often people just communicate between two chips with no SSEL because there's only one slave. Also many (most?) chips don't require this pulsing per byte. This is the first time I've encountered it.

The master could be a processor and the slave an ADC for example.

Admittedly not having a SSEL is asking for the two to get out of sync with no easy way to get back in.

Anyway I think I have found the answer as per the above post.

______
Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by graynomad on Mon Sep 19 09:01:37 MST 2011
I think I may have answered this, it seems that the CPOL and CPHA bits do a lot more that control phase and polarity, they also control the SPI mode used.

If I'm correct with CPOL = 1 and CPHA = 1 the SSEL line can be permanently asserted with bytes (or words, whatever length is set) being written to and read from the FIFO contiguously.

So as long as I keep up and clear the FIFO I should be right.

Is that correct?

______
Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Mon Sep 19 08:44:52 MST 2011

Quote: graynomad
It seems that SSEL has to be pulsed for every byte.

Yes (if your master is sending 8 bits) :)

Quote: graynomad
If that's the case is there a clever work around...

A work around for what? Receiving more than one slave with one SSP?

A simple approach could be to read master SSEL's with interrupts, detect which master is active and then switch (own) slave SSEL via own GPIO. But that's of course not working if both masters are working at the same time :mad:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by graynomad on Mon Sep 19 08:13:22 MST 2011
Further to this if you're still there Zero.

As mentioned I want to simply record data on the MISO and MOSI lines and for this I plan to use two SSPs in slave mode.

On AVRs the SPI port is little more than a fancy shift register that is enabled by the SS signal, so for monitoring all you do is tie SS low.

Am I correct in saying that this won't work with the LPC? It seems that SSEL has to be pulsed for every byte.

If that's the case is there a clever work around, maybe count 8 CLKs with a timer and use a MAT pin to pulse the SSEL (except that would tie up two counters for such a simple function).

Thinks...as both SSPs are running in parallel one timer and one MAT would handle both SSPs I would think.

That still loses a timer though, is there a better way?

______
Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by graynomad on Mon Sep 19 03:06:19 MST 2011
No, all slaves I'm afraid. It's a protocol sniffer so I need two ports to monitor the line MOSI and MOSI, they don't transmit but I need the two inputs.

The third one is used in a conventional manner but for another function.

I may have to think about the third one and use another technique there.

Thanks for the reply.

______
Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Mon Sep 19 02:58:57 MST 2011

Quote: graynomad
Please tell me I can use all three ports independently

As described in your manual you can use just 2 of them :eek:

Don't know what you are trying, but if you want to use them as master a simple solution is to select different slaves via CS
( Example: SPI LCD and SPI Touchscreen Controller are working at the same SPI controller) :)