FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

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 - allenhuffman

Pages: [1] 2 3 4
1
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.

2
It is my understanding that FT_SetTimeouts() will cause a Read/Write to timeout. How can you tell if this happened? I did not see an obvious return code.

Code: [Select]
ftStatus = FT_SetTimeouts (ftHandle, 5000, 5000);

...

ft4222Status = FT4222_I2CMaster_Read (ftHandle, address, buffer, bufferSize, &sizeTransferred);

In this I2C example, suppose the slave device invoked clock stretching and held it longer than 5000ms. I would expect the Read call to return due to the SetTimeouts.

We sometimes see unexpected FT4222_FAILED_TO_READ_DEVICE errors, so I added code to print any time "bufferSize" and "sizeTransferred" do not match (and did the same in the Master_Write. I am not seeing those print, but I do see the program hang for 5 seconds from time to time, which makes me think it's being stuck in I/O then timing out.

Thanks, much. I am working on a project that uses FTDI I2C to communicate between a host PC and almost 30 boards using a write/read protocol. While it's been proven very solid (I've personally tested it with over 41 million messages with 0 errors), if/when a line glitch does happen, I want to make the master code robust.

3
My second question still stands:

    Is there an API that I can use to ensure that the previous transmission finished?

I have been down this rabbit hole. There is not. You just know the data has been handed out to the FTDI driver.

This is a problem, because there is a get status call that should tell you if it is busy, but due to a hardware issue in the FTDI chip, if you call that while data transfer is in progress, it can corrupt that data.

4
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.

5
1.4.5 has taken care of the compiler errors. I still have no idea how I was using 1.4.4 fine for two months before it suddenly "broke" when I tried to make a 32-bit DLL.

6
Hello,

You can also reference the latest version of ftd2xx.h in the latest 2.12.36.4 driver files.

Best Regards,
FTDI Community

E-mail support pointed me to this, and the file contained inside (50K versus 101K) does appear to be in a valid format for use with GCC, etc.

7
Hello,

It depends if you are building a static or dynamic application.

.lib is a static library which is linked into an .exe at compile time. Only the .lib is included in the folder.
.dll is a dynamic library that is loaded at runtime. That includes a .lib for the symbols.

Fantastic -- I did not know a static library was provided. Thanks!

I see only one ftd2xx.lib - what DLL does it use?

Quote
•   D2XX Interface
ftd2xx.h
  Dynamic library
    ftd2xx.lib (32-bit)
    ftd2xx.lib (64-bit)

8
I just learned there is a LibFT4222-v1.4.5.zip out, so I was trying to use it. There are two header files included:

  • LibFT4222-v1.4.5\imports\ftd2xx\ftd2xx.h
  • LibFT4222-v1.4.5.zip\LibFT4222-v1.4.5\imports\LibFT4222\inc\LibFT4222.h

My IDE could open the second file opens just fine, but the first one is rejected as being a binary file ("Cannot open binary files as text files"). Using a hex editor, I can see that the ftd2xx.h file does appear to be non-ASCII. It has a zero byte every other character, so I am guessing it was saved out as something like unicode (whatever format uses two bytes per character, I guess).

