update ftd2xx files; fix for Win32 compile error: 'EOPNOTSUPP' undeclared

[gojimmypi]

See https://github.com/f32c/tools/issues/8

 int __cdecl __MINGW_NOTHROW usleep( useconds_t )__MINGW_ATTRIB_DEPRECATED;
                             ^~~~~~
ujprog.c: In function 'exec_svf_tokenized':
ujprog.c:1488:9: error: 'EOPNOTSUPP' undeclared (first use in this function); did you mean 'WSAEOPNOTSUPP'?
   res = EOPNOTSUPP;
         ^~~~~~~~~~
         WSAEOPNOTSUPP
ujprog.c:1488:9: note: each undeclared identifier is reported only once for each function it appears in

[gojimmypi]

Added more changes:

Changes by gojimmypi Feb 13 2019:

README.md

Microsoft dumpbin reports 51E00677 time/date Fri Jul 12 06:36:55 2013 for current repo ftd2xx.lib

The most recent ftd2xx.lib in 2.12.28 is 599AE440 time/date Mon Aug 21 06:46:40 2017

See https://www.ftdichip.com/Drivers/CDM/CDM%20v2.12.28%20WHQL%20Certified.zip on https://www.ftdichip.com/Drivers/D2XX.htm

I copied the FTDI zip file:

• CDM v2.12.28 WHQL Certified\ftd2xx.h to ./ftd2xx.h
• CDM v2.12.28 WHQL Certified\i386\ftd2xx.lib to repo ./ftd2xx.lib
• CDM v2.12.28 WHQL Certified\amd64\ftd2xx.lib to repo ./ftd2xx.amd64.lib

Compiling with x86_64-w64-mingw32-gcc results in this incompatibility error for ftd2xx.lib (32 bit vs 64 bit conflict):

$ make -f Makefile.ming32_64
x86_64-w64-mingw32-gcc ujprog.o  -lftd2xx -o "ujprog.exe" -s -static -L. -lftd2xx.amd64.lib
/usr/bin/x86_64-w64-mingw32-ld: skipping incompatible ./ftd2xx.lib when searching for -lftd2xx
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lftd2xx
/usr/bin/x86_64-w64-mingw32-ld: cannot find -lftd2xx.amd64.lib
collect2: error: ld returned 1 exit status
Makefile.ming32_64:26: recipe for target 'ujprog.exe' failed
make: *** [ujprog.exe] Error 1

So I created Makefile.ming32_64 and added the 64-bit (not static) version (CDM v2.12.28 WHQL Certified\amd64\ftd2xx.lib) as ftd2xx.amd64.lib

I also added a Makefile.ming32 to compile with i686-w64-mingw32 but I could not test this.

Feel free to cherry pick.

[gojimmypi]

these issues were manually addressed and fixed by @emard (including a much cooler Makefile!) see https://github.com/f32c/tools/issues/8

[emard]

HI

Just about something to this closed issue - compiled at my debian ujprog.exe in win32 and win64 versions and uploaded binaries to ulx3s-bin Somebody tried them and reported they don't work - can you check it too?

https://github.com/emard/ulx3s-bin/tree/master/usb-jtag/win64mingw https://github.com/emard/ulx3s-bin/tree/master/usb-jtag/win32mingw

On 2/16/19, gojimmypi notifications@github.com wrote:

Closed #9.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/f32c/tools/pull/9#event-2144267895

[gojimmypi]

hello @emard I can confirm both your 32 bit (renamed to ujprog32.exe ) and 64 bit (renamed to ujprog64.exe) compiled exe files were able to successfully upload the blinky binary to my ULX3S. I was able to do this in a standard command prompt, with elevated permissions not needed.

Admittedly, I needed to tell my AV software that I trusted the files. One ended up going to quarantine that I needed to manually restore. (I must really trust you! ;)

Although your ujprog64.exe and the 64 bit ujprog.exe that I compiled on my system are the same size, I find it curious that the binaries contents differ.

