[marcan_42]

The really sad thing is that the FTDI clones worked better than the original ones.

The original FT232R chips have a clocking bug that makes bitbang mode unusable for many applications, with no workaround (their errata sheet suggests a bullshit workaround of setting the clock speed to max, that is unusable in practice because USB can't keep up). It's supposedly fixed in a revision that I've never seen, and I believe they never manufactured it.

The clones... work perfectly fine: https://twitter.com/marcan42/status/695292366639378433

In fact, I reverse engineered FTDI's bricker, and it works by exploiting the fact that their own chips violate their own interface design by requiring EEPROM words to be written back to back - even word writes alone are staged and ignored without an odd word write. The clones honor the writes independently, like FTDI's other chips. Their bricker code only writes even EEPROM words and preimage attacks their own checksum algorithm (since the real checksum is at an odd word they can't touch) to make it work, so it has no effect on the real chips (which get sent the same commands). It's hilarious.

Don't buy FTDI. They're just bad.

[drothlis]

We too found that the FT232R is unusable in bitbang mode. After much to-and-froing, FTDI support eventually acknowledged that even their later hardware revision "C" is still buggy, despite what the errata sheet implied.

We switched to the FT230X, which works great.

Our detailed investigation: https://stb-tester.com/blog/2016/05/26/ir-post-mortem

[robomartin]

I've been using FTDI for, I don't know, twenty years. No problems at all. Also using USB solutions from other vendors (not FTDI clones).

> The original FT232R chips have a clocking bug that makes bitbang mode unusable for many applications, with no workaround

One of the problems with this situation is that if clones are allowed to permeate the market unencumbered the manufacturer of the genuine device might not have the financial capability to address problems and continue to innovate. Every single fake chip takes revenue away from the legitimate supplier.

Not arguing that your technical point isn't valid. It is. My point is that causing damage to the legitimate manufacturer by substituting their chips with clones has a non-zero non-trivial effect. Clone chip makers have zero interest and expend zero effort, time and money supporting the ecosystem they infect. All they care about is pushing their hardware and nothing else.

This also causes damage to consumers because it is impossible to know what issues fake chips might bring to the table across a wide range of vectors, safety and reliability being just two of them.

The better path is to take design wins away from FTDI and adopt hardware from legitimate part suppliers with solutions that meet your requirements. That's fine and that's how a healthy market works. Choosing fakes over legitimate parts hurts everyone. Today it's FTDI, tomorrow it could be your own products. Having experienced the "attack of the clones" myself, I can tell you this is not pleasant at all and it can, quite literally, destroy your company, costing jobs and your future.

Not a simple problem.

[feteru]

Wait so the bricker wouldn't even work on the clones? Or it only works on the clone because they don't have the FTDI checksum algorithm bug?

[kd5bjo]

If I’m reading marcan_42’s comment correctly, the FTDI chip defers any EEPROM write request to an even address until it receives the next write request to the subsequent, odd, location. If the next write is somewhere else, it discards the original data.

The 3rd-party chips, on the other hand, perform each write immedately per the official documentation. The malicious driver uses this difference to overwrite the firmware of the 3rd-party chips with carefully-crafted nonsense that has the same checksum as the legitimate firmware.