FAQ: How do I reconcile Blackfin SPI serial clock phase control (CPHA) settings with potentially conflicting hardware/software slave select modes, when both these attributes are managed by the same control bit?

Document created by CraigG on Sep 19, 2011Last modified by CraigG on Aug 28, 2013
Version 1Show Document
  • View in full screen mode

By definition, the clock phase control bit is used to manage whether data is sampled on the leading or trailing clock edge.  But this bit is also used to manage whether the slave select output pin is driven by hardware or software.  These two attributes are sometimes in contention.  (Note that in hardware slave select mode, the select line is toggled between bytes which can cause an unintentional slave device reset.)


Most Blackfin SPI hardware implementations provide both serial clock phase (CPHA) and serial clock polarity (CPOL) control bits within the SPI_CTL control register. These two serial clock control bits configure the SPI protocol to use one of four industry standard SPI clocking modes to suite external slave device timing requirements.


But the serial clock phase (CPHA) control bit also controls programming of the slave select pin to be generated either: automatically, i.e., using the SPI hardware slave select mode (where CPHA=0); or, in the software mode by application software (where CPHA=1).  Note that in the software mode, the application will directly manipulate an explicit flag pin around each SPI transfer.  So in addition to controlling the clock phase, the CPHA bit also controls selection of the hardware/software slave select mode.


Because the hardware slave select mode (CPHA=0) may (depending on protocol speed) deassert and reassert the slave device select line between each byte of the transfer, some slave devices may interpret this transition as a slave reset request which may interfere with a block transfer.


In cases where the slave device requires use of CPHA=0 on the Blackfin SPI master-mode controller (implying use of the hardware slave select mode), the slave select “reset” between bytes can be avoided by combining the needed hardware select (CPHA=0) mode with a software-driven slave select technique. This solution requires the associated slave select function be disabled in the function enable register (FER) for the port and pin in question and that the application software take responsibility for driving the slave select pin as if CPHA=1 (software slave select mode) were active.  In short, the application programs the slave select pin “manually” (via the flag service) by manipulating the select before and after each transaction (DMA or otherwise): assert the select just prior to the SPI enablement and deselect it at the transaction completion or DMA interrupt.


TAR-45231 describes a feature request to support this workaround in the SPI Device Driver.