If someone is having problems, I'd check to ensure the device shows up as a COM port using FTDI drivers, and that the right USB port is being used (literally - as facing the connectors - the one on the right, closest to the LED's)

Note that the 32 bit file arrived apparently without the Windows security block setting, but the 64 bit does have it set: I did not need to check the "Unblock" checkbox to get it to work.

These tests were performed on Windows 10 64 bit; I'm not sure I have a 32 bit machine to try.

[gojimmypi]

@emard the other thing I just learned is that Windows executables can be run from within WSL!!

So, despite the native USB drivers not being available in WSL, the entire toolchain can remain in WSL by compiling those apps for Windows.

[gojimmypi]

@emard - I did stumble upon something really odd: it appears compiling the Windows ujprog.exe with -f Makefile.ming32_64 in WSL on a Windows filesystem directory (/mnt/c ...) works just fine... however when compiling on a WSL directory (/home/ ...) - the app compiles without error, but also does not appear to work.

Here are side-by side fresh git clone and make, both from the same repo just minutes apart: on the left in /mnt/c/test_mntc/tools/ujprog and on the right in /home/gojimmypi/test_wsl/tools/ujprog; Note the app on the left returns help info. The app on the right does not show anything when running ujprog.exe.

This is not the case with the linux version, that works fine (as expected!) regardless of directory:

[emard]

wow this is really strange, I have never seen something like this! There is another user that tried every ujprog.exe I have around (latest mingw 32,64 and non-mingw) and nothing worked. (finally I compiled him for raspberypi-3 and that worked :)

On 2/18/19, gojimmypi notifications@github.com wrote:

@emard - I did stumble upon something really odd: it appears compiling the Windows ujprog.exe with -f Makefile.ming32_64 in WSL on a Windows filesystem directory (/mnt/c ...) works just fine... however when compiling on a WSL directory (/home/ ...) - the app compiles without error, but also does not appear to work.

Here are side-by side fresh git clone and make, both from the same repo just minutes apart: on the left in /mnt/c/test_mntc/tools/ujprog and on the right in /home/gojimmypi/test_wsl/tools/ujprog; Note the app on the left returns help info. The app on the right does not show anything when running ujprog.exe.

This is not the case with the linux version, that works fine (as expected!) regardless of directory:

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/f32c/tools/pull/9#issuecomment-464853666

[gojimmypi]

ok, now I understand why you asked me to test those. So you've apparently seen this behavior as well - and more importantly from a "real" Linux environment. (I assume your reference was not to WSL Debian)

At first, I thought perhaps this was another manifestation of that annoying CR/CRLF issue I encountered with the https://github.com/DoctorWkt/ULX3S-Blinky/issues/2 (specifically with the lpf file: https://github.com/YosysHQ/nextpnr/issues/235 ) but in that case I was using git to check out actually in a Windows command prompt vs a WSL Ubuntu prompt; Visual Studio "saw" there were changes, but oddly nothing was highlighted.

I'd open an issue in the WSL repo, but I don't know where I'd even start. And the fact that you've seen this in Debian is even more bizarre (thus probably not WSL specific). I'll poke around some and see what I can find.

[gojimmypi]

ok, so more info on this: I've discovered the problem is not where the code is compiled, rather where it is executed. Running the same .exe file from a WSL directory (/home/...) results in the no-output, quiet fail. Copying the same .exe to a non-WSL directory (/mnt/c/...) and the code works.

