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 - FTDI Community

Pages: [1] 2 3 ... 37

Yes that is correct, they can be programmed to pull low during USB suspend.
Unfortunately however they cannot be programmed to pull low when neither RD or WR are asserted.

Best Regards,
FTDI Community

Discussion - Hardware / Re: UM245R baud rate
« on: Today at 12:41:26 PM »

Thank you for the update, I'm glad it is working at lower baud rates now.
As mentioned the baud rate setting shouldn't have any affect on the FIFO interface, but if this issue reappears please let us know so we can investigate further.

Best Regards,
FTDI Community


Yes that is correct when used in Input Mode, the input pins are pulled to VCCIO via internal 200kΩ resistors, so they will gently pull high unless driven by some external logic. These pins can be programmed to gently pull low during USB suspend (PWREN# = “1”) by setting an option in the internal EEPROM. But unfortunately you cannot disable the pull up entirely.

Best Regards,
FTDI Community


This setting does in fact alter the USB descriptors presented to the USB host on enumeration, altering the host that the device is either Bus or Self powered. The USB spec requires that a device correctly identify itself to the USB host, so please ensure you have selected the correct setting for your configuration.

Forgetting to update the setting to reflect if you are using a bus powered or self powered design may result in enumeration issues for the device.

Best Regards,
FTDI Community

Discussion - Hardware / Re: UM245R - EPROM bus current limit setting
« on: January 19, 2021, 11:17:57 AM »

The MaxPower Descriptor defines the maximum power that may be drawn by the peripheral from the USB host. The USB host will read this value during enumeration to determine if it can provide the desired current draw the device is requesting. If for example you change this setting to 500mA and the USB host cannot provide this much power to the device, then the device will not enumerate.

The MaxPower Descriptor relates to Bus Powered devices, when using a Self Powered design you can set this value to 0mA.

Best Regards,
FTDI Community

Discussion - Hardware / Re: UM245R baud rate
« on: January 19, 2021, 11:07:06 AM »

The FT245R of which the UM245R is based upon provides a parallel FIFO interface as a COM port on the host machine, however as this IC implements a FIFO interface the baud rate settings are ignored.

It is curious that with your chosen terminal emulator the behaviour seems to vary with baud rate setting, what terminal are you using? And have you tried any other terminal emulators?

Best Regards,
FTDI Community


Although the FT4222H uses a data byte of 8 bits, most SPI peripherals can still use this so long as you keep CS asserted as they still see this as one transfer.

It looks like this particular device has some kind of timeout if the clock sits low for more than 28ms but beyond that was there any other reason why it could not accept multiple bytes so long as CS is kept asserted?

MPSSE (for example the FT232H) would have been another option but can only do SPI modes 0 and 2 and it looks like this ADC may need mode 1.

Best Regards, FTDI Community


Unfortunately we don't have any experience with impact or Quartus (Altera) package.
These packages require specific hardware to program FPGAs as mentioned in an external forum that you have created:


If no-one else on this FTDI community website can help, it may be worthwhile contacting Altera.
Another community user already replied to one of your posts on this:


If you are trying to clone FPGA programmers that’s not something we can support.

The FT232H uses our standard VCP Drivers or D2XX Drivers.

Best Regards,
FTDI Community

Discussion - Software / Re: FT4222 Python Interface
« on: January 13, 2021, 04:33:19 PM »

The LibFT4222 API return code 1000 is FT4222_DEVICE_NOT_SUPPORTED.

Which revision of silicon are you using?

Which mode are you using the device in? Which hardware are you using?

Which version of the D2xx driver are you using and which version of LibFT4222?
Note the following versions for the 64bit dlls and libs:

.\CDM v2.12.28 WHQL Certified\amd64

This issue has never been reported before.
Have you tried the 32bit and 64bit dlls with the standard examples provided with LibFT4222? This would take the python aspect out of the equation, if you say that it’s a problem with our dll:


Unfortunately we have no support for Python, but you can check out the following information with respect to the D2xx driver (not specifically LibFT4222):

It is possible implement the D2XX driver in python scripts.

The following imports are required:

import os
import sys
import ctypes

And the library can be loaded in the following manner:

class D2XXTest(object):
    def __init__(self):
        #Load driver binaries
        if sys.platform.startswith('linux'):
            self.d2xx = ctypes.cdll.LoadLibrary("libftd2xx.so")
        elif sys.platform.startswith('darwin'):
            self.d2xx = ctypes.cdll.LoadLibrary("libftd2xx.1.1.0.dylib")
            self.d2xx = ctypes.windll.LoadLibrary("ftd2xx")
        print 'D2XX library loaded OK'

Also see some other Third Party Implementations:

ctypes Wrapper for D2XX:

I found one for LibFT4222 also:

There also may be other FTDI Community users with Python knowledge and LibFT4222 who may be able to help you further.

Best Regards,
FTDI Community

Discussion - Drivers / Re: VCP driver on macOS 11
« on: January 12, 2021, 02:06:10 PM »

Unfortunately there hasn't been any updates from our driver team as of yet, but I will be sure to post any updates when I receive them.

Best Regards,
FTDI Community


The following function should help:

USBH_device_get_descriptor(hDev, USB_DESCRIPTOR_TYPE_REPORT, index, offset, buffer)

USB_DESCRIPTOR_TYPE_REPORT comes from ft900_usb_hid.h.

Best Regards,
FTDI Community


There's a function USBH_device_get_descriptor() in usbh.c which allows you to get a descriptor.
It will get a device, config or report descriptor.

The type of descriptor to get is defined in ft900_usb.h:

    @name USB Descriptor Types
    @brief Table 9-5. Descriptor Types.
    Used for wValue high byte in 9.4.3 Get Descriptor, 9.4.8 Set Descriptor.

You'll have to decode the report descriptor yourself.

In the file ft900_usb_hid.h all the constituent parts of a report descriptor are defined. These can be decoded when looking through the report descriptor. So, it is a case of all the possible values already typed into the header file.

Even better there are loads of online ones to check the results against.

Best Regards,
FTDI Community

Discussion - Hardware / Re: FT230XS
« on: January 06, 2021, 04:47:15 PM »

Can you please email your local support team and we can look into this issue further?


Then you can post any resolution here to help other community users.

Best Regards,
FTDI Community


If there are 3 endpoints to monitor then the USBH_transfer_async is good way to do it.

You pass in a unique ID (one for each endpoint) and a callback function (the parameters are in the ft900_usbh.h header file).

typedef int8_t (*USBH_callback)(uint32_t id, int8_t status, size_t len, uint8_t *buffer);

There are no examples but it is the same as USBH_transfer except that you get your buffer filled and your callback called during the USBH_Process call. The ID will be used to differentiate the endpoints.

Best Regards,
FTDI Community

Discussion - Software / Re: USB3.0 communication error on FT601
« on: January 06, 2021, 04:43:54 PM »

You have already emailed our support team on this issue.

Feel free to post any resolution here to help other FTDI Community users.

Best Regards,
FTDI Community

Pages: [1] 2 3 ... 37