Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length.

[allenhuffman]

We have been using these chips for years along with a Windows host program. We start getting FTDI errors when we are doing PWM pulsing of an RF signal in our product. In my system logs, I start seeing read errors from one of our boards, and then all the rest (as if the FTDI driver itself is messed up; inspecting the I2C line with a Saleae logic analyzer shows it is not locked):

Code: [Select]

20230724 092734.302 FTDI Read 100 (Exc): Status 1011 (FT4222_FAILED_TO_READ_DEVICE).
Restarting our Windows host resumes, so I expect we should be able to recover in software. I've tried doing Bus resets, Master resets and other things, and can make it continue, but there is usually a hang long enough that it shuts down our boards (for safety, they shut down if they don't hear from Master Control Program ;-).

Does anyone have any tips on what can be done with an I2C read or write returns one of these errors? One it happens, our system is basically a brick until I restart the Windows host program.

Thanks, much.

[allenhuffman]

I posted another topic specifically about detecting FT_SetTimeouts() timeouts in a write/read, but wanted to update this one.

On the system I am working with, I have seen it successfully write/read over 41 million messages (7-112 bytes in length) with zero errors. It's field proven and works well. When we introduced some RF (or possibly power line noise, unclear), the whole communications layer will start having problems. Often, when one of these READ errors is seen, the comms are done until the program is restarted. I am testing just Closing and Re-opening the FTDI connection to see if that is enough. BUT, if a slave device got stuck while clock stretching, I suppose that wouldn't help. FTDI did add a "bus reset" function in one of the recent DLL versions and this sends the clock pulses to try to un-stick a slave, so I have put that in to.

I hope there is a best practices list somewhere rather than "throw stuff at the wall and see if it sticks" like I am doing.

[FTDI Community]

Hello,

When using our products in electrically noisy environments, you can try in section 5.1 Adjusting the Reset Pipe Retry Count of AN_107 Advanced Driver Options.

You can also edit the registry, opposed from editing the INF files which breaks driver signing.

Note that registry entry may need to be created:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FTDIBUS\Parameters\RetryResetCount
The default value is 50 so you can try increasing to see if it has an effect.
This can stop USB disconnects in electrically noisy environments.

The above might be something additional to try to see if it helps, otherwise modify your hardware to cope in electrically noisy environments might be the best way forward and check if you are using a USB certified and shielded cable.

Best Regards,
FTDI Community