FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  


Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support

New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - stijn

Pages: [1]
General Discussion / Re: Can a timeout be set on FT_purge?
« on: June 29, 2020, 05:26:02 PM »
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?

General Discussion / Can a timeout be set on FT_purge?
« 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!

Pages: [1]