This behavior was not observed with other native Windows apps launched from WSL (Notepad.exe, Calc.exe, VS Code). They all worked regardless of launch point. (but then they don't use USB drivers)

I've only recently discovered that Windows .exe files can be launched from WSL prompt at all.

ujprog.exe always seems to work properly from a Windows command prompt.

Note I added a printf("Startup!"); immediately after the main(); - and it never even displays when launching from WSL directory, but works just find when launching from /mnt/c/ in WSL...

I'm open to suggestions. Per you know how to single-step debug a Windows app compiled with x86_64-w64-mingw32-gcc ?

[emard]

HI not me, I'm running all from debian but other users have reported some unpredictable behaviour, they could not explain what and how and they tried "something" and then it "works" so your description is more informative, it matters the directory from where you start ujprog.exe

I would understand if this directory contains ftdi dll but otherwise it's unexplainable & crazy...

On 2/19/19, gojimmypi notifications@github.com wrote:

ok, so more info on this: I've discovered the problem is not where the code is compiled, rather where it is executed. Running the same .exe file from a WSL directory (/home/...) results in the no-output, quiet fail. Copying the same .exe to a non-WSL directory (/mnt/c/...) and the code works.

This behavior was not observed with other native Windows apps launched from WSL (Notepad.exe, Calc.exe, VS Code). They all worked regardless of launch point. (but then they don't use USB drivers)

I've only recently discovered that Windows .exe files can be launched from WSL prompt at all.

ujprog.exe always seems to work properly from a Windows command prompt.

Note I added a printf("Startup!"); immediately after the main(); - and it never even displays when launching from WSL directory, but works just find when launching from /mnt/c/ in WSL...

I'm open to suggestions. Per you know how to single-step debug a Windows app compiled with x86_64-w64-mingw32-gcc ?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/f32c/tools/pull/9#issuecomment-464922968

[gojimmypi]

interesting comment about the dll; I wonder if somehow the search path is processed differently in /mnt/c/ directories ? I tried moving the app to /other to see if perhaps there was an issue with ~/ user directory, but no:

this is really unfortunate, given the obvious importance of ujprog.

[emard]

HI

Thank you so much for the effort on isolating the problem, describing it in detail and making it repeatable.

Frankly I have regretted multiple times why I didn't keep FT2232 which would work out of the box with native support from lattice diamond.

Author of ujprog asked me to use few $ cheaper FT231X because he will easily maintain it the same way as he did for years on ULX2S and FT232R.

But it was not so easy. He got ULX3S with FT231X prototype on DEC 2017 and fixed ujprog to work at OCT 2018. And few days ago, he just signed-off from f32c without any will to hear about any further f32c or ujprog related issues :)

ujprog is great because it's best and fastest (when it works :), but if it doesn't ULX3S is not left only on ujprog but has 2 other USB-JTAG options:

OpenOCD mainstream accepted my FT232R/FT231X patches. Openocd organization will release good binaries for all platforms so you don't need to worry about compiling or compatibility.

FleaFPGA-JTAG (my fork) works with ULX3S FT231X and FleaFPGA-Ohm FT230X and is compileable also with mingw.

On 2/19/19, gojimmypi notifications@github.com wrote:

interesting comment about the dll; I wonder if somehow the search path is processed differently in /mnt/c/ directories ? I tried moving the app to /other to see if perhaps there was an issue with ~/ user directory, but no:

this is really unfortunate, given the obvious importance of ujprog.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/f32c/tools/pull/9#issuecomment-464942615

[gojimmypi]

Glad to help. Always nice to be appreciated. :)

It seems that from the gitter a short time later, there was quite a discussion on the FT2232 vs FT231X topic.

I would agree that for a relatively small incremental cost, if there's a substantial increase in reliability & usability - it is probably a good idea.

I'm not sure I agree with you on OpenOCD. The ujprog (usually) works out of the box, first time, default FTDI drivers when the ULX3S is plugged in. To get OpenOCD working, I had to use zadig to install libusbK drivers. Yes, perhaps minor annoyance - but an annoyance and tripping point nonetheless. Even more annoying when you come back to your computer and Windows has decided to apply updates. Of, no worries that everything you left running was closed. Hopefully everything was saved. But often Windows updates will change back to default drivers. Now that can be rather frustrating, particularly if you don't know you need to manually run zadig again.

