Silicon Bugs In The FTDI FT232R, And A Tidy RF VCO Project

[Scott Harden] wrote in to tell us of some success he’s having using the FT232 chip to speak SPI directly from his laptop to a AD98850 digital signal generator. At least that was his destination. But as so often in life, more than half the fun was getting there, finding some still-unsolved silicon bugs, and (after simply swapping chips for one that works) potting it with hot glue, putting it in a nice box, and putting it up on the shelf.

In principle, the FTDI FT232 series of chips has a bit-bang mode that allows you to control the individual pins from a fairly simple API on your target computer, using their drivers and without installing anything on basically any platform. We wrote this feature up way back in 2009, and [Scott] was asking himself why he doesn’t see more hacks taking advantage of bit-bang mode.

“Square” waves

Then he answered his own question the hard way, by spending hours “debugging” his code until he stumbled on the FTDI errata note (PDF), where they admit that bit-bang mode doesn’t get timings right at all on the FT232R and FT232RL parts. FTDI has made claims that they fixed the bug in subsequent chip revisions, but the community has not been able to confirm it. If you want to use bit-bang mode, which is plenty cool, steer clear of the FT232R chips — the ones found in the ever-popular FTDI cables and many adapter dongles.

The good news here is twofold. First, now you know. Second, bit-bang mode is tremendously useful and it works with other chips from the vendor. Particularly, the FT232H and FT230X chips work just fine, among others. And [Scott] got his command-line controlled digital VCO up and running. All’s well that ends well?

We’ll wrap up with questions for the comment section. Do other manufacturers’ cheap USB-serial chips have an easily accessible bit-bang mode? Are any of you using USB bit-bang anyway? If so, what for?

31 thoughts on “Silicon Bugs In The FTDI FT232R, And A Tidy RF VCO Project

  1. The CP2104 does offer some extra pins that could be used for e.g. bit-banging, but I have never needed to use them for anything, so I do not know how easy they are to make use of.

    1. That is correct.

      May be that the clones worked better than the originals was one of the reasons FTDI deliberately released a MS autoupdate for the malware drivers to brick all the competition clone chips.

      Fortunately the linux version attempt at the same dirty trick was laught at and rejected.

      1. That also showed, that a mass produced, cheap microcontroller may be the better choice, compared to a (medium volume) custom chip.
        And that’s probably the reason, why Silicon Labs and Microchip sell factory programmed microcontrollers as USB to serial/parallel converters.

  2. I would say that if you want to build a device that works and keeps working even after a driver update, steer clear of FTDI in general. You never know what new trick they will invent next to brick your device.

    1. As long as you have the real FTDI chip in your design, it will continue to work, no matter how many driver updates.

      You will only run into problems if you buy fakes. But if you buy fakes, you might run into a lot of issues. They might work… or fail under certain conditions… or might be unable to handle high baud rates.

      You shouldn’t complain about FTDI, you should complain about people making and selling fakes.

  3. The Radio Shack Color Computer used software as a UART for the serial port, though you could buy a serial board. I ran Microware OS-9 on it, multitasking and multi-user. But when I was printing something, the timing meant the software UART had to turn off interrupts a lot, which slowed down other things. So if I was printing, word processing in another window would slow to a crawl, suddenly you’d see the cursor moving about the screen ever so slowly.

    Hardware UARTs are the way to go.


  4. A few comments have recommended chips that have bit-bang mode, but I don’t see anyone sharing tales of what they use it for. Surely there must be use cases out there?

    I’ve been trying to think of a place where I would have used bit banging if I had it but can’t really think of one. I have a Bus Pirate that I often use to test out new chips to ensure I understand the protocol before using them in a larger system. But that’s usually SPI or I2C and so that’s what Scott Harden is doing here with the FTDI chip (and Bus Pirate has a bitbang mode so that’s another solution to add to the list of chips).

    Anyone have a non-standard protocol they bit bang?

    1. My L-Star project uses a Propeller to bitbang a 6502 but because that takes up a lot of pins on the Propeller, it’s difficult to emulate some old computers because I simply run out of pins.

      My design uses an FTDI based Prop plug to communicate between the PC (needed to program the Propeller) and the project, but I’m thinking of replacing it with a PIC that has a USB interface and extra bitbang-capable pins. That way I can free up pins from the Propeller to emulate more computers. It’ll have to be a PIC though: FTDI still doesn’t make their chips in DIP format and I want to keep my design 100% through hole.


    2. We bitbang SWD to enable our main CPU to erase, reflash, reset etc a secondary MCU/radio-chip (an nRF52xx). For both production test, factory programming and subsequent field updates.

      1. Actually it should be fairly easy to bitbang an USB-serial adaptor that has more then the TX RX GND pins exposed, such as DTR, RTS, CTS, DI pins. I made a while back a simple program using the serial libs of linux to toggle a DTR pin:

        Those cp2102 based breakout boards have most of the pins exposed on the board.

        But I am pretty sure you could bitbang them faster with some libusb messages.

  5. I once used their ‘new’ VNC2 USB micro for a production test fixture. Turned out all our problems were caused by their buggy SPI implementation. It’s really not that hard to get right (speaking as an ex digital IC designer) but that issue killed the project and I never touched those parts again.

  6. Why not consider the Exar XR22802? It has a very low latency HID interface, which works fine under Linux. The ethernet driver can be disabled in firmware to reduce power consumption. We used the MCP2210 in the past, which is slow. FTDI chipsets were not considered because of their custom linux drivers.

  7. Maybe the dumbest one if you need to control timing from something that runs a real opsys (linux, pi, PC, MAC) that won’t bitbang- I just use an arduino, the chinesium sort, dirt cheap and realtime as I wish with my little cooperative multitasking system (which is less fancy than the name). OK, it’s big, but I’m doing infrastructure stuff anyway. I used to be a super PIC fan and designed them into product for myself and others, but Arduino is just a no-brainer anymore. ~~$4 and 30 minutes tops with a bog standard USB to talk to the host in the host’s timing while I do realtime in the Atmel? Beat that and I’m listening.

  8. I will *NEVER* *EVER* buy anything with FTDI in it (if I can avoid it). I had a student lab with 30+ arduino nano clones which stopped working after the infamous driver update (and no, sorry, how am I supposed to know if a chip marked FTDI is legit or not?). Yes, I eventually was able to fix things, but anytime any of these was connected to a different windoze machine things went badly. Too much time to fix things. Eventually just gave all of them away and got the chinese clones which are cheaper and work better. #neverFTDI

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.