[TriEmbed] OSX 10.11 FTDI driver issues

[Rodney Radford]

Yes... they did back out the change that bricked the hardware, but if the
hardware was used with the old driver, it does not un-brick when used with
a new driver.  They actually changed the vendor ID in the chip so no driver
can find it again (even under Linux).  So once brick'ed it stays brick'ed
unless you can reprogram the vender ID.

The latest Windows change is to send a garbage string from the driver back
to the app, so not brick'ed, but also not usable. The advantage of this
system is that switching drivers or OS's does restore the functionality
again (ie: not permanent changes to the device).



On Wed, Apr 13, 2016 at 5:35 PM, <jonjwolfe at anibit.com> wrote:

> FTDI quickly backpeddled on their counterfeit-bricking drivers from 2
> years, but apparently there is a new FTDIgate v2 a couple months ago that I
> missed:
>
> http://hackaday.com/2016/02/01/ftdi-drivers-break-fake-chips-again/
>
> This one doesn't brick the hardware per se, but will make it potentially
> unusable with the latest drivers. It doesn't affect Linux because the
> drivers are open-source, I don't know about OSX.
>
>
>
> On 2016-04-13 15:10, Rodney Radford via TriEmbed wrote:
>
>> Could you be a victim of FTDI-gate?
>>
>> If the answer to both of these questions is yes:
>> * Have you ever used this FTDI adapter on a Windows box?
>> * Is it possible you have an FTDI clone?
>>
>>
>> http://www.zdnet.com/article/ftdi-admits-to-bricking-innocent-users-chips-in-silent-update/
>> [3]
>>
>>
>> On Wed, Apr 13, 2016 at 2:53 PM, Alex Davis via TriEmbed
>> <triembed at triembed.org> wrote:
>>
>> Anyone run OSX 10.11 and use an FTDI with an Arduino-type board? I
>>> had
>>> repaired some broken HT1632-based LED displays with a new driver
>>> chip
>>> and wanted to test them, and the nearest thing at hand was an AVR
>>> 1284P
>>> "mighty mini" board, which needs an FTDI to program it.
>>>
>>> I hadn't used that since last year, and I've gone through a few
>>> Arduino
>>> verions since, so I had to go through the routine of updating my
>>> "hardware" directory with a version which works with 1.6.7.
>>>
>>> My issue is when I try to program via the FTDI, something goes
>>> wrong,
>>> which then causes OSX to dump the driver, which makes the entry in
>>> /dev/
>>> disappear. This is apparently due to a bug in the FTDI-supplied
>>> driver,
>>> and supposedly the solution is to use a utility to delete the kext
>>> for
>>> it.
>>>
>>> Anyone gone through this successfully? I'm not SOL at the moment,
>>> as I
>>> can use my AVRISP MKII to program it directly through the ICSP
>>> connector, but I do have other boards which lack that and need the
>>> FTDI.
>>>
>>> --
>>> "The theater of noise is proof of our potential."
>>> | | (¯ / |¯ |V| | ¯|¯ |¯) | / | | | |¯ (¯ /¯ / |V|
>>> |-||_ (_ / |_/ @| | |-| | | | / |^| | |_/ (_ . _ / | |
>>>
>>> You won't find me on Facebook.
>>>
>>> _______________________________________________
>>> Triangle, NC Embedded Computing mailing list
>>> TriEmbed at triembed.org
>>> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org [1]
>>> TriEmbed web site: http://TriEmbed.org [2]
>>>
>>
>>
>>
>> Links:
>> ------
>> [1] http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
>> [2] http://TriEmbed.org
>> [3]
>>
>> http://www.zdnet.com/article/ftdi-admits-to-bricking-innocent-users-chips-in-silent-update/
>>
>> _______________________________________________
>> Triangle, NC Embedded Computing mailing list
>> TriEmbed at triembed.org
>> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
>> TriEmbed web site: http://TriEmbed.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20160413/c134285c/attachment.htm>