Windows MinGW64 executables have problems

[xor-gate]

Using:

• toolchain mingw-w64\x86_64-5.3.0-win32-sjlj-rt_v4-rev0
• libusb 1.0.20
• cmake 3.2

Problems:

• Printf formatting is broken for (e.g %zu)
• Libusb prints errors on nucleo-64 (stm32l476), "mbed-enabled"
• Hex encoded ascii serial (Already in issue STLINK/V2-1 and STLINK/V2 SN incompatibility on NUCLEO-F401RE board #417)

Log:

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --serial
libusb: error [init_device] device '\\.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
303636454646343835353530373535

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --descr
libusb: error [init_device] device '\\.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
L4 device

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --flash
libusb: error [init_device] device '\\.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
0xzx

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --sram
libusb: error [init_device] device '\\.\USB#VID_0483&PID_374B&MI_02#6&2E55A1F8&0&0002' is no longer connected!
0xzx

C:\Users\Jerry\Downloads\stlink-deprecate_autotools\build>st-info.exe --probe
Found zu stlink programmers

This is a followup of issues found in PR #434 when updating MingGW/MSYS build for windows.

[xor-gate]

Probably the device <devpath> is no longer connected! is due to the nucleo is a composite device:
http://libusb.6.n5.nabble.com/libusb-Two-libusb-devices-for-a-single-physical-device-td5715528.html

[texane]

%zu formatting issue fixed (the hard way). 3f7d0f9..72fbf6a

[xor-gate]

Yeah indeed, this seems brute-forced. I'm not 100% happy with this "fix", but for now it works. I'm wondering why the MinGW64 toolchain libc doesn't implement that. I'm not sure if the printf format we used is C99 or GNU99.

[texane]

It will do until a better solution is proposed. A tool / code first has to
be correct
from the functional point of view. Of course, it is better if the
implementation is
good too, but stdio makes that very difficult.

2016-06-20 20:48 GMT+02:00 Jerry Jacobs notifications@github.com:

Yeah indeed, this seems brute-forced. I'm not 100% happy with this "fix",
but for now I don't care. I'm wondering why the MinGW64 toolchain libc
doesn't implement that. I'm not sure if the printf format we used is C99 or
GNU99.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#438 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAEeH2l9yXt8mGa7KRu444N2I_uqHPHGks5qNuBrgaJpZM4I5zeh
.

[xor-gate]

Yes I agree it has to be functional.

It seems we don't use it correctly as others have the same problem:
http://stackoverflow.com/questions/10678124/mingw-gcc-unknown-conversion-type-character-h-snprintf
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/4F893862.1060206@users.sourceforge.net/
http://www.embedded.com/electronics-blogs/programming-pointers/4007254/A-case-study-in-portability

The suggestion would be just to use everywhere where possible the formatting from <inttypes.h> like PRIuMAX for size_t.

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/inttypes.h.html

I will leave this open, for now it is okay. But needs correct reworking.

[texane]

I checked that all the cases were safe to downcast to unsigned int.
Regarding PRIuMAX,
it needs a cast too, plus it adds the macro. So I do not see any added
value in our case.
OK to let it open, it was not the only problem of the issue.

2016-06-20 20:59 GMT+02:00 Jerry Jacobs notifications@github.com:

Yes I agree it has to be functional.

It seems we don't use it correctly as others have the same problem:

http://stackoverflow.com/questions/10678124/mingw-gcc-unknown-conversion-type-character-h-snprintf

https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/4F893862.1060206@users.sourceforge.net/

http://www.embedded.com/electronics-blogs/programming-pointers/4007254/A-case-study-in-portability

The suggestion would be just to use everywhere where possible the
formatting from <inttypes.h> like PRIuMAX for size_t.

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/inttypes.h.html

I will leave this open, for now it is okay. But needs correct reworking.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#438 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAEeH_B_wy2CzK8U0ew1BTh6mQL84Q3Hks5qNuMegaJpZM4I5zeh
.

[xor-gate]

Related to #465, I have tested this myself and --probe seems to work now as expected. Others not tested.

[Nightwalker-87]

Can somebody with a MinGW64 environment test this properly?
Has this been addressed in Release v1.3.0?

[slyshykO]

This is output for stlink-v1.5.1

e:\test-st\stlink-1.5.1\build-mingw64>st-info.exe --serial
303637324646343835353530373535

e:\test-st\stlink-1.5.1\build-mingw64>st-info.exe --descr
F7 device

e:\test-st\stlink-1.5.1\build-mingw64>st-info.exe --flash
0x100000

e:\test-st\stlink-1.5.1\build-mingw64>st-info.exe --sram
0x50000

e:\test-st\stlink-1.5.1\build-mingw64>st-info.exe --probe
Found 1 stlink programmers
 serial: 303637324646343835353530373535
openocd: "\x30\x36\x37\x32\x46\x46\x34\x38\x35\x35\x35\x30\x37\x35\x35"
  flash: 1048576 (pagesize: 2048)
   sram: 327680
 chipid: 0x0449
  descr: F7 device

Before v1.5.1, I observe issues in output of st-info.

[Nightwalker-87]

Could be PR 680, 695 or 704...

[slyshykO]

I give up 😪.
PR #680 still have an issue.
PR #695 & #704 won't compile (somesibg wrong with cmake project).

CMake Error at CMakeLists.txt:116 (set_target_properties):
  set_target_properties called with incorrect number of arguments.

[Nightwalker-87]

Don't try to force it - things will become clearer someday. I may take a closer look, as soon as I find some time. Can you give me some advice regarding a correct MinGW setup in a Win10 VM (which appears useful anyway) besides the (outdated?) documentation?

[slyshykO]

• I did never really "install" toolchains. Always just download archive and simply extract it in the destination folder.
• A folder path should contain only ASCII without spaces.

For compile with a certain toolchain, I usually write a simple *.bat script. Like this:

set STLINKVER=git
set CMAKE=e:\test-st\cmake-3.4.0-win32-x86\bin\cmake.exe

set "CUR_DIR=%CD%"
cd %~dp0

PATH=e:\test-st\mingw64\bin;e:\test-st\cmake-3.4.0-win32-x86\bin\;%PATH%

cd %~dp0\stlink-%STLINKVER%

mkdir build-mingw64

cd .\build-mingw64

%CMAKE% -G "Ninja" -DCMAKE_BUILD_TYPE=Release ..

%CMAKE% --build .

[Nightwalker-87]

@slyshykO: I have some news on this. As you can see, I have created new branches for old versions that fix the git version tag bug (introduced when the version numbering scheme was alligned for earlier versions) in each of these earlier versions, which prevented cmake from compiling. With this fix (which is nothing functional really, and did not exist in earlier days) I can compile quite a few releases with the newest cmake and MinGW-w64 going backwards. With this I find that compiling works without any warnings down to v1.4.0 (incl.). Testing st-info after each compile gives:

C:\Users\user-10\git\stlink\scripts>st-info.exe --probe
Found 1 stlink programmers
 serial: 3f70050132124647524b4e00
openocd: "\x3f\x70\x05\x01\x32\x12\x46\x47\x52\x4b\x4e\x00"
  flash: 65536 (pagesize: 1024)
   sram: 20480
 chipid: 0x0410
  descr: F1 Medium-density device

... which is very nice to see. Going back further, warnings occur in v1.3.1 and v1.3.0, but that does not prevent the compilation to conclude successfully down to the very end. The result from st-info.exe --probe is the same as above. I have completely wiped the previous build before every new build and can see the the version string changes when the package is built at the end of compilation, so I can rule out any accidental rebuilds of already tested versions. Can you try the v1.3.0-patch branch to verify that on a second windows environment? For convenience you may use the latest cmake and MinGW tools, if you like. It should not affect whether the build is successful or not, I shall think by now.

Looking at this I think this issue here has been finally fixed with Release v1.4.0, as all warnings are resolved since then, but as mentioned before, an easy verify should be of common interest.

[slyshykO]

On my PC I receive appropriate output for v1.5.1-patch. Libusb was updated to 1.0.22 in this version.
Before v1.5.1-patch libusb warnings appear in the output.

[Nightwalker-87]

@slyshykO: Could be that a newer libusb package had accidentally been reused during my previous tests. I can hardly tell by now, but however - the key fact is that I can now somehow reproduce your observations regarding v1.5.1.

This is the history of bugfixing related to this issue:
v1.3.1: Building succeeds with compilation warnings, but some features don't work (see #846)
v1.4.0: libusb 1.0.21 introduced a bug causing builds to fail. Several fixes for MinGW (#578, #582, #584, #610) mainly address this issue.
v1.5.0: - no change -
v1.5.1: Update to libusb 1.0.22 finally fixes the remaining related bug in this external library. Function 'libusb_set_debug' is deprecated since then, what was subsequently fixed in #704.

With these findings we are now finally able to close this issue as resolved and verified.