But: I have a hard time believing the fault on the topic of ujprog operation in WSL is based solely on the ujprog code and/or the type of chip used. I'm still probably going to open a WSL issue on this, as it is just too weird and unbelievable.

Have you seen ujprog problems on plain Windows and/or plain Linux? Sounds that way with the when it works comment. In all fairness, WSL is still relatively new.

See also the What’s new for WSL in Windows 10 version 1903.

[emard]

HI

for windows user's perspective, I think most important advantage of ft2232 would be to have native support for diamond programmer. and I think we need first to prove that is possible using external ft2232 board going to ulx3s jtag.

There are many other unanswered questinos, e.g. ft2232 jtag lines must go by default high-z otherwise ESP32 jtag sharing would be in trouble

For generic ft2232 on linux: First I must run OpenOCD which will set some ft2232 registers, I have no idea what it does but from then on, diamond accepts generic ft2232 as native programmer! that's on linux, I don't know what happens on windows in that case.

most of problems of ujprog came from windows platform. Many versions xp, 7, vista, 10, 32/64 bit, multiply that with N versions of ftdi driver... you see.. for linux there are not serious issues only usb access priviledge

On 2/20/19, gojimmypi notifications@github.com wrote:

Glad to help. Always nice to be appreciated. :)

It seems that from the gitter a short time later, there was quite a discussion on the FT2232 vs FT231X topic.

I would agree that for a relatively small incremental cost, if there's a substantial increase in reliability & usability - it is probably a good idea.

I'm not sure I agree with you on OpenOCD. The ujprog (usually) works out of the box, first time, default FTDI drivers when the ULX3S is plugged in. To get OpenOCD working, I had to use zadig to install libusbK drivers. Yes, perhaps minor annoyance - but an annoyance and tripping point nonetheless. Even more annoying when you come back to your computer and Windows has decided to apply updates. Of, no worries that everything you left running was closed. Hopefully everything was saved. But often Windows updates will change back to default drivers. Now that can be rather frustrating, particularly if you don't know you need to manually run zadig again.

But: I have a hard time believing the fault on the topic of ujprog operation in WSL is based solely on the ujprog code and/or the type of chip used. I'm still probably going to open a WSL issue on this, as it is just too weird and unbelievable.

Have you seen ujprog problems on plain Windows and/or plain Linux? Sounds that way with the when it works comment. In all fairness, WSL is still relatively new.

See also the What’s new for WSL in Windows 10 version 1903.

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/f32c/tools/pull/9#issuecomment-465644387

[gojimmypi]

I wonder if these problem are perhaps related to an improper copy of DLL's at install time? Note the 64bit DLL is the larger, 314k version:

the 64 bit version appears to have been renamed and placed in my system32 directory, but not renamed in the DriverStore\FileRepository:

btw - I saw your README.md updates; for me, having either of these DLL's included in the same directory as the ujprog.exe made no difference in the case where it is launched from the "wrong" directory (e.g. not /mnt/c/ ...)

[gojimmypi]

more details on the "wrong" directory (currently noted as this in the README troubleshooting, of course for lack of better info). Perhaps it is more accurate to describe this as: when launching ujprog.exe from VoIFS. See this thread in askubuntu.

Given that - I wonder what is different in VoIFS to cause ujprog.exe to not work?

[emard]

Probably case in/sensitivity in VoIFS DOS etc in windows is ambiguous or buggy, combined to misnamed copies of 32 and 64 bit DLLs created this problem. But if it had happened to you, it will happen again to another user

I'm updating troubleshooting section to reflect recent discoveries :)

On 2/20/19, gojimmypi notifications@github.com wrote:

more details on the "wrong" directory (currently noted as this in the README troubleshooting, of course for lack of better info). Perhaps it is more accurate to describe this as: when launching ujprog.exe from VoIFS. See this thread in askubuntu.

Given that - I wonder what is different in VoIFS to cause ujprog.exe to not work?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/f32c/tools/pull/9#issuecomment-465693978