Q
We have been faced in our project with propositions from some experts, that in
SPI communication the risk exists that a clock flank on the SCK SPI clock is
missed (by a slave) and that we'll need to implement periodical resets of the
SPI interface (shut down, turn on) to get out of the false synchronization
caused by the missed clock flank.
This puzzles me and leads to this simple question: (I haven't found the answer
in the Hardware Reference Manual.)
Will unselecting and reselecting (over SPISS) a BF SPI slave also reset the
shift register internal index so that the next clock pulse clocks in a new
first bit in the shift register and not e.g. a last bit which would trigger the
interrupt?
Put another way: Are there always at least sixteen clock pulses from the
assertion of SPISS to the first SPI interrupt?
I always assumed that this was the case and that the short unselect pulse on
SPISS (like in Figure 10.3 on page 10-7) would act as a manner of frame sync.
Don't see how you could *not* design the system this way, but now I need an
authoritative answer, please.
A
It is possible to make a kind of framesync with /SPISS.
One condition has to be fullfilled for this: The SPI clock must run at that
time.
When you are deactivating /SPISS, the SPI-Slave stores all data in Shift
Register to the receive buffer SPI_RDBR (the SPI-Slave acts like the
Shift-Register would be full). So when you wait on the Transmit-Side until the
next full word is supposed to be sended, than activate /SPISS again and you are
synchronized again.
If you also deactivate the SPI clock, which would be the regular condition as
this is gate clocked, the SPI-Slave remains at the actual state ('he' acts like
a state machine).