SSP: How does SSP Slave detect end of packet?

[lpcware]

Content originally posted in LPCWare by capiman on Sat Mar 14 12:12:02 MST 2015
Hello,

I am currently thinking about a general problem with SSP Slave, perhaps I have overseen something?

I am implementing a SSP slave (SPI Format). SSP Master is lower CS and transmits some data to me.
I get an interrupt, when the receive FIFO has data and I can read them. So far so good.
Now when SSP Master is setting CS back to high, how do I recognize that the packet is complete?
Or take the case, the SSP Master is setting CS back to high and back to low to start a new packet,
how do I recognize that a new packet has started? Is there any bit which signals that packet is complete or a new one is started?
(Especially also interesting with variable length data per packet.)

Or do I need to sample the CS again and again (or at a certain position) to recognize it is not more low?

Best regards,

Martin

[lpcware]

Content originally posted in LPCWare by anniegilson35 on Sat Mar 21 00:28:08 MST 2015
I read every part of it and this is one of the best searching for me. Thanks much
please vist

[lpcware]

Content originally posted in LPCWare by capiman on Sun Mar 15 08:53:24 MST 2015

---

Quote: R2D2
And what's the problem here?

---

I assume that I (could, will) get the GPIO pin interrupt before I get the last bytes from SSP peripheral.

[lpcware]

Content originally posted in LPCWare by R2D2 on Sun Mar 15 05:24:52 MST 2015

---

Quote: capiman
If CS goes high after I get all data, no problem.
But if CS goes high before I got the last byte, I say: Data is missing and discard all previous data.
It could have been sent on SSP, but not yet delivered to my application.

---

And what's the problem here?

You are transmitting 8 bytes, so your master is generating CS via GPIO, right?

If you want to confirm a correct reception, read a status byte back. Of course then you have to use a command (byte) and variable data length...

[lpcware]

Content originally posted in LPCWare by capiman on Sun Mar 15 04:31:50 MST 2015
Many thanks to you both for your answers.
Unfortunately I am only building the SSP slave, the master is fixed and cannot be changed.
I must build the SSP slave, so it can be used by different masters, but not at the same time.
But behaviour is similar like in Serial flashes, I think nothing special for my device.
E.g. have a look into

http://www.adestotech.com/wp-content/uploads/DS-AT25SF041_044.pdf

page 6. There is e.g. the following sentence (in chapter 5):

"In addition, if the CS pin is deasserted before complete opcode and address information is sent to the device, then no operation will be performed and the device will simply return to the idle state and wait for the next operation."

Situation is displayed in figure 4-1 on same page:
Look at right end of CS and SCK in the figure. There is my problem. Last clock cycle versus CS going high.
If CS goes high after I get all data, no problem.
But if CS goes high before I got the last byte, I say: Data is missing and discard all previous data.
It could have been sent on SSP, but not yet delivered to my application.

I think it is tCSLH on this datasheet, which could make me problems, can be found on page 33 and page 36.
Attention: I don't use the AT25SF041, I just want to ack similar like this one, just as a "simple" SSP slave.

Best regards,

Martin

[lpcware]

Content originally posted in LPCWare by R2D2 on Sun Mar 15 04:10:42 MST 2015
I'm not sure what you are trying to do in detail  :)

Sounds like data transfer with a simple protocol (command and data frames)?

Are master and slave your own devices?

An easy approach would be to add an additional GPIO to detect data / command frames (DATA / COMMAND)?

Or just use a frame bit (and use 9 bit frames) to detect a command frame (with command & length of following data)?

Or use >8 bit frames with included counter (12bit: 8bit data, 4bit counter to transfer 16 byte data blocks)?

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Sun Mar 15 03:21:37 MST 2015
Another thought.

Design a SSP slave via SGPIO.
[Isn't there an AppNote?]

Note I have no idea as to specifics, but I'd guess that you could build in
an end of frame type interrupt based on CS rising.

Regards, Mike

[lpcware]

Content originally posted in LPCWare by capiman on Sun Mar 15 01:00:39 MST 2015
Hi Mike,

many thanks for your reply. I just want to show the following example:
Take the case the packet shall be (always) 8 bytes long.
(fixed length or length in first byte or so)

Case 1: CS low, 8 bytes transmitted, CS high.
Case 2: CS low, 4 bytes transmitted, CS high, "some" time later, CS low, 4 remaining bytes transmitted, CS high.

First case is valid, second case is invalid, because I get 2 packets which are too short.

For case 2:
Ok, I refuse the first one (first 4 bytes) as too short, but then I get the second one and try again to decode it with random outcome, because it is the second part of a packet. Instead of the length I get user data. Ok, normally you have some kind of checksum, so you just discard both too small packets.

Regarding the pin interrupt:
Yes I already considered this, but had hoped there is a way just with the SSP peripheral to tell me this kind of info.

With pin interrupt, there is (perhaps) the following problem:
Take the case I configured the pin interrupt triggering by rising edge on CS.
So I receive the data via SSP, they are filled into FIFO and at some time CS goes high.
Now I get my interrupt and mark this received packet as completely received.
But I think there is now a race condition between CS going high (and pin interrupt) and SSP peripheral giving me received data.
I don't know when (how much delayed) the SSP peripheral is giving me the received data.
Workaround could be that the pin interrupt is starting a short timer, and when timer times out, then it is really done.
But there are some timing assumptions, where I am really not happy with.
Perhaps some SSP master sends CS sometimes a bit faster and then it is not working any more.
(Or I am too pessimistic here?)

I hoped I have overseen some easy way to do this...
I hoped the SSP is checking CS. It is already using it for enabling/disabling MISO (in case of multiple slaves),
so why not giving a status flag "CS went high" (which means packet end).

Best regards,

Martin

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Sat Mar 14 18:06:10 MST 2015
I suspect that a slave knows the length and format of packets based on the opcode (the first byte).

On the other hand, if you are developing some sort of proprietry protocol of you own, I would add
start/end packet markers. Just as I would for a serial (RS232) protocol.
[Google device link escape if you need to allow the packet delimiters as legal in the data payload part of a packet.]

Some developers favour the inclusion of a length field.


On the third hand (sic) if the chip select in is GPIO, look at pin interrupts in the UM GPIO chapter.

Regards, Mike