# FT4232H: Configuring RI# as TXDEN Using FTProg

I am developing a device based around two FTDI FT4232H quad USB-to-Serial converters plugged into a Texas Instruments TUSB2046 USB hub controller. The serial outputs of each FT4232H channel goes to a Texas Instruments SN65HVD72 RS-485 transceiver, thus creating a dual-quad USB-to-RS485 converter. See Section 4.3.3 (page 20) of the FT4232H datasheet for a diagram of what I am doing for each FT4232H (though using all four channels rather than just two). The FT4232H multiplexes the functions of Ring Indicator and Transmit Data Enable on a single pin, called RI#/TXDEN, and the default is RI#. If I am reading the datasheet correctly, in order to use this pin as TXDEN to drive the DE pin of the RS-485 transceivers, I need to configure it to use this function in the FT4232H's EEPROM. For this I use the FT_PROG utility from FTDI.

When I first plug in my board containing the hub, USB-to-serial converters, and the RS-485 transceivers to my USB port, all 8 COM ports enumerate as they should. The next thing I do is open up FT_PROG and run the "Scan & Parse" command. Once completed, both FT4232H USB-to-serial converters appear, and they show up as "Blank Devices":

My next step is to go into each channel and check the box next to "RI as RS485 Enable", as shown in the following image:

I repeat this process for all ports, A-D, on both devices. Next I click the "Program" icon on the top menu bar, and on the confirmation window I check that both devices are checked and I click "Program". Once done, I see "Finished Programming" appear at the bottom of the window.

Everything appears to work, and after clicking "Cycle Ports" I confirm that data does appear to have been written to the internal memory. After that I click "Scan & Parse" once more:

After running the "Scan & Parse" command, however, the devices appear blank once again and none of my changes "stuck". The "RI as RS485 Enable" setting is unchecked again.

I thought perhaps that "Scan & Parse" might delete some settings of the chips (Think I found this in the datasheet or an app note somewhere, that this setting was cleared on reset), and even though that doesn't make any sense to me I decided to give it a try without re-scanning. Unfortunately I was not able to communicate with my RS-485 device - my terminal program was unable to even detect the presence of any devices on the RS-485 bus. This is my first time ever using FT_PROG, as well as these particular FTDI chips, so perhaps I am missing a step in the process? I am hoping someone might be able to determine the reason why my changes don't "stick" and why I am unable to communicate with my RS-485 device after connecting to the respective COM port.

For the record, I tried all COM ports which were enumerated when I plugged in my USB cable, so unfortunately it's not as simple as me just not looking at the right bus.

• Sounds like DE is not being selected. Can you monitor those signals? – Tony Stewart EE75 May 28 '20 at 0:29
• That was my instinct as well, though that would not explain why the settings weren't sticking in the FT4232H EEPROM. I will have to finagle the board a bit in order to probe those pins, but I wanted to check and make sure I wasn't doing something stupid in the software first. – DerStrom8 May 28 '20 at 0:33
• Use resistor wires to test pins. With gnd pins too. Not familiar with the rest – Tony Stewart EE75 May 28 '20 at 0:38
• I assume you meet the criteria for dot NET4 – Tony Stewart EE75 May 28 '20 at 0:44
• @TonyStewartSunnyskyguyEE75 Yes, I believe so. I can confirm tomorrow. – DerStrom8 May 28 '20 at 0:51

EEPROM Type: No EEPROM detected