<div dir="ltr">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.<div><br></div><div>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).</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 13, 2016 at 5:35 PM,  <span dir="ltr"><<a href="mailto:jonjwolfe@anibit.com" target="_blank">jonjwolfe@anibit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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:<br>
<br>
<a href="http://hackaday.com/2016/02/01/ftdi-drivers-break-fake-chips-again/" rel="noreferrer" target="_blank">http://hackaday.com/2016/02/01/ftdi-drivers-break-fake-chips-again/</a><br>
<br>
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.<span class=""><br>
<br>
<br>
<br>
On 2016-04-13 15:10, Rodney Radford via TriEmbed wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Could you be a victim of FTDI-gate?<br>
<br>
If the answer to both of these questions is yes:<br>
* Have you ever used this FTDI adapter on a Windows box?<br>
* Is it possible you have an FTDI clone?<br>
<br>
<a href="http://www.zdnet.com/article/ftdi-admits-to-bricking-innocent-users-chips-in-silent-update/" rel="noreferrer" target="_blank">http://www.zdnet.com/article/ftdi-admits-to-bricking-innocent-users-chips-in-silent-update/</a><br></span>
[3]<div><div class="h5"><br>
<br>
On Wed, Apr 13, 2016 at 2:53 PM, Alex Davis via TriEmbed<br>
<<a href="mailto:triembed@triembed.org" target="_blank">triembed@triembed.org</a>> wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Anyone run OSX 10.11 and use an FTDI with an Arduino-type board? I<br>
had<br>
repaired some broken HT1632-based LED displays with a new driver<br>
chip<br>
and wanted to test them, and the nearest thing at hand was an AVR<br>
1284P<br>
"mighty mini" board, which needs an FTDI to program it.<br>
<br>
I hadn't used that since last year, and I've gone through a few<br>
Arduino<br>
verions since, so I had to go through the routine of updating my<br>
"hardware" directory with a version which works with 1.6.7.<br>
<br>
My issue is when I try to program via the FTDI, something goes<br>
wrong,<br>
which then causes OSX to dump the driver, which makes the entry in<br>
/dev/<br>
disappear. This is apparently due to a bug in the FTDI-supplied<br>
driver,<br>
and supposedly the solution is to use a utility to delete the kext<br>
for<br>
it.<br>
<br>
Anyone gone through this successfully? I'm not SOL at the moment,<br>
as I<br>
can use my AVRISP MKII to program it directly through the ICSP<br>
connector, but I do have other boards which lack that and need the<br>
FTDI.<br>
<br>
--<br>
"The theater of noise is proof of our potential."<br>
| | (¯ / |¯ |V| | ¯|¯ |¯) | / | | | |¯ (¯ /¯ / |V|<br>
|-||_ (_ / |_/ @| | |-| | | | / |^| | |_/ (_ . _ / | |<br>
<br>
You won't find me on Facebook.<br>
<br>
_______________________________________________<br>
Triangle, NC Embedded Computing mailing list<br>
<a href="mailto:TriEmbed@triembed.org" target="_blank">TriEmbed@triembed.org</a><br>
</div></div><a href="http://mail.triembed.org/mailman/listinfo/triembed_triembed.org" rel="noreferrer" target="_blank">http://mail.triembed.org/mailman/listinfo/triembed_triembed.org</a> [1]<br>
TriEmbed web site: <a href="http://TriEmbed.org" rel="noreferrer" target="_blank">http://TriEmbed.org</a> [2]<br>
</blockquote>
<br>
<br>
<br>
Links:<br>
------<br>
[1] <a href="http://mail.triembed.org/mailman/listinfo/triembed_triembed.org" rel="noreferrer" target="_blank">http://mail.triembed.org/mailman/listinfo/triembed_triembed.org</a><br>
[2] <a href="http://TriEmbed.org" rel="noreferrer" target="_blank">http://TriEmbed.org</a><br>
[3]<br>
<a href="http://www.zdnet.com/article/ftdi-admits-to-bricking-innocent-users-chips-in-silent-update/" rel="noreferrer" target="_blank">http://www.zdnet.com/article/ftdi-admits-to-bricking-innocent-users-chips-in-silent-update/</a><span class=""><br>
<br>
_______________________________________________<br>
Triangle, NC Embedded Computing mailing list<br>
<a href="mailto:TriEmbed@triembed.org" target="_blank">TriEmbed@triembed.org</a><br>
<a href="http://mail.triembed.org/mailman/listinfo/triembed_triembed.org" rel="noreferrer" target="_blank">http://mail.triembed.org/mailman/listinfo/triembed_triembed.org</a><br>
TriEmbed web site: <a href="http://TriEmbed.org" rel="noreferrer" target="_blank">http://TriEmbed.org</a><br>
</span></blockquote>
<br>
</blockquote></div><br></div>