Hello,

The extra bytes may be due to lack of biasing on the RS485 transceiver. If you could email into support1@ftdichip.com we can share the RS485 biasing schematic that will be able to help you.

Best Regards
FTDI Community 

Hi everyone,

I have a problem like I mention in title shortly. I designed a board to communicate between pc and a device which use RS485. I can communicate but every time receive a data it comes with a FE or FF byte as prefix. I'm using FT2232HQ with ADM3485EARZ-REEL7 on my board. Then I used USB-COM485-PLUS2 and I compared the waveform of the two converters. Even though the waveforms are same, I did not receive any extra byte while using USB-COM485-PLUS2. I wonder if I get schematic of COM485-PLUS2? Or does anyone have an idea about that situation?

Thank you.

Cristian

Hello,

Yes, there are internal pullups on the RXD lines of FT232R and FT232H.

the typical value is 75 KΩ. You can find more information in 5.3 of the FT232H datasheet.

Best Regards
FTDI Community

Hello,
I have two FTDI cables based on the FT232H (a C232HMDDHSL-0 and a C232HD-DDHSP-0) and one based on the FT232R (TTL-232R-3V3).

In active mode (device enumerated after EEPROM read) the RXD pin is HIGH on these devices (some 2.5V on the FT232H based cables and 3.3V on the FT232R based cable). Now, in this mode, this pin operates as an input. In order to be high, it must have a pull-up. Is there any information available with regards to this pull-up (its value)?

The datasheet of the FT232R might infer the presence of a 200k pull-up on this pin, with this statement which is present after Table 5.10:

** Only input pins have an internal 200KΩ pull-up resistor to VCCIO

But there is nothing on this in the FT232H datasheet (although it talks about pull-ups on various other pins, the RXD pin is not mentioned).

I am familiar also with AN_184 FTDI Device Input Output Pin States, but that didn't help either, it just indicates that in in active mode the RXD pin is configured as "Function".

Regards,
Cristian

Hi,

Number 1 is just the general configuration of the device. Number 2 is to enable the GPIOs. Have a look at section 3.1 of AN_412 FT600/FT601 Bridge Chips Integration.

This goes over the configuration modes of FT600 with section 3.1.5 focusing on the GPIO configuration.

We have a FT60x configuration programmer that you can use. You can find it here along with the AN_370 FT60X Configuration Programmer User Guide.

Best Regards
FTDI Community

Thank you very much for Your reply.

Hi,

Have a look at section 3.2 of AN_412 FT600/FT601 Bridge Chips Integration, this goes over the abort recovery process.

Any error or timeout requires this abort process before resuming the read/write.

Best Regards
FTDI Community

What the  difference between these two approaches for device configuring process:
1.
FT_60XCONFIGURATION oConfigurationData = {0};
FT_GetChipConfiguration(HandleFtdi, &oConfigurationData);
if (oConfigurationData.ChannelConfig != CONFIGURATION_CHANNEL_CONFIG_1 ) {
    oConfigurationData.ChannelConfig = CONFIGURATION_CHANNEL_CONFIG_1;
    FT_SetChipConfiguration(HandleFtdi, &oConfigurationData);
}

2.ftStatus = FT_EnableGPIO(ftHandle, 0x1, 0x1); //??
    ftStatus = FT_WriteGPIO(ftHandle, 0x1, 0x1);
Thank You !!!

      while(1)
        for (int i = 0; i < configurationDescriptor.bNumInterfaces; i++) {
            FT_GetInterfaceDescriptor(HandleFtdi, i, pInterfaceDescriptor + i);
            for (int j = 0; j < pInterfaceDescriptor.bNumEndpoints; j++) {
                res = FT_GetPipeInformation(HandleFtdi,i,j, &pipeInformation);
                if (res != FT_OK) {
                    cout << "FT_GetPipeInformation Error!";
                } else {
                    if (!(pipeInformation.PipeId & 0x80)) {
                        res = FT_WritePipe(HandleFtdi, pipeInformation.PipeId, bufWr, pipeInformation.MaximumPacketSize, &ulBytesTransferred, NULL);
                        if (res != FT_OK) {
                            cout << "FT_WritePipe Error " ;
                        }
                    }
                    else {
                        res = FT_ReadPipe(HandleFtdi, pipeInformation.PipeId, bufRd, pipeInformation.MaximumPacketSize, &ulBytesTransferred, NULL); //second time this function does not return. Why? The first time it returns by timeout.
                        if (res != FT_OK) {
                            cout << "FT_ReadPipe Error " ;   
                        }
                   }
                }
            }
        }

Hi all. Please, say Me.
This part of the program works well, but on the second pass, when FT_ReadPipe is executed, the program freezes and does not return after timeout. The first time it returns by timeout (default 5 seconds).
In addition, I want to say that we made a USB device with FT600 and STM. But the STM is not running yet and is not writing to the FT600 buffer, so it's good that FT_ReadPipe is returning after a timeout. But why doesn’t it return the second time but freezes?
Thank everybody.