2
\$\begingroup\$

This capture by a Saleae Logic Pro 8 (v 1.2.18) shows the result of transmitting (MOSI data) 0x20 0x11. Unfortunately it is interpreted and shown as 0x40 0x23. The dialog shows Saleae's SPI analyzer settings which, I believe, are correctly set for SPI Mode 1. (Both digital and analog versions of each SPI line are shown for thoroughness.)

If I change the analyzer to Mode 0 (by changing to CPHA=0, the original data shows correctly. However, the device to be written to only does Mode 1 (see 9.5.1 and 10.1.1).

enter image description here

To confirm the correct data/clock phase relationship, see this.

I am using the FTDI MPSSE output command 0x11 (see 3.3.2 here). I have tried changing several of the setup parameters (adaptive clocking on/off, three phase clock/two phase clock) with no change in behavior. This is the first two SPI bytes out after using the bad command strategy shown in all the FTDI examples to ensure command synchronization (which works as expected).

\$\endgroup\$
4
\$\begingroup\$

I got a response from FTDI technical support:

The FT2232D and FT2xxH MPSSE devices only support SPI Modes 0 and 2. Some customers have tried using 3 phase clocking, but have not been successful.

We have a new USB to SPI/I2C device – FT4222H. This chip supports all SPI CPOL/CPHA (clock polarity/clock phase) modes.

Note: “Quad SPI” in the FT4222H datasheet refers to a 4 bit wide SPI interface option, not 4 independent SPI channels.

That appears to definitively answer the question of how to do this.

We are looking at possible workarounds such as inverting the clock signal in hardware. I'll update this answer when we determine feasibility.


Edit: We got it working. It required two areas of modifications compared to a straightforward implementation.

Added a hardware inverter to the SPI_CLK signal output. This allows the clock and data to transition 180° out-of-phase preventing sampling errors.

The software is changed with adding slightly odd but careful ordering of chip select and clock transitions. At the end of a message, it does produce a tiny clock glitch, but none of our devices (Saleae analyzer and TI A2D converters) care.

The sequence to enable chip select is:

1.  SPI_CK = 1  &&  SPI_CS = 1
2.  SPI_CK = 1  &&  SPI_CS = 0
3.  SPI_CK = 0  &&  SPI_CS = 0

To disable chip select:

1.  SPI_CK = 1  && SPI_CS = 1   # causes slight glitch

The glitch is an extra (but short) clock pulse produced as the MPSSE engine finishes clocking out the data where it concludes by setting SPI_CK zero but since we hardware invert it, it appears as a one. The disable CS step then corrects this, ready for the next CS enable sequence (when it is eventually time).

\$\endgroup\$
3
\$\begingroup\$

According to this library, you need to set the clock high before enabling the slave select line, otherwise it creates a clock glitch. Your decoded data is shifted right, which is exactly the glitch this comment is describing

Hackish work around to properly support SPI mode 1. SPI1 clock idles low, but needs to be set high before sending out data to preven unintended clock glitches from the FT2232. (mpsse.c line 655)

\$\endgroup\$
  • \$\begingroup\$ I have the signals doing what I think needs to be done, but the Saleae analyzer complains with The initial (idle) state of the CLK line does not match the settings. I am not sure what to make of the situation. \$\endgroup\$ – wallyk Mar 7 '18 at 0:24

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.