A few days ago we learned chip maker FTDI was doing some rather shady things with a new driver released on Windows Update. The new driver worked perfectly for real FTDI chips, but for counterfeit chips – and there are a lot of them – the USB PID was set to 0, rendering them inoperable with any computer. Now, a few days later, we know exactly what happened, and FTDI is backing down; the driver has been removed from Windows Update, and an updated driver will be released next week. A PC won’t be able to communicate with a counterfeit chip with the new driver, but at least it won’t soft-brick the chip.
Microsoft has since released a statement and rolled back two versions of the FTDI driver to prevent counterfeit chips from being bricked. The affected versions of the FTDI driver are 2.11.0 and 2.12.0, released on August 26, 2014. The latest version of the driver that does not have this chip bricking functionality is 126.96.36.199, released on January 27th. If you’re affected by the latest driver, rolling back the driver through the Device Manager to 188.8.131.52 will prevent counterfeit chips from being bricked. You might want to find a copy of the 2.10.0 driver; this will likely be the last version of the FTDI driver to work with counterfeit chips.
Thanks to the efforts of [marcan] over on the EEVblog forums, we know exactly how the earlier FTDI driver worked to brick counterfeit devices:
[marcan] disassembled the FTDI driver and found the source of the brick and some clever coding. The coding exploits differences found in the silicon of counterfeit chips compared to the legit ones. In the small snippet of code decompiled by [marcan], the FTDI driver does nothing for legit chips, but writes 0 and value to make the EEPROM checksum match to counterfeit chips. It’s an extremely clever bit of code, but also clear evidence FTDI is intentionally bricking counterfeit devices.
A new FTDI driver, presumably one that will tell you a chip is fake without bricking it, will be released next week. While not an ideal outcome for everyone, at least the problem of drivers intentionally bricking devices is behind us.
The FTDI FT232 chip is found in thousands of electronic baubles, from Arduinos to test equipment, and more than a few bits of consumer electronics. It’s a simple chip, converting USB to a serial port, but very useful and probably one of the most cloned pieces of silicon on Earth. Thanks to a recent Windows update, all those fake FTDI chips are at risk of being bricked. This isn’t a case where fake FTDI chips won’t work if plugged into a machine running the newest FTDI driver; the latest driver bricks the fake chips, rendering them inoperable with any computer.
Reports of problems with FTDI chips surfaced early this month, with an explanation of the behavior showing up in an EEVblog forum thread. The new driver for these chips from FTDI, delivered through a recent Windows update, reprograms the USB PID to 0, something Windows, Linux, and OS X don’t like. This renders the chip inaccessible from any OS, effectively bricking any device that happens to have one of these fake FTDI serial chips.
Because the FTDI USB to UART chip is so incredibly common, the market is flooded with clones and counterfeits. it’s very hard to tell the difference between the real and fake versions by looking at the package, but a look at the silicon reveals vast differences. The new driver for the FT232 exploits these differences, reprogramming it so it won’t work with existing drivers. It’s a bold strategy to cut down on silicon counterfeiters on the part of FTDI. A reasonable company would go after the manufacturers of fake chips, not the consumers who are most likely unaware they have a fake chip.
The workaround for this driver update is to download the FT232 config tool from the FTDI website on a WinXP or Linux box, change the PID of the fake chip, and never using the new driver on a modern Windows system. There will surely be an automated tool to fix these chips automatically, but until then, take a good look at what Windows Update is installing – it’s very hard to tell if your devices have a fake FTDI chip by just looking at them.
Them kids with those Arduinos don’t know what they’re missing. A serial connection is just too easy, and there’s so much fun to be had with low bandwidth modems. [Mark] made the MicroModem with this in mind. It’s a 1200 baud AFSK modem, capable of APRS, TCP/IP over SLIP, mesh network experimentations, and even long-range radio communication.
As the MicroModem is designed to be an introduction to digital wireless communication, it’s an extremely simple build using only 17 components on a board compatible with the Microduino. The software is built around something called MinimalProtocol1, a protocol that will be received by all other listening stations, features error correction, and automatic data compression. There’s also the ability to send TCP/IP over the link, which allowed [Mark] to load up our retro site at a blistering 1200 bps.
The code is extremely well documented, as seen on the Github for this project, with board files and even breadboard layouts included. [Mark] has three PCBs of his prototype left over, and he’s willing to give those out to other Hackaday readers who would like to give his modem a shot.
A serial monitor is an easy way to debug your projects. As we step through code, it’s nice to see a “Hey! I’m working, moving to next thing!” across the monitor, and not so nice to see nothing – the result of a bug that needs debugging. This has always meant needing a PC loaded with your favorite serial terminal program close at hand.
Most of the time this is not an issue, because the PC is used to compile the code and program the project at hand. But what if you’re in the field, with a mission of fixing a headless system, and in need a serial monitor? Why lug around your PC when you can make your own External Serial Monitor!
[ARPix] built this fully functional serial monitor based on an Atmega328 and a 102 x 64 LCD display. While it doesn’t have a keyboard port like this microcontroller based serial terminal, tact switches allow access to the user interface to start and stop the reading and set the baud rate. The Atmega328 has 2K of SRAM, which is needed for the project. Apparently, 1K was not enough to handle all the data. All code, schematics and a very well done parts layout are available, making this sure to be your next weekend project!
Think you need a microcontroller or a proper motor driver to control a motor? Not really. Because RS-232 serial ports are a hack in and of themselves, you can control two motors with only a serial port and a bridge driver.
Instead of using the data pins on the serial port, this circuit works on with the DTR and RTS control signals of an RS-232 interface. Unlike the data lines of a serial port, these control signals are high when they’re enabled and can also provide a small amount of current – enough to control a pair of pins on a TA7291P bridge driver.
The rest of the circuit consists of a few resistors and a pair of motors, and the software simply turns the DTR and RTS lines on and off. It’s enough for a small robot to waddle across a table, and given the correct driver is simple enough to mash together out of parts from a junk drawer.
[Jesus] is helping his cousin learn about microcontrollers. Right now they’re on the subject of serial communications, which turned into a nice way to add a Hackaday Easter Egg.
Using and FTDI chip in conjunction with the PIC 18F4550 (it’s a little soon for them to tackle implementing USB directly) the serial data is shown in a terminal window. At the same time the binary value of each byte is flashed on the PORTD LEDs. When the chip receives the characters “hack” it immediately echos back the recommendation to check out the awesomeness that is Hackaday. He posted the code used in this example as a Gist.
This is an entry in the Fubarino Contest for a chance at one of the 20 Fubarino SD boards which Microchip has put up as prizes!
Continue reading “Fubarino Contest: Serial Data Transmission”
[ch00f] managed to capture some holiday spirit this year by translating all of A Christmas Carol to scrolling text. Dickens’s work has long since entered public domain, which led [ch00f] to wire up a GeekCatch programmable display from Amazon. It has a low refresh rate, which means videos look a bit goofy, but it’s perfectly acceptable for text. [ch00f] ditched the remote control and instead used the display’s serial connection to program in the novella. Unfortunately, he could not find any documentation for the serial protocol, but he was able to reverse engineer it with some freeware applications found online.
It takes over six hours for the sign to spit out the entirety of A Christmas Carol, which easily surpassed the display’s limited text buffer. [ch00f] instead had to send text to the display one paragraph at a time via a custom Python script. This solution takes advantage of the sign’s fixed-width font to estimate the time it takes for each character to scroll by, then immediately feeds the sign a new line.
Check out the blog post for a quick teardown of the display itself and for a detailed description of the protocol in case you decide to use this display for a project. Stick around for a video below!
Continue reading “Serializing Dickens to LEDs”