-
Notifications
You must be signed in to change notification settings - Fork 215
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
SPI reads all 1's (0xFF's) off of FT2232H #383
Comments
Things you can do:
|
We are having a similar problem, using similar code, although we must admit we have not yet probed the device. We are using an FT2232 Mini Module to try and communicate with two transceiver devices. from pyftdi.ftdi import Ftdi
from pyftdi.spi import SpiController, SpiPort
# devices used for configuration
device_a = "ftdi://ftdi:2232/1"
device_b = "ftdi://ftdi:2232/2"
# Documentation for device states 20 MHz is max
# 20 MHz will result in 25% error of 15 MHz for max, so just using 15 MHz
max_freq = 15e6
freq = 10e6
spi_a_cntrl = SpiController()
spi_b_cntrl = SpiController()
spi_a_cntrl.configure(device_a, frequency=max_freq, debug=True)
spi_b_cntrl.configure(device_b, frequency=max_freq, debug=True)
receiver_a = spi_a_cntrl.get_port(cs=0)
receiver_a.set_frequency(freq)
receiver_a.set_mode(0)
receiver_b = spi_b_cntrl.get_port(cs=0)
receiver_b.set_frequency(freq)
receiver_b.set_mode(0)
cmd = b'\x00\x00\x00\x00\x00\x00' # 6 bytes
spi_1_response = receiver_a.exchange(cmd, duplex=True)
spi_2_response = receiver_b.exchange(cmd, duplex=True)
print(spi_1_response)
print(spi_2_response)
I know this comment does not provide new or helpful information to the original post, but thought we should share as the issue is very similar to our own. Could this potentially be a bug with pyftdi? |
Thanks for the help in brainstorming ideas. It turns out that we needed to initialize the second MPSSE interface in order for the receive buffer to start working. Adding this code (and then doing nothing with the second interface afterward) solved our problem. # Open up the 2nd MPSSE interface on the FTDI chip.
# We've found experimentally that the 1st MPSSE interface will not
# work until the 2nd is initialized.
# We won't do anything with this interface after this.
b = Ftdi.create_from_url("ftdi://ftdi:2232h/2")
b.open_mpsse_from_url("ftdi://ftdi:2232h/2", 0xFFFB, 0xFFFB, 1e4, 127) |
Hello, as we are still having issues, I am curious as to why this solved your problem. Why did you go the route of using |
Unfortunately, we just stumbled across the "solution". After we initially couldn't get pyftdi to work, we reimplemented the protocol in C using the FT2X libraries from FTDI directly. When we tested that, we were getting the same issues (everything else works, but we read all FFs). So we were pretty sure this wasn't an issue with pyftdi (we didn't look under the hood, but assumed they use the same or similar drivers from FTDI), but instead an FTDI initialization issue. After scouring all the FTDI literature and examples, we were just methodically measuring and initializing as much of the part as we could when we stumbled upon this in the C version. Then we back-ported it to pyftdi, and it worked there as well. There is no significance to the methods that we used to initialize it. I believe that it will work with the initialization method you use, but we haven't tested that version yet to say it conclusively. We ended up making no modifications to the original pyftdi code above except adding those lines in my later post. We needed the GPIO for some discrete signals for reset, standby, SPI control selection, etc, so they had to stay. Luckily we found this, since we were 1-2 days away from throwing away the FTDI part and instead driving the chip directly from an FGPA, which would have been a bit more of a hassle in writing our own drivers - not terrible on the SPI protocol side, but a bit of a chore to manage all the initialization, buffering, comms with a PC, etc. As to your problem - I don't have too much more insight, except noting that it could be a problem on the transceiver side. Did you hook up a logic analyzer to see if your system under test is driving the MISO line? If you have a pull-up and the chip is not driving the line, then you would see all 1's, which would be the correct behavior from the FTDI device, and you'd have to start debugging why the SUT is not responding. |
Also, thanks again @eblot for your thoughtful debug steps! Great library! |
Thanks @nickhdc33 Re-opening this issue for now, as I do not understand why this workaround is needed... |
Following the same steps as @nickhdc33, I was unable to get a response (other than all F's), so I am not sure it is a universal workaround/fix. |
BTW, what are the reference(s) of the SPI slave devices? |
With the FTDI2232 Mini Module, we are using a 10 MHz reference clock for both the slave devices. Is this what you are asking? |
Not really, the type/kind of SPI device you're trying to communicate with: FTDI being the master/host, what are the (slave) devices? |
A couple of transceiver modules, found here. |
It turns out that the device we linked does not have wiring as specified in the pyftdi documentation. We only realized this once the manufacturer finally gave us schematics for the device. To get around this, we had to use GPIO pins to control which slave device to communicate with, and we were finally able to get status back. |
Thanks, I can confirm this also fixed the issue of receiving all 1's for me. I was also using a FT2232H and probing the SPI lines, the MISO line was always actively pulled high by the FTDI device. Using this code to initialize the second interface, I can now also read data from the MISO line. |
Hi there, we are interfacing the FT2232H with a slave device using pyftdi, using SPI for communication. We can write to the device, and it responds correctly on the logic analyzer. However, the return value from pyftdi is always 0xFFFF, as though it is not reading the MISO. We confirmed that MISO is wired to the correct pin on ADBUS.
The read sequence is <read byte 1> <read byte 2>. We have tried simultaneous read/write as well as separate write/read cycles, reading extra bytes at the end, trying to extend the CS cycle, etc, but always read 1's back, despite correct sequences on the logic analyzer. However, if we turn on loopback, we can see the bytes we're writing out in the read buffer.
Attached is a screen capture of a typical read sequence of register 0:
<0x00> (read command) <0x00> (register 0). <reading MSB> <reading LSB>
<writing cmd> <writing register> <0x00> (MSB) <0x49> (LSB)
But we still see 0xFFFF when pyftdi returns.
Any thoughts on what could be going wrong, or other ways to debug why this is happening? Thanks!
Code example:
The text was updated successfully, but these errors were encountered: