You could try using FT_PROG to reflash the EEPROM with the factory settings attached. Extract the .zip and the .xml file is the config.
In FT_PROG, first go to DEVICES->Scan and Parse. The board should then show up. Click the open folder icon to load the config. Then click the lightning bolt icon to program it. In the dialog that pops up, click Erase then Program. Unplug/replug your board.
You may need to erase it, then load the config, then program it. I’m not 100% sure if erasing does anything to the open config (seems like it might be reloading it for me).
I’m pretty curious about what happened with this specimen for the driver to act that strange…
FT_PROG is pretty easy to use and it’s impossible to kill the board using it, so if you wish to save yourself the RMA delay you could try it with no risk.
I didn’t offered to do it because I wanted @alchitry opinion on this, because I didn’t knew if we were allowed to fiddle with the FTDI
OK, I did run FT_PROG and followed your previous instructions. It did find the board, identified it as Alchitry Au, I was able to erase it, load the file au_ftdi, and it said install was successful.
However, Labs still cannot see my board. I ran your FDDIList app again and got exactly the same output as I sent yesterday (posted above).
So I guess I am still on the path of returning the board for a replacement.
Ok, so this is very odd…
Maybe the FTDI chip is defective, a newer revision that have a new behavior, or an unofficial clone or counterfait
Or there is something odd with the driver itself, but pretty unlikely since you tried it on 2 different computers…
One last thing that you could be worth a try is to run my app as admin and see if the driver’s behavior is affected.
@alchitry We could also update Labs and Loader to read the description from EEPROM like my app does instead of relying on the driver’s report?
It would make the detection slower since it need to open the each device and read EEPROM instead of just reading the list, but it would be more reliable and solve this case.
Amazing. So I tried Labs, and it recognizes my board and is now working. I don’t understand at all how that fixed it, but thank you!! I have already successful loaded and run a couple of sample projects I had already built. SUCCESS!
Oh! Nice to read that! So it was just FTDI’s driver afterall
So you saved a long RMA and we all learnt something
I remembered that the first time I ran FT_PROG, it was not able to detect my Au, so I ran it as admin and it worked.
I didn’t had any problem with Labs though.
So my guess here is that the problem is really in the FTDI layer that simply need admin rights to update the driver-side description with the value stored in EEPROM, probably because it is stored somewhere in Windows’s registry, or maybe it needs to update some descriptors on the chip.
So all it needs is to ensure that any app that uses the FTDI driver and at least opens the device (maybe reads the EEPROM too?) is ran as admin at least once, and after that it’s not required anymore. Good to know.
I’m glad that my small app I wrote up in 30 min could help
It was just intended to list the detected devices to gather data about your issue, but this side effect is pretty neat.
I may make a variant that would detect the description missmatch and recommand to run it again as admin in an attempt to fix it.
I could also bundle it with required dependancies to make it fully portable, but it would add a few MB because the FTDI layer requires GUI dependancies that the app does not use…
I may try to remove it if there are interest for the this app to become a debug tool
Have the same problem with Alchitry Au. Followed all instructions. FDListDevices.exe prints out:
FTDI device infos
The following devices were detected :
04036010.01D1 : Alchitry Au A
Type : FT_DEVICE_2232H
Manufacturer : Alchitry
Description : Alchitry Au
VID : 0403
PID : 6010
04036010.01D2 : Alchitry Au B
Type : FT_DEVICE_2232H
Manufacturer : Alchitry
Description : Alchitry Au
VID : 0403
PID : 6010
called recommended FT_Prog as admin, erased and programmed succesfully. However Vivado Lab is still unable to find th target.
I am sure there is nothing wrong with board. Any help please?
