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

Pages: [1] 2 3 ... 10
 1 
 on: January 24, 2020, 04:33:38 PM 
Started by Liam - Last Post by FTDI Community
Hello,

Which driver version is installed? The latest is 2.12.28.

Can you please test with our standard hardware to rule out any issues with OEM hardware?

See our Development Modules:

FT-X Breakout Modules
FT-X Development Modules

It looks like you are also into contact with our support team via email. Please continue to work with your local support team member and feel free to post any resolution here to help other users.

Best Regards,
FTDI Community

 2 
 on: January 22, 2020, 10:01:26 PM 
Started by Liam - Last Post by liquidair
@FTDI Community,

I'm using the FTD2XX_NET_v1.1.0 wrapper from you guys and custom hardware, an AVR microcontroller. There's multiple i2c IO expanders in this design that all read and write i2c perfectly so it's not an i2c thing, and I can do everything else from the computer to the chip just fine. It's only Write (maybe read too but I haven't gotten that far).

Yes, I've referred to AN_255; I've literally read every app note of yours i can find multiple times but nothing works. I've even attempted to use the FTD2XX with a C++ console app and that won't work either.

What I think is happening is that Visual Studio updated the standard libraries with VS2019 and it broke the driver. My C++ console code, which is literally code copied out of the D2XX programmer's guide, will not compile when using the static driver (yes, I did follow along with TN_153 for this)...all errors come from inside the driver (which I can't access). When substituting the dll version, the code compiles but will not connect to the device. I contacted tech support a while back and he had no issues with the same code in VS2010 or 2017 i believe, but did have the same issues with VS2019.

 3 
 on: January 22, 2020, 09:36:46 PM 
Started by Liam - Last Post by liquidair
Thank you gabriel.au! I'm definitely not having the same issue based on your response!


 4 
 on: January 21, 2020, 10:13:15 PM 
Started by Liam - Last Post by gabriel.au
Sorry, I ended up resolving this but never posted the final results.

It turned out to be a problem with the hub IC.  It was built into the CPU SOC and it would randomly lower the output voltage of the D+/D- signals sometimes so that the FTDI couldn't discern the signal.  We never got the vendor to admit why.  We eventually got a work around in the bios by changing the hub from xHCI to EHCI Controller.  The hub had USB 3.0 ports which we weren't using and I think they were confusing the 2.0 ports by trying to negotiate sometimes?  Not sure.  By using the EHCI controller it forced the USB 3.0 ports off and the problem went away.

 5 
 on: January 21, 2020, 04:30:47 PM 
Started by Liam - Last Post by FTDI Community
Hello liquidair,

The original posts seem slightly different to your issue.

Which C# wrapper are you using? Are you using custom hardware?
This is not a common issue with FT201X I2C slave.

Have you referred to AN_255 USB to I2C Example Using the FT232H and FT201x Devices for examples on how to use FT201X?
The code can be downloaded here.

The I2C routines involve using standard D2xx functions to send buffers of commands and read bytes back from the FT232H. The routines can therefore be ported over to any other operating systems which support the D2xx drivers. Likewise, the routines can be used in other languages such as Visual Basic and C# by modifying them to use the correct syntax for the required language.

Best Regards,
FTDI Community

 6 
 on: January 17, 2020, 05:58:36 PM 
Started by Liam - Last Post by liquidair
Any update on this? I too am having a similar problem with the FT201X where the C# version of FT_Write will return FT_OK but nothing is written. In my case, BytesWritten gives the correct value, however. When you try to read this data via i2c the chip returns 0, as does using the 'Read Data Available" command. Been stuck for a month now.

 7 
 on: January 16, 2020, 12:06:35 AM 
Started by jefflongo - Last Post by jefflongo
EDIT: after some more investigating it seems that the CBUS pins are in fact not pulled up to VCCIO even when disconnected from the circuit. Adding an external stronger pull-up seems to solve my problem.

 8 
 on: January 15, 2020, 11:02:29 AM 
Started by bridgethegap - Last Post by FTDI Community
Hello Jason,

V2DIP1 gives access to USB Port2 but "UART to FT232 Host Sample Application ROM" is built to access USB Port 1.

You could consider editing the code and rebuilding for USB Port 2, or purchasing V2DIP2 which gives access to both ports.
However, consider the information below.

Vinculum-II is a very mature products and has been superseded by FT9xx.

Hosting FT232 devices with these older Vinculum-II products can be unreliable.
It takes a lot of the MCUs resources to run the FT232 device code (eg FT232Uart) so there can be performance issues.
I wouldn’t recommend using this product for this application because you will most likely run into problems.

The best solution we have is our FT90x MCU.

There are lots of other examples available:

AN_360 FT9xx Example Applications
FT90x Software Examples
FT9xx Software Examples

Take a look at FT90x UART to FT232 Host Bridge, there is already a software example which can host FTDI devices.
A video has been created which demonstrates this:

https://youtu.be/_vwOKFaOcJI

There are significant benefits of FT90x:

-Eclipse based IDE
-Source code for API drivers is provided
-Significant performance improvement
-Actively in development by R&D
-Improved documentation and software examples

We provide FT9xx Development Modules and a free FT9xx Toolchain for custom application development.

Best Regards,
FTDI Community

 9 
 on: January 15, 2020, 03:35:57 AM 
Started by jefflongo - Last Post by jefflongo
Hello all,

I am using FT232R's CBUS3 pin in I/O mode (with VCCIO=3.3v) to control the reset pin of an STM32 microcontroller (which has an integrated 45kohm pull-up to vdd = 3.3v). When I am not actively driving the reset pin, I set CBUS3 to input mode. The FT232R datasheet specifies that input pins have an internal 200kohm pull-up to VCCIO. However, I notice that when I set CBUS3 to input mode, the reset node voltage drops from 3.3v to 2.6v. After disconnecting CBUS3 from the circuit, the reset node voltage is back to 3.3v, and CBUS3 is in fact not pulled-up when floating in input mode. Furthermore, if CBUS3 was even just tri-stated, I would expect the microcontroller's embedded reset pull-up to pull the voltage to 3.3v.

I have ensured the EEPROM is programmed to set CBUS3 to I/O mode and that the pull-down on USB suspend is not checked. My application works despite the reset node voltage dropping, but this is still less than desirable. Does anybody have any idea why CBUS3 is causing the voltage to drop?

Best,
Jeff

 10 
 on: January 10, 2020, 03:13:39 PM 
Started by bridgethegap - Last Post by bridgethegap
All,
I recently purchased the Vinculum II chip to bridge UART to a FT232HL/Q (pid 6014) device.  I downloaded the precompiled firmware from the project "UART to FT232 Host Sample Application ROM" on the FTDI web page.  I was expecting this application to work out of the box, but I'm having issues on the V2DIP1 development board.  Other than a modification in the source code to adjust for the default pid, 6001 vs 6014, are there any other changes I should need out of the box?  I'm running a 256000 baud rate and have made the appropriate baud rate changes to the code as well.  I'm scoping the usb data lines to the FT232HL chip and do not see any activity when I initiate communications.  Using the debugger, the firmware fails in ft232_host_attach() either trying to find the FT232 device or performing the attach.  Does anyone have any ideas? 

Thanks in advance. 

Jason

Pages: [1] 2 3 ... 10