FTDI Community
General Category => General Discussion => Topic started by: stijn on June 26, 2020, 12:31:03 PM
-
We have a device attached to an FT232. FTDI driver version 2.12.28. Using D2XX with communication parameters:
- FT_SetUSBParameters 2048, 2048
- FT_SetBaudRate 921600
- FT_SetDataCharacteristics 8, 2, 0
- FT_SetFlowControl 0, 0, 0
- FT_SetLatencyTimer 2
We have been using the same code for over 10 years in production, over a hundred deployments. Recently on one device we were having a problem with communication stalling: we call FT_write and it does not return, for minutes, until unplugging the cable. After plugging back in things work normally again. Reason yet unknown; given the age of both the device and the FTDI chip (about 7 years we guess) we assume wear in a cap's value or so, hard to tell and not worth yet investigating.
The stalling is problematic though, the software should just report an error and retry the connection. So we added a call to FT_SetTimeouts configuring 10000mSec timeout. This approach works so now FT_write returns after 10 seconds when the problem occurs.
However FT_purge still has the same problem: it stalls and just doesn't return until unplugging the cable.
I couldn't find a documented remedy for that. Is there a way to setup a timeout for FT_purge, or another software solution which makes it not stall?
Thanks in advance!
-
Hello,
It sounds like some sort of hardware issue has occurred as you have suggested.
FT_SetTimeouts sets the read and write timeouts for the device. It won't have any effect on the other functions.
You could test out some of the other available commands to see if they would help reconnect with the failing hardware:
FT_ResetDevice
FT_ResetPort
FT_CyclePort
FT_Rescan
FT_Reload
FT_CyclePort could be the best option, this is like a physical unplug/replug.
Also check the API function return codes which might give you more information on the failure mode.
For example, FT_IO_ERROR usually points to an issue with the hardware.
Best Regards,
FTDI Community
-
Thanks for the reply!
We're already using FT_CyclePort and in the event of e.g. FT_IO_ERROR (which is indeed what we mostly get) after FT_Read or FT_Write we use it to succesfully reconnect.
However we can only do so when there's effectively an error, which isn't the case if FT_Purge never returns..
So is it correct that there's no way to keep FT_Purge from blocking? That would mean we cannot really use it, as it stalls the software in case something goes wrong; well, I guess unless we use a separate thread to measure how long it's been running and then call FT_CyclePort from the other thread but I'm not sure the FTDI functions are threadsafe for use like that?
-
Hello,
Yes FT_IO_ERROR does point to a hardware issue.
D2XX functions are thread safe.
Best Regards,
FTDI Community