An anonymous reader pinged us about an issue that affects people who jumped onto the latest-and-greatest OS from the Apple gardens: USB devices that stop working due to the FTDI-based USB solution. At its core appears to be that the built-in FTDI driver provided by Apple (AppleUSBFTDI.dext) only supports FTDI chips which provide the standard FTDI vendor and product ID (e.g. 0x0403 and 0x6001 respectively for the FT232R). Many products however set a custom product ID (PID) to differentiate their device, though in the thread some mention that there are driver issues even with the default VID/PID combination.
Over the past years, Apple has been restricting and changing the way kernel extensions (KExt) and driver extensions (DExt) are handled. As these FTDI chips are often used for virtual com port (VCP) purposes, such as with Arduino boards and USB-TTL adapters, this is a rather cumbersome issue that would affect anyone using Big Sur in combination with such a hardware device.
So far only the FTDI team has been somewhat responsive based on the support forum thread, with Apple seemingly rather silent on the issue.
What it clearly demonstrates is Apple doesn’t do any testing before releasing.
They have adopted the microsoft model of using end users as beta testers.
Build a list of what everyone screams about the loudest, then fix half the list and roll the rest into the next OS version that can be charged for. Translated the general public did all the testing on your product and paid to have half the bugs they found fixed…. maybe.
This is why Apple don’t care, because instead of switching to a vendor that is doing better, your typical Apple user bashes them to validate their choice in the face of a screw up.
No. The USB standard says if you enumerate as a custom VID / PID and do not deliver generic class descriptor then the host needs to be providing a custom driver. This is the way with USB… for almost 25 years now.
This is an epic FAIL on the part of FTDI. Going “custom” was part of the FTDI business model with these serial chips — there is implicit “lock-in” / dependency if you go this route. The FTDI chips do not present a CDC descriptor, meaning that *only* a custom driver can match. No operating system can deal with this without custom patching / installing a driver for the VID / PID pair. Apple created a kext that handles the “default” VID / PID from FTDI, but it only delivers the standard CDC serial functionality.
FTDI also have a very bad record with the KEXTs they have provided. My experience is that an FTDI KEXT will panic when the serial device is open, data is being transmitted and you “unplug” the serial device. If you use the built-in Apple driver this does not happen. I conjecture that his is the reason why Apple created a “generic” driver to handle the default VID / PID case.
“No. The USB standard says if you enumerate as a custom VID / PID and do not deliver generic class descriptor then the host needs to be providing a custom driver. This is the way with USB… for almost 25 years now.”
Yes. Yes it is.
“This is an epic FAIL on the part of FTDI.”
Not so sure about that. Is this FTDI’s problem? Or is it the actual product vendor that is supposed to supply the driver for their product? I have the FTDI drivers, in several variants, and there is no issue with the proper FTDI identifying devices. I have had problems, both on Linux and Windows, with devices that have non-FTDI ID’s.
I agree that it is not (mostly) Apples responsibility here, nor is it an issue specific to Apple OS’s. But Apple did change established behaviour breaking working systems.
Except that MacOS updates come for free. So Apple don’t make money from leaving bugs in.
Please help me understand how it is an “advantage” or plus for Apple, Windows, Ubuntu, Debian to deliberately mess-up a customer on an update? As you note, the update was not a $$$ transaction. Any bugs would mean more costs and bad sentiment? Where is the gain / upside / advantage to be had doing this with a free update?
You premise implies malice. The logic suggests something else is going on.
My money’s on stupidity/carelessness.
They probably have a test matrix. Perhaps it doesn’t (didn’t) include FTDI devices with custom PIDs.
I release software. I have absolutely no way to test every hardware combination before I release.
“What it clearly demonstrates is Apple doesn’t do any testing before releasing.”
Apple *extensively* seeds their developer previews, which FTDI almost certainly had access to. There’s no way FTDI didn’t see this coming.
Ditto for groups like Arduino.
Tons of people who aren’t developers run the developer previews. There are people who install the very first previews, many months ahead of the final releases.
Apple hasn’t charged for an OS upgrade in eleven years, but nice try.
Wrong! This was announced several years in advanced! I was in contact with FTDI, they know about this issue since a long time, but are just not able to update their drivers to dext yet!
This is another reason why CDC devices are superior to proprietary ones.
Live by the sword…
Yes., yes, yes. LUFA with an Atmel 32U2 / 16/U2 with CDC works really well. Warning don’t keep the string “Dean Camera” in the CDC descriptor name, even for testing, or you might be in for some legacy “Camera” matching fun, grrr
100% Agree.
Never liked the FTDI device, specifically because of that “ID” business. I’ve used the Silicon Labs CP2104 with good success on Macs.
It’s generally a good idea to avoid Silicon Labs because they churn out new chips every six months or so and you have to continually update your designs.
The cp2104 has been out for several years. I used it at my last job around 2018.
Just an FYI, but the FTDI FR232RL has been around since at least 2008… as that is when we first designed it into one of our products.
Well, there goes the FTDI chips, along with the CH340s that crash Macs!
The Mac OS updates break things again.
That is a pain because I an a long time user of Macs, falling back to Windows only when I really have to.
An earlier update disabled USB video adapters too. I wish they would just stop breaking things that used to work well.
I never had CH340’s crash my mac’s,… Most of the time something doesn’t work, it turns out i’m using a USB power cable without datalines ;)
Well, you live on the edge of consumer-town with those systems, so they are only expected to support the newest and worst.
I’ve had a some bad experiences with the FTDI kext and macOS. If the serial device was open and data was in transit, pulling the plug on the USB device would more often than not cause a kernel panic and many, many swear words. I do not recall this every happening since Apple started providing a generic FTDI driver.
I remember the same issue to have occurred on Windows as well some years ago. That left my FTDI-equipped RS-485-adapter unrecognized. As there was (and is) an original FTDI chip assembled, it was possible to rewrite the PID to the original one by an FTDI tool which brought the adapter back to life; FTDI seems to know this kind of issues for the same period of time. Hm, we read a lot about counterfeiting FTDI chips; isn’t there a better solution to the PID? Who’s fault is it so?!
Title should be : “MacOS 11 not working with FTDI VCP Chips With Custom PIDs”
This is just the tip of the iceberg. MOSXI “security” is based on treating owners of devices like peons who are merely leasing the hardware from Apple. That’s not a formula for creating great experiences for those who like to hack their systems. And a nice way to invalidate any hardware that needs more than superficial custom drivers.
Nope. A custom VID / PID without a valid USB class is going to behave this way on any operating system. FTDI had a business selling VID / PID pairs and coding this into the FTDI “custom” driver. If you didn’t install the FTDI driver, then your device would not enumerate. This is part of the USB specifications. The custom VID / PID mappings and the endpoint behaviours / packet types are not publicly available. This is an FTDI problem that they created and sold to people who chose to use the FTDI chips.
Use non-standard hardware, get non-standard issues.
Problem is you can’t set a standard years after the ship has sailed. Admittedly the way some of these adapters work is non-compliant but if you don’t enforce the rules from day one, you are on the hook if you do it later. It was unnecessary for them to break these devices at this point in time. Non-standard hardware is a big thing to anyone doing design and engineering work. Everything is non-standard until it becomes a standard. If Apple wants to be the go to computer for engineering and hackers, they need to understand that people will do non-standard stuff.
Apple is by definition non standard hardware. This sin’t the first time apple has FU hardware devices with a software update.
BTW did anybody notice Apple no longer allows users to change the MAC address of USB devices?
This is my last MacBook. I am not allowing my MacBook to update with the daily nag screens “update now” and this FTDI is another nail in the coffin IMHO. Looks like I would be SOL again with Apple kindly breaking all my USB and communications with non-Apple devices.
Apple’s policy is to turn all MacBooks into iPads and not allow users to do anything outside their acceptable use policy for what a computer is.
This happened years ago when Windows 10(?) introduced driver signing, so you could no longer just edit a .INF file to create a driver package for a FTDI chip with custom name.PID.
Total PITA as it was very useful to use custom PIDs to get the right driver configuration to reduce the amount of fiddling a user needed to do.
Sadly, later Win 10 builds require far more effort. These days not only does one need a specialty 2-factor token based signing certificate, but that afterwards you have to submit the driver and test results to Microsoft for approval. The latter is right out of the Apple playbook where Microsoft can control what devices you can use with “your” computer. It could be only a matter of time when Microsoft will demand payment from the hardware vendor for the “privilege” of allowing their devices to be used with Win10 and newer O/S’s
Out of curiosity I decided to investigate the “latest” FTDI drivers.
There are 3 flavours:
VCP Drivers
D2XX Drivers
D3XX Drivers
The FTDI VCP download page says that the drivers were “released” on 2020-08-13 and “This driver is signed by Apple”. It is supposed to work on “Mac OS X 10.9 and above”. Many of these these things seem to be less than truthful. The driver is signed by “Developer ID Installer: Iain Paterson (PCP3X3VXC2)”. This is not Apple, but possibly an individual that works at “FTDI???”, so there is a bit of a misunderstanding there. The code signing date and compilation of the driver is from 2020-05-26, not the 2020-08-13 date that is claimed on the web page. The driver is being installed into /Library/Extensions — so that is a plus (many drivers try to install into /System which according to Apple Docs should be treated as read-only). The take-away is that this driver was definitely created and “tested” before Big Sur — even before many of the of the Catalina updates! __Shrug__, does this mean that FTDI is not actively tracking and testing what apple is releasing? Since the signing date on this driver is before any of the summer announcements this can never work on Apple Silicon – so the “Mac OS X 10.9 and above” is called into question. Have they been testing this? How? Is FTDI just not monitoring what Apple is releasing? Do they care? Why don’t the dates match up? Too many questions. Red flags?
The Linux drivers have no dates listed, but the Comments say, via a PDF to TN_101 – that to support custom VID / PID numbers you will need to edit some files (so definitely 100% not plug and play)….
The macOS D2XX drivers seem to be installing some sort of USB “user-space” driver. When downloading the driver there is a text box attempting to explain possible VID / PID problems and what is needed to stop the “stock” driver from claiming the device and “locking out D2XX programs”. Not sure who messed up here, why would a VID / PID match multiple drivers? Is this some sort of architectural snafu, who is at fault here? Ho hum.
For D3XX, the macOS drivers do not appear to have been updated since 2017 (same date for Linux and Android, An exception is Windows that got an update in 2020). The download is a ZIP file. Seems to be some sort of developer libraries and sample code. Not qualified to say if this is good or bad. If the code is 100% perfect and does not warrant an update then “just fine”. But, 3 years is a long time and a different platform was updated. Is D3XX dead?
” The code signing date and compilation of the driver is from 2020-05-26, not the 2020-08-13 date that is claimed on the web page”
But as you said, the web site shows a release date, not compilation date !!
No idea on FTDI’s protocols, but unless they’re one of those “It compiles without errors… ship it!” merchants, then surely some time spent testing then waiting for it to be signed off before finally releasing it would explain the difference.
Folks still use FTDI after #FTDIGate?
Any other alternative beside Silicon Labs?
When my boss gives me a month to put together a dev board and software for our chip that needs USB to 2 UART channels, 1 I2C channel, and 1 JTAG channel that works with OpenOCD, I’m not going to insist that I roll my own firmware and driver. I’m going to throw in an FT4232H and save a month or two of development and debug time.
If it were just one UART channel, I’d use SiLabs. But for multi channel and other interfaces (especially JTAG), there aren’t any other plug and play options.
My comment is perhaps only related in an ancillary way, and perhaps reads like a rant, although that’s not my intention.
It is my experience that Apple has little-to-no interest in supporting devices for more than a couple of years. Even upgrading to Catalina was catastrophic for me. After the update, several USB devices stopped connecting. The list of devices included older, Apple-branded devices (such as iPods) as well as a fairly new, third-party, eReader. When I contacted Apple support, their recommendation was to buy a new Mac and new devices. I was flat out told that the support manager wouldn’t care about my issue and that it wouldn’t be escalated. The individual tried his best to help me, and seemed to by sympathetic, but there was little he could do.
I also own a dedicated film scanner that had support dropped for its driver ages ago by Apple. (Film photography using vintage cameras is a hobby of mine.) As such, I keep an ancient Mac Mini around that runs a very out-of-date OS X (yes OS X, not MacOS) just so that I can scan my film.
The moral of the story is that if you want to use Apple products, you should expect to create a small pile of e-waste on a regular basis. I don’t agree with it, but their business model requires that you upgrade your devices often.
And “buy a new device” does NOT apply to film scanners. Good film scanners are Lostech now.
Ha. I just had to buy an Appe G4 quicksilver to install mac os 9.2.2 to use an very high end scanner, The Agfa XY-15 as it was build twenty years ago and needs scsi and mac os 8.6 or later to run. There is an experimental os x app, but I have yet to install 10.2 somewere to test it. The data leaves the mac via a firewire drive…
You should have a look at VueScan: https://www.hamrick.com/
Compatible with a LOT of scanners without any driver. And M1 Apple Silicon/Big Sur compatible.
Using FTDI devices with the driver built into OS X has been a hit and miss for quite a while now. Using the official FTDI driver from their website has resolved all my issues.
Ever since “FTDI Gate” when they started bricking stuff deliberately FTDI is on my black list of companies from which I would not buy again willingly. (Even though my Linux box was not affected, because it does not use the FTDI drivers.
That product is also mostly obsolete.
It was a useful thing some 20 years ago, but these days a simple uC with hardware USB is cheaper then one of those FTDI chips.
The most irritating barrier left is the cost of a vendor ID. The complete ridiculousness of using such a small number to make a row of 16 bits scarce and then extort a lot of money (Several thousand USD, maybe ever recurring yearly?) to use a simple number is beyond me. Why is such a thing even legal?
There’s nothing to prevent you from just creating a USB device with whatever VID you want, but if you try to sell it I’m guessing the USB-IF will probably send you a cease-and-desist if they find out (such as when the VID owner complains.) But the bigger non-legal issue is if your device collides with the VID owner’s device, operating systems will recognize your device as the other entity’s and install their driver. If it’s just just for your own use, feel free to pick any unused VID-PID combination but be aware it could collide in the future.
To purchase a VID it’s a one-time fee of $6000 or you can become a member for an annual $5000. Realistically, that’s nominal for a company making a commercial product. If it’s an open source project, look into pid.codes: https://hackaday.com/2015/04/03/usb-pids-for-all/
Can you not just use FTDIs own tool to change your custom VID/PID product (which is just using the VCP driver) to the stock FTDI one, so that their verfied and working drivers work with it? I am sure I have done that in the past with a abandonwared USB-485 converter that used an FTDI chip?
FYI – I did testing (see: https://tips.graphica.com.au/macos-big-sur-rs232/ ) with macOS Big Sur and FDTI & ATEM Prolific based USB/RS-232 dongles.
The FDTI worked “out of box” while Prolific device is not recognised (it was previously with Catalina).
The “About This Mac” USB reports:
>> FT232R USB UART:
>>
>> Product ID: 0x6001
>> Vendor ID: 0x0403 (Future Technology Devices International Limited)
>> Version: 6.00
>> Serial Number: A50285BI
>> Speed: Up to 12 Mb/s
>> Manufacturer: FTDI
>> Location ID: 0x14400000 / 1
>> Current Available (mA): 500
>> Current Required (mA): 90
>> Extra Operating Current (mA): 0
>> com.apple.DriverKit-AppleUSBFTDI:
>>
>> Version: 1.0
>> Last Modified: 1/1/20, 7:00 pm
>> Bundle ID: com.apple.DriverKit-AppleUSBFTDI
>> Notarised: Yes
>> Loaded: No
>> Obtained from: Apple
>> Location: /System/Library/DriverExtensions/com.apple.DriverKit-AppleUSBFTDI.dext
>> Kext Version: 1
>> Loadable: Yes
>> Dependencies: Satisfied
>> Signed by: Software Signing, Apple Code Signing Certification Authority, Apple Root CA
So it it step forward and backwards at the same time.
Has this been resolved? I’m holding out because I sometimes use FTDI drivers.
I see a few spotty comments. One mentioned that maybe the latest drivers from FTDI do work? Another mentioned that all but the default VID PID work? I would like the default VID PID to work, I can’t always control the hardware I get that I need to connect. I have used a Windows VM to set the VID PID of a device plugged into my Mac before, so I’m a little concerned if that workflow stops functioning with no alternative.
I use a tool (fujprog) that uses the FTDI D2XX drivers, I ended having to rebuild the tool using the latest libftd2xx.a & headers to make it work for a FT231X chip. I’m on OSX 11.1. Product ID: 0x6015 Vendor ID: 0x0403
FIXED:
I’m on macOS Big Sur (v11.5.2) and some FTDI USB/serial adapters weren’t being recognized anymore.
On Windows downloaded FT_PROG (https://ftdichip.com/utilities/#ft_prog) and pressed ‘scan’ (with the USB unit connected)
After that I changed the PID and VID see which PID/VID required for your FTDI chip (https://www.ftdichip.com/Support/Documents/TechnicalNotes/TN_100_USB_VID-PID_Guidelines.pdf).
After pressing the ‘program’ button and re-inserting (it had to reconfigure the device itself) it did show up with the correct PID/VID.
After this the device is working properly again on Mac.