FTDI Community
General Category => Discussion - Software => Topic started by: piezontm on August 21, 2019, 06:05:24 PM
-
I am having same problem as https://www.ftdicommunity.com/index.php?topic=250.msg804#msg804 (https://www.ftdicommunity.com/index.php?topic=250.msg804#msg804) with the 0.4 version of the MPSSE library. However, I have found that the fast read/write option runs without the FT_IO_ERROR but there is still a long timeout on the final read operation before returns. Also, the data returned is not correct, yet a Scope/Protocol Analyzer shows the correct data on the bus.
As the original post, I too compiled the 0.4 MPSSE lib against the 1.4.8 D2xx driver. I did modify the MPSSE lib to:
- change the timeout from 5s to 2s (for capture purposes)
- added timestamps to DBG to add a timestamp
Test Use Case
My test use case is slightly different:
Start, hD0 [ h68 | WR ], h01, h00, Stop
Start, hD0 [ h68 | WR ], h02, Stop
Start, hD1 [ h68 | RD ], hAD NAK, Stop
Start, hD0 [ h68 | WR ], h03, Stop
Start, hD1 [ h68 | RD ], h28 NAK, Stop
Basically:
WR 01 00
WR 02
RD 1 byte (expect 0xAD)
WR 03
RD 1 byte (expect 0x28)
Normal Read/Write
I connected a Scope/Protocol Analyzer for the "normal" read and write mode (non-fast) and see nothing obvious ("ftdiNormalWR_ioError_filtered.pcapng"). The attached image "ftdiNormalWR_ioError.png" is the only portion of the data transfer seen on the bus. One strange part of the trace is the duration of the stop operation as well as there are no errors seen. The other is why the transactions stop.
My DBG trace was similar to the original post from https://www.ftdicommunity.com/index.php?topic=250.msg804#msg804 (https://www.ftdicommunity.com/index.php?topic=250.msg804#msg804). See the attached log "ftdiNormalWR_ioError.log". NOTE: The timestamps are on the far left in msec.
Fast Read/Write
When running the above use case using the fast read/write option the signals look fine and the Scope/Protocol Analyzer and [filtered] USB Wireshark ("fdtiFastWR_timeoutBadData_filtered.pcapng") shows the completion of all reads and writes to be approx 39.59ms with the correct I2C protocol. As you can see in the DBG trace ("fdtiFastWR_timeoutBadData.log") the final byte READ results in two timeouts: one by the byte read, and one for the NACK read--my code is compiled with a 2s timeout, not 5s. However, the Wireshark and Scope/Protocol Analyzer indicates the complete I2C transactions were fast and complete. It would indicate the D2xx driver is causing this timeout. Also, as I previously mentioned, the data read/returned in the Wireshark and the Scope/Protocol Analyzer is 0x28 ("ftdi_fastWR_getsReadTimeouts_LastDataRead.png"), yet the lib MPSSE does not appear to be filling in the rx buffer at all. The buffer contains the same data prior to the call to the read routine.
Some other things I have tried
- Powered USB hub
- Connected directly to my laptop
- Other I2C masters can communicate without a problem to my slave device
- Only tried 100KHz, my slave only operates in this mode
- Tried a couple USB cables
- Only tested Ubuntu 64-bit. I have NOT tried a 32-bit OS or Windows.
- Attempted uncommenting the SEND_IMMEDIATE for the fast read but this did not return the data any further
- Modified the Mid_SetClock() for the FT232H to match the various specs for calculating the clock divider. The routine does not appear to match the formulas in AN_108, etc. This did not appear to fix/alter the problem, only the clock pulse/width.
- In the MPSSE lib for the fast read routine there is ifdef'ed code for various proposals/alternatives. I have tried all the other proposals and they did not work.
- Modified the I2C_FastRead() to check the FT_GetQueueStatus until the number of expected bytes are read, then do the FT_Channel_Read. This did nothing. The timeout still occurred and the data portion was not returned.
Questions
- Why does the "normal" read/write and the fast read/write APIs not yield the same results? One gives an IO error, the other nearly works but gives some incorrect data.
- Are the Mid_SetClock calculations correct? Shouldn't it be "((12M/clock)/2)-1" when the clock divide is enabled and "((60M/clock)/2)-1" when the clock divide is disabled? This correction matches the AN_108 among other Application Notes FTDI has published.
- Why is the final read timing out but does return data? All indications indicate a problem in the D2xx based on the I2C bus and Wireshark traces.
- Why does the fast read not fill in the rx buffer?
- Is it possible to get the latest lib MPSSE source to compile and try? The link from the other posts does not work.
Setup
FTDI device: Adafruit FT232H
OS: Linux, Ubuntu 16.04 (64 bit)
Driver: libftd2xx-x86_64-1.4.8
Lib: LibMPSSE-I2C Version 0.4 20-May-2014
Sample Calls
ftStatus = I2C_DeviceRead( dcb->hnd,
addr,
nRead,
rBuf,
&bytesTransfered,
#ifdef MPSSE_FAST_I2C_READ_API
(I2C_TRANSFER_OPTIONS_START_BIT |
I2C_TRANSFER_OPTIONS_STOP_BIT |
I2C_TRANSFER_OPTIONS_FAST_TRANSFER_BYTES) );
#else
(I2C_TRANSFER_OPTIONS_START_BIT |
I2C_TRANSFER_OPTIONS_STOP_BIT) );
#endif
ftStatus = I2C_DeviceWrite( dcb->hnd,
addr,
nWrite,
(uint8_t*)wBuf,
&bytesTransfered,
#ifdef MPSSE_FAST_I2C_WRITE_API
(I2C_TRANSFER_OPTIONS_START_BIT |
I2C_TRANSFER_OPTIONS_STOP_BIT |
I2C_TRANSFER_OPTIONS_FAST_TRANSFER_BYTES) );
#else
(I2C_TRANSFER_OPTIONS_START_BIT |
I2C_TRANSFER_OPTIONS_STOP_BIT) );
#endif
Due to the attachment limitations I tarred the files up:
- ftdiNormalWR_ioError.log = DBG output for the normal write/read test. Timestamps are on the far left in msec.
- ftdiNormalWR_ioError.png = Image of normal write/read test from Scope/Protocol Analyzer.
- ftdiNormalWR_ioError_filtered.pcapng = Wireshark trace for the normal write/read use case. Filtered to only show frames > 66 bytes to reduce the size of the file.
- ftdiFastWR_getsReadTimeouts.log = DBG output for the fast write/read test. Timestamps are on the far left in msec. NOTE: My timeouts were changed to 2 seconds, so that is what you see in the log.
- ftdiFastWR_getsReadTimeouts_filtered.pcapng = Wireshark trace for the fast write/read use case. Filtered to only show frames > 66 bytes to reduce the size of the file.
- ftdiNormalWR_getsReadTimeouts_LastDataRead.png = Image of fast write/read test from Scope/Protocol Analyzer showing ONLY the last read transaction 0x28, but the MPSSE lib returns 0xAD.
- ftdiNormalWR_getsReadTimeouts_Duration.png = Image of fast write/read test from Scope/Protocol Analyzer showing overall I2C transaction time, yet the test takes > 4 seconds due to some read timeouts in the D2xx driver.
-
Hi,
We will have a look through your details provided but here is a link to the latest beta and source code:
LibMPSSE (ftp://u45902898-ide:Ftd1$erv@ftp.ftdichip.com/CES/LibMPSSE/0.6Plus_Beta_Source.zip)
Best Regards, FTDI Community
-
Thanks so much for quick response with a link for the beta source code.
I have integrated the beta code and found the following:
- When compiled with `INFRA_DEBUG_ENABLE=1` and `!__BORLANDC__` you get compiler errors with the changes made to fix the warnings for the "unused status" warnings. I added:
#define FN_EXIT_VOID DBG(MSG_DEBUG,"Exiting function\n"); to ftdi_infra.h. Then I modified the places that had no status to fix the new errors. The files effected were: ftdi_infra.c, ftdi_mid.c.
- Fixed a reference to "byte" in ftdi_mid: Mid_CheckMPSSEAvailable(). I changed this to "uint8" and it worked fine. This could be specific to my compiler, not sure.
As for the testing results:
- For the normal read/write APIs I get the same results as other post (https://www.ftdicommunity.com/index.php?topic=250.msg804#msg804) when using the beta source (i.e. no change from v4, I still get the "FT_IO_ERROR").
- For the fast read/write APIs things improved slightly. I still get the timeout which is the biggest problem. On the plus side, I actually get the data I expected from the final read transaction (0x28).
I have attached my logs of the DBG for these two use cases. Please note the timeouts in the trace is compiled for 2s, not 5s.
-
I was wondering if there were any improvements or other things I can try?