Compilers may or may not have an issue with that (I do not know what the current C standard says regarding file formats). The editor I am using will not open it. (And even saving it as a .txt or copy/pasting in to another editor and saving retains the 0 -- I guess it's a standard file format Windows supports).

Just a heads-up on this. I have reported it to FTDI, and I am going to either write a quick script to convert the file, or find some tool to do it for me.

Cheers...

9
I have only been building for 64-bit, but recently was told to create a 32-bit as well. During the process of updating from 1.4.4 to the 1.4.5 zip, I noticed there are duplicate lib files with the same name, but different file sizes:

LibFT4222-v1.4.5.zip\LibFT4222-v1.4.5\imports\LibFT4222\dll\amd64 -- 3 KB

LibFT4222-v1.4.5.zip\LibFT4222-v1.4.5\imports\LibFT4222\lib\amd64 -- 743 KB

In our existing project, the files needed were collected together, but I am not sure which one I should use now.


10
I found that there is a 1.4.5 linked here:

https://ftdichip.com/software-examples/ft4222h-software-examples/

I had a hard time finding it this time -- ended up using a search engine. I'm not sure how to get to it directly on the site.

11
We are using a package numbered 1.4.4 (LibFT4222-v1.4.4.zip), which was the latest the last time I checked.

I will see if there is something newer posted.

Please note -- I was building just fine the past two months, and only when I tried to make a "new" project (creating a 32-bit and 64-bit DLL, instead of just a 64-bit DLL) did I start having these issues. I even made a brand new project, pulling in my .c files and trying to replicate the settings -- same warnings. I expect it's something simple, that was accidentally working in the project I made two months ago.


12
Dependency Walker shows that LibFT4222(-64).dll has MSVCR100.DLL as a dependency, and I see function matches in that DLL, so I am guessing that is what it is looking for. It finds the DLL, but how does it know the functions exist? I thought a .lib was required, like for the FTDI DLLs. (I am an embedded programmer, with no Windows experience beyond the past four years maintaining an existing product.)

13
Using a DLL dependency walker tool, which I really do not understand how to use, I found some of these unresolved items in:

MSVCR1200.DLL (_purecall, __CppThrowException)

When I used a different walker yesterday, I found them when I clicked on MSVCP100.DLL (VCP versus VCR? I feel like I'm back in the 80s working at the video store.)

In my original project, I never had to do anything except add my sources, tell it to build a DLL, and drag in to .lib files and have the DLL there. I expect something else was making it work - I just have no idea why it stopped working.

Funny enough, I have posted on the LabWindows forum before about MSVCP100.DLL and MSVCR100.DLL. They were required to run out program (using FTDI) and are not part of Windows 10 LTSC. We had to find the MS download that provides them so it could be included with our installer.

14
I created a DLL for handling our I2C communications protocol. It requires the LibFT4222-64.dll from FTDI. I am using the LabWindows/CVI 2017 compiler.

Everything has been working fine the past few months, but I was requested to make a 32-bit version of the DLL as well. I only changed a few options in the compiler, and now it won't link.

I even made a new project, brought in my source code and the .lib files, and it does the same. I'm not sure what changed.

Do any of these symbols look familiar? Is this something the FTDI DLL is needing? If I don't have it included, it complains about FT_xxx calls. As soon as I add the .libs, then it goes to these:

Build Status (z.prj - Release64)
 Link z.dll
  error: Undefined symbol '??0exception@std@@QEAA@AEBV01@@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '??2@YAPEAX_K@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '??3@YAXPEAX@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '??_7type_info@@6B@' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '??_E?$clone_impl@U?$error_info_injector@Vlock_error@boost@@@exception_detail@boost@@@exception_detail@boost@@UEAAPEAXI@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '??_E?$clone_impl@U?$error_info_injector@Vthread_resource_error@boost@@@exception_detail@boost@@@exception_detail@boost@@UEAAPEAXI@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '??_E?$error_info_injector@Vlock_error@boost@@@exception_detail@boost@@UEAAPEAXI@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '??_E?$error_info_injector@Vthread_resource_error@boost@@@exception_detail@boost@@UEAAPEAXI@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '??_ERingQueue@@UEAAPEAXI@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '??_ERxBuffer@@UEAAPEAXI@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '??_Ebad_alloc@std@@UEAAPEAXI@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '??_Eclone_base@exception_detail@boost@@UEAAPEAXI@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '??_Elock_error@boost@@UEAAPEAXI@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '??_Eruntime_error@std@@UEAAPEAXI@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '??_Esystem_error@system@boost@@UEAAPEAXI@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '??_Ethread_exception@boost@@UEAAPEAXI@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '??_Ethread_resource_error@boost@@UEAAPEAXI@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '?generic_category@system@boost@@YAAEBVerror_category@12@XZ' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '?system_category@system@boost@@YAAEBVerror_category@12@XZ' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '?what@exception@std@@UEBAPEBDXZ' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '_CxxThrowException' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '__CxxFrameHandler3' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '__imp_??0exception@std@@QEAA@AEBQEBD@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '__imp_??0exception@std@@QEAA@AEBV01@@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '__imp_??1_Container_base12@std@@QEAA@XZ' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '__imp_??1exception@std@@UEAA@XZ' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '__imp_?_Xlength_error@std@@YAXPEBD@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '__imp_?_Xout_of_range@std@@YAXPEBD@Z' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '__imp_?what@exception@std@@UEBAPEBDXZ' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
  error: Undefined symbol '_purecall' referenced in "c:\path\msvc64\LibFT4222-64.lib". 
Build failed.

15
Since the bug in the FTDI I2C chip presents using FT4222_I2CMaster_GetStatus() after a write (unless you can wait long enough to know the write has completed), I came up with a workaround.

We blindly write our our message (without knowing if anything saw it and ACK'd it), then we go to read our special protocol.

We read the first two bytes (a start code, and number of data bytes) like this:

Code: [Select]
// Read two bytes (Start Code, Number of Data Bytes).
ft4222Status = FT4222_I2CMaster_ReadEx (ftHandle, deviceAddress, START, buffer, 2, &sizeTransferred);

Initially, I thought we might be able to use GetStatus() hear and see if the READ was ACK'd, but it will return a BUS_BUSY due to the ReadEx being in the middle (no STOP bit yet). At least that's what it looks like -- always BUS_BUSY until I do the second ReadEx.

I do a check like this:

Code: [Select]
// Fake it. Reads from non-responding devices will return FFs.
if ((buffer[0] == 0xff) && (buffer[1] == 0xff))
{
    // Nothing responded, or other issue.
}

...BUT, this means I never got to the second half of the ReadEx that completes it, with the STOP:

Code: [Select]
ft4222Status = FT4222_I2CMaster_ReadEx (ftHandle, deviceAddress, STOP, &buffer[2], messageSize-2, &sizeTransferred);
/code]

How can I just send the "STOP"? I tried this (ReadEx with 0 bytes) and that doesn't do it:

[code]// Fake it. Reads from non-responding devices will return FFs.
if ((buffer[0] == 0xff) && (buffer[1] == 0xff))
{
    // Nothing responded, or other issue.
    FT4222_I2CMaster_ReadEx (ftHandle, deviceAddress, STOP, buffer, 0, &sizeTransferred);
}

Looking at the I2C line in my Saleae analyzer, I see no STOP bit, though the next write/read is still able to happen.

How can I send a STOP without reading data? Is that possible?

Pages: [1] 2 3 4