General Category > Discussion - Drivers

FT_Write returning FT_OK but BytesWritten is 0

(1/3) > >>

Liam:
Hello;

We have a project using the FTDI driver (ftd2xx.dll) that generally works for loads of customers without problems. However I recently had a customer where communication between the software and device was failing, and it turns out that the FT_Write function was returning FT_OK but the 'BytesWritten' field was returned set to 0. 

Can anyone tell me under what possible conditions this could happen? I can't find anything online or in the documentation. It looks as if a failure to write any data should return an error code, but it doesn't. It's not something I've seen before - in the past we have seen FT_Write fail with an error code of 4 (FT_IO_ERROR) and it's because the device has been unplugged.

Re-plugging the device's USB connection seems to have solved the issue for now, but it has happened a couple of times for this customer and I'd like to get to the bottom of what is causing it.

Thanks

Liam

FTDI Community:
Hello Liam,

Which driver version and IC are you using?

Has BytesWritten been initialised correctly first? This would be good practise.

You could also try FT_Purge.

What are your timeouts set to in FT_SetTimeouts? Could it be that it's timing out before there is enough time to send the data?
Remember USB is non-deterministic. There can be lots happening on a USB bus or with the OS which can cause delays.

See the D2XX Programmer's Guide for more information.

Also AN232B-04 Data Throughput, Latency & Handshaking provides some useful information and applies to all FTDI devices.

Best Regards,
FTDI Community

gabriel.au:
Hi,
  I'm not the original poster, but I'm having the same problem.  I'm using FTD2XX Library version: 00010112 with the FT232HL.  I've tried setting the timeouts to 50000 and the problem still occurs. 

My application is programming an FPGA.  I use the FTDI in FIFO mode to talk to a CPLD which reads the data from the FTDI and then writes it out to the FPGA configuration pins.  It's a custom implementation; it doesn't follow the FPGA configuration examples that FTDI provides.  The OS in my case is linux.  The latency is not important but the bytes must all arrive correctly without any data loss or corruption or else the FPGA configuration will fail.

Resetting the USB hub can clear this error condition and make the configuration pass every time.  But when the hub is in this 'bad' state, the FPGA configuration fails 2 out of 3 tries.

When the FT_Write fails, there's no error code but 0 bytes were written.  If I dump all the USB accesses from the linux kernel (https://technolinchpin.wordpress.com/2015/10/23/usb-bus-sniffers-for-linux-system/) I see a EPROTO protocol error from the bulk OUT transfer that fails.  I don't see that error when the configuration succeeds.  I tried resending the failed block and also just ignoring the failure but both still fail to configure the FPGA.  I also tried periodically checking FT_GetStatus to see if there were bytes in the queue but it always read 0.

I've also tried using the libftdi driver and I get a similar problem but it doesn't error on the write.  It still gets the EPROTO in the linux kernel and the FPGA configuration fails so I suspect that driver just ignores whatever error is happening.

This problem just showed up recently, coinciding with a new CPU model.  This design was used with an older slower CPU without problems.  I think the faster CPU might be writing too fast.  What is the flow control method for OUT data?  How is the FTDI supposed to throttle the CPU?  Does the FT232H generate USB NAKs and/or NYETs?

thanks,
Gabe

FTDI Community:
Hello, if you are using FIFO mode, please see the following Tech Note which should help:

TN_167 FTDI FIFO Basics

Flow control must be set to CTS_RTS in the application, even though these signals are not physically used. This will avoid any data loss.

Are you using Sync or Async FIFO mode?

Are you using known good hardware? Test with C232HD cables, UM232H-B, UM232H.

It's a custom implementation and uses an external hub so is difficult to support. Is the results the same when the USB hub is removed?

Best Regards,
FTDI Community

gabriel.au:
Thanks for responding.

We are using Async FIFO mode.  The hardware has been in use for years with a different CPU so the FTDI/CPLD/FPGA side is known good.
The USB "hub" is internal to the CPU SoC so it can't be removed.

I tried the CTS_RTS setting and it still failed the same way.

Navigation

[0] Message Index

[#] Next page