FT232R BitBang mode is broken.

While trying to use a FTDI RT232RL in synchronous bitbang mode, I (like many others apparently) discovered that this feature is completely broken in most chips currently on the market.

The problem is described in the errata but not anywhere in the datasheet or appnode describing the bitbang modes.

It annoys me to no end that the bug is not described in the bitbang appnote, it would have saved me hours of frustration, and could possible save other people quite a bit of wasted time too.

When I was trying to find out what was wrong with my project, I ended up with this small repo case, that should have resulted in a 500 Hz square wave signal.

#include <stdio.h>
#include <string.h>
#include <ftdi.h>

int main()
  ftdi_context ftdic;

  if(ftdi_usb_open_desc(&ftdic, 0x0403, 0x6001, NULL, NULL) < 0)
    fprintf(stderr, "ftdi_usb_open_desc failed: %s\n", 

  if(ftdi_set_baudrate(&ftdic, 1000) < 0)
    fprintf(stderr, "ftdi_set_baudrate failed: %s\n", 

  if(ftdi_set_bitmode(&ftdic, 0x01, BITMODE_SYNCBB) < 0)
    fprintf(stderr, "ftdi_set_bitmode failed: %s\n", 

  uint8_t data[256];
  for(int i=0; i<sizeof(data); i++)
    data[i] = i&1;

    ftdi_write_data(&ftdic, data, sizeof(data));
    uint8_t data2[256];
    ftdi_read_data(&ftdic, data2, sizeof(data2));

  return 0;

But when hooking up a scope to the tx line of the FT232, it's easy to see that the output is a complete mess. The pulse widths are all over the place, from 60μs to 1ms.

In the errata, it's suggested that the fix is to run with a baudrate of 3000000, and just generate longer pulses to compensate. This might sound like a usable workaround, but FTDI neglected to tell that the chip is only running with 12.5MBit/s usb speed. Far from the needed ~65MBit/s needed for 3000000 baud (3000000baud * 10bits/byte (with bit stuffing) * 2 (we need to both send and recv) * 10% (usb header overhead).

Running the chip at 3000000 baud (changing 1000 to 3000000 in the ftdi_set_baudrate call), does not work either.
Not only do we not have enough usb bandwitdh (can be seen as the spratic blocks of data in the top part), but we only get 0.5μs long pulses. Not 0.33μs as expected.
The pulse widths are better than at lower speeds, but still not stable.

We can only hope that vendors will soon sell out of there devices using the A and B revisions of these chips, so that we can get some breakout boards with revision C, that supposedly will work as advertised.


  1. Rev B is *not* affected by this bug. Only rev A is buggy. Check the errata:

    """The current revision of the FT232R is revision B, released May 2007. At the time of releasing this Technical Note there are no known issues with this silicon revision."""

    There should be no rev A on the market anymore. Rev B was released in 2007.

  2. I've has the same problem for months, and I have just stumbled on this article. Thank you because I would never have found the FTDI Errata TN_120 without you.
    I am using an FTDI lead TTL-232R-3V3 purchased in the past year or two from Farnell/RS, this has the sporadic gaps in the synchronous tx, just like your article. As this is a pre-made lead the FTDI chip is over moulded so that I cannot see the chip version, but after a little work with a craft knife I see that I have...
    This means I have the revision C of the device.
    But having looked at the Errata, it notes that Rev A has the problem but it will be fixed in rev B. If it was fixed in rev B - it's now broken in rev C !!!

  3. The FT232R rev C is still broken in bit-bang mode. See details of our investigation here: https://stb-tester.com/blog/2016/05/26/ir-post-mortem

    We sent our evidence to FTDI support and they agreed that it is a bug with the chip.

    The FT230X is a similar USB-to-serial chip that also has a bit-bang mode, and it works perfectly. (@Nigel Webb: and it also comes in a dev package, UMFT230XB).

  4. I also beat my head against this for a while before discovering the same thing. For others passing by, the bit-bang mode on my chip actually seems to work ok with the baud rate set to 65536, which is fast enough for my purposes. Maybe there are other sub-3MHz rates that are also stable?

  5. Just for clarity, the 65536 baud rate I mentioned above was set using libftdi:

    ftdi_set_bitmode(ftdi, 0xFF, BITMODE_BITBANG);
    ftdi_set_baudrate(ftdi, 65536);

    libftdi does some munging of the baud rate so the rate that gets set on the chip is probably actually 65536/16 = 4096 to account for the 16x that applies in bit bang mode.

  6. In our experiments 65536 still gives timing problems. We were using it to generate infrared button-presses, resulting in ~2% of button-presses to be so far off the timings that the set-top box or TV wouldn't recognize them.

    With most other baud-rate settings, the chip wouldn't work at all.