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

Pages: 1 ... 8 9 [10]
 on: July 21, 2021, 12:29:47 PM 
Started by Josiah - Last Post by j.pflaum
Hello Josiah,

I might have the same problem and cannot resolve it.
Did you find a solution and may you share it, please?

Thank you and best regards,

 on: July 20, 2021, 12:00:36 PM 
Started by FTDI Community Admin - Last Post by cioma
Is there a document describing differences between the old FT232H/FT2232H/FT4232H and the new chips?
E.g. is the availability of Type-C/PD3.0 Controller is the only difference with all the rest being exactly the same?

 on: July 08, 2021, 04:51:58 PM 
Started by j.pflaum - Last Post by FTDI Community

We have a recovery procedure in this application note below (see section 3.2). Could you advise if this procedure helps to recover from the error?
AN_412_FT600_FT601 USB Bridge chips Integration

Best Regards, FTDI Community

 on: July 06, 2021, 03:05:51 PM 
Started by jimmy.bai - Last Post by FTDI Community

Thank you for your question, I will look into reproducing this behaviour.

Could you just clarify what hardware configuration for the FT4222 you are using? is it the UMFT4222EV-D?

Best Regards,
FTDI Community

 on: July 06, 2021, 02:51:58 AM 
Started by jimmy.bai - Last Post by jimmy.bai
       I am using FT4222H linux driver on my module and I find sometime the FT4222 driver will run into DEAD status in linux setup, even for get-version.c example code. The reproducing step is as follows:

1.     Connect the module which carries FT4222H chip with PC.
2.     Download libft4222-linux- from  www.ftdichip.com
3.     Put the zip file into ubuntu 18.04 and unzip it, the ubuntu run in virtual box 6.1.
3.     run "sudo ./install4222.sh"
4.     run "cc get-version.c -lft4222 -Wl,-rpath,/usr/local/lib"
5.     run "sudo ./a.out" and the output result is :
        Device 0: ‘FT4222 A’
        Chip version: 0x42220400, FT4222 version: 0x0104042C
Of course, the output result is OK. But, if we run “sudo ./a.out” continuously for several times, the code will run into dead status(the terminal has no any output and can't type an key), as shown below,(General we meet this condition after running 4-5 times, sometimes running 7~8 times.)

I also try the windows example code for FT4222 driver in window setup(which is visual studio code), it works fine and no issue occurs.
Do you know how to resolve this issue? Thanks.

 on: June 28, 2021, 03:09:15 PM 
Started by willycat - Last Post by FTDI Community

Thanks for the update! I'm glad you have gotten up and running.

Yes, the slave address should be written on the I2C bus for every vos_dev_read() call issued so the data packet conforms to the I2C standard.

Best Regards,
FTDI Community

 on: June 28, 2021, 01:37:53 PM 
Started by willycat - Last Post by willycat
OK, i found the mistake !

i incorrectly configure the pins for the i2c interface: they need to bi bidirectional.

// i2c interface
vos_iomux_define_bidi(14, IOMUX_IN_GPIO_PORT_B_2, IOMUX_OUT_GPIO_PORT_B_2);
vos_iomux_define_bidi(15, IOMUX_IN_GPIO_PORT_B_3, IOMUX_OUT_GPIO_PORT_B_3);

Now, it works.

It is normal for the vos_dev_read() function to begin with a write operation to update the address pointer of the i2c slave.


 on: June 27, 2021, 10:09:41 PM 
Started by willycat - Last Post by willycat

thank you for your reply. My confusion came from the "i2c.h" file which talk about pin number starting at one.

Things go better now as there is activity on clock and data signals, but it doesn't work yet. Look at this source code:

   #define VOS_DEV_I2C 5

   // Configure direction of port B
    vos_gpio_set_port_mode(GPIO_PORT_B, 0x0c);

    // i2c interface
    vos_iomux_define_output(14, IOMUX_OUT_GPIO_PORT_B_2);
    vos_iomux_define_output(15, IOMUX_OUT_GPIO_PORT_B_3);

    // Needed declarations
    i2c_ioctl_cb_t i2c_iocb;
    i2c_port_t i2c_port;
    unsigned char i2cerr;

    char i2c_Buf[8];
    uint16 i2c_Nbr;


    // Define the I2C pins
    i2c_port.clkPort = I2C_PORT_B;
    i2c_port.clkPortNo = 3; // Pin 15
    i2c_port.dataPort = I2C_PORT_B;
    i2c_port.dataPortNo = 2; // Pin 14
    i2cerr = i2c_device_init(VOS_DEV_I2C, &i2c_port);

    // Open I2C Interface
    hI2C = vos_dev_open(VOS_DEV_I2C);

    // Set RTC address
    i2c_iocb.ioctl_code = VOS_IOCTL_I2C_SET_DEVICE_ADDRESS;
    i2c_iocb.data = 0x68;
    i2cerr = vos_dev_ioctl(hI2C, &i2c_iocb);

    // Set I2C options
    i2c_iocb.ioctl_code = VOS_IOCTL_I2C_SET_OPTIONS;
    i2c_iocb.data = I2C_OPTIONS_READ_ADDRESS;
    i2cerr = vos_dev_ioctl(hI2C, &i2c_iocb);

    // Set address to read
    i2c_iocb.ioctl_code = VOS_IOCTL_I2C_SET_RDWR_ADDRESS;
    i2c_iocb.data = 0x00;
    i2cerr = vos_dev_ioctl(hI2C, &i2c_iocb);

    // Read one byte form Addess 0x00
    i2cerr = vos_dev_read(hI2C, i2c_Buf, 1, &i2c_Nbr);

First: All vos_dev_ioctl() calls return 1. From what i saw in the disassembly code window, this is normal and each call successfully did its job. But according to the manual, the vos_dev_ioctl() function should return 0 in case of success.

Second: The vos_dev_read() fail and return 2. With my scope, i know that the first byte (which contain the start condition,the chip address, the direction bit) is sent to the RTC which response with an ACK. But that is all i see and the R/W bit is set to 0 instead of 1 for a read.

I tried to find where the problem could be in the assembler code, but your debugger doesn't allow to put breakpoint in the assembler code which makes the debug process almost impossible.

Maybe, i do something wrong, but i don't know what.

In attachment, you will find the result of the vos_dev_read() function.

Can you help me again ?


 on: June 23, 2021, 11:25:48 AM 
Started by Vijay - Last Post by FTDI Community

Could you advise what you see on the MOSI/MISO/CS/SCK lines when you run the code? If you have a logic analyser or a PC-based scope could you capture the lines to see if you are getting the expected waveforms.

Which SPI mode does your SPI peripheral use? Note that MPSSE only supports mode 0 and 2,

Note that you should also check the sizeTransfered value after a read or write to ensure your requested bytes were all transferred.

What was the error which you saw, did you get the expected number of bytes back but they were the wrong values?

One further thing to also check is that you have opened the right channel, depending which channel A or B your SPI device is connected to.

Best Regards, FTDI Community

 on: June 22, 2021, 03:27:34 PM 
Started by _adam_ - Last Post by FTDI Community

Yes, you are correct, you can use LibFT260 or access the device using raw HID class commands but an application must be running on a PC to control the FT260.

If you want a device to act like a keyboard HID class device per say, then see FT90x or FT93x from our sister company Bridgetek which is a programmable MCU.

Take a look at AN 360 FT9xx Example Applications and the USBD Example HID example. This particular example sends fixed characters, but you could modify the code to bridge to the UART side.

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

Pages: 1 ... 8 9 [10]