pyftdi icon indicating copy to clipboard operation
pyftdi copied to clipboard

The last bit of every byte is missing when reading data

Open idanuliel opened this issue 2 years ago • 4 comments

Using pyftdi version 0.50.0 with FT4232HL FTDI chip reading registers from SC18IS600 (spi to i2c chip) I'm missing the last bit when reading its internal registers and from reading data from slave i2c chips.

Using spi mode 3 and 100 kHz clock.

My code:

from pyftdi.spi import SpiController

spi = SpiController(cs_count=5,)

# Configure the first interface (IF/2) of the FTDI device as a SPI master
spi.configure('ftdi://ftdi:ft4232h:/2')

# Get a port to a SPI slave w/ /CS on B*BUS and SPI mode 3 @ 100 kHz
slave = spi.get_port(cs=2, freq=100e3, mode=3)

rtrn = slave.exchange([0x21, 0x00, 0x00], 1)

print(rtrn.hex())

rtrn value is 0x0E but the written value is 0x0F (register control GPIO I verify is HIGH after write).

Tested with a scope on the FTDI SPI lines I can verify the 0x0F:

scope with SPI decode: scrprint (7) Scope screenshot

LSB zoom Picture1 Green: CS, Yellow: clock, Purple: MOSI, Orange: MISO

Contacted NXP support and from the image below they say everything is good with the command and structure sent to the chip and the return values are good.

Issue is not replicated with different chip on the same bus with the same mode.

SC18IS600 datasheet

How can I solve this?

idanuliel avatar Sep 22 '22 08:09 idanuliel

Be sure to read https://eblot.github.io/pyftdi/api/spi.html#spi-modes-1-3 : FTDI devices do not really support SPI mode 1&3.

You may try other modes: sometimes the slave device accepts another mode.

eblot avatar Sep 22 '22 13:09 eblot

Slave device is not responding to SPI modes 0-2. Any known workarounds that can solve this ?

idanuliel avatar Sep 28 '22 07:09 idanuliel

@idanuliel "Any workarounds".... It will be slower, but you can always bit/bang to mimic nearly any protocol manually. It is what we had to do before we had SPI hardware in our microprocessors. Hope this helps.

Hagtronics avatar Nov 06 '22 15:11 Hagtronics

The only workaround I could think of at the moment is to replace the FTDI device with an emulated device such as the Sipeed dongle which emulates the MPSEE protocol and reports itself as an FTDI device. As the Sipeed is using a RISC-V microcontroller and no dedicated HW, you could implement whatever you need. However, this is not an effort-less project :-)

eblot avatar Jan 28 '23 13:01 eblot