2
\$\begingroup\$

If one is using SPI to interface two microcontrollers that may spend much of their time sleeping, and if the SPI slave port is supposed to wake up its controller when data is received, that would suggest that the SPI clock wire should not be synchronized to the latter microcontroller's clock. If indeed the clock and processor's clock are asynchronous, that would seem to imply that data written by the microcontroller to its slave port can neither be double-synchronized to the SPI clock [since it must be available to the SPI master on the next SPI clock cycle], nor can it be guaranteed to occur at any moment other than an SPI clock edge [since the SPI slave has no idea when that will be]. The SPI port on e.g. the Freescale KL25 series specifies that if a data underrun occurs, the port will output the previous data, and the next data written by the controller will be transmitted after the repeated data byte. Putting all those conditions together would sound like a recipe for potential metastability issues if the master starts trying to read a byte just as the slave micro is writing it.

I don't know that it would be possible to design an SPI slave port which could guarantee that it would always either repeat a data byte and then put a new byte after it, or else transmit the new byte directly. What can or do SPI slave port designs do to minimize such issues, and what can software in the master or slave do to ensure that they don't cause trouble?

\$\endgroup\$
  • \$\begingroup\$ I'm not entirely sure what exactly you think the problem might be, but one thing that struck me is that I would expect a slave SPI to become active with the slave select signal and not the clock signal, and according to one of the datasheets for the KL25 it must precede the first clock signal edge by at least 1 t_periph. Does that make any difference to your thought experiment? \$\endgroup\$ – fm_andreas Apr 18 '13 at 18:37
  • \$\begingroup\$ Is this about DFF metastability between the SPI clock domain and the microcontroller's internal clock? \$\endgroup\$ – pjc50 Apr 18 '13 at 18:47
  • \$\begingroup\$ @pjc50: Yeah. When in slave mode, the SPI peripheral operates completely independently of the processor's clock which need not even be running. If the "read data ready" bit feeding the processor is double-synchronized (and there's no reason to think it wouldn't be) and the processor doesn't try to read any data when there's none ready, there should be no problem. if /SS were required to strobe between bytes, and writes would be ignored unless they precede both /SS and the rising clock edge, that could constitute "double synchronization", but data may be written... \$\endgroup\$ – supercat Apr 18 '13 at 18:56
  • \$\begingroup\$ ...at any point prior to the first clock edge of a new byte. Presently my plan is to simply have the master wait long enough between bytes that the slave's data should get written long before that first clock pulse arrives, but I don't like relying upon such things any more than I have to. \$\endgroup\$ – supercat Apr 18 '13 at 18:58
  • \$\begingroup\$ I would be confident in relying on it; everything between the outside of the processor and the inside will be suitably synchronised. Otherwise it would be extremely vulnerable to e.g. induced transients on signal lines. \$\endgroup\$ – pjc50 Apr 18 '13 at 20:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.