Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The last bit of every byte is missing when reading data #318

Open
idanuliel opened this issue Sep 22, 2022 · 4 comments
Open

The last bit of every byte is missing when reading data #318

idanuliel opened this issue Sep 22, 2022 · 4 comments

Comments

@idanuliel
Copy link

idanuliel commented Sep 22, 2022

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?

@eblot
Copy link
Owner

eblot commented Sep 22, 2022

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.

@idanuliel
Copy link
Author

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

@Hagtronics
Copy link

@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.

@eblot
Copy link
Owner

eblot commented Jan 28, 2023

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 :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants