Windows Environment Flash Issue Under Eclipse

[MarcusW]

For some weeks now, I’ve been beating my head against an environmental problem with the ESP32 environment on Windows 7, and I was hoping that someone here might be able to give me a pointer in the right direction.
I’ve set up the pre-packaged msys2 environment and toolchain release from March 30th, and git cloned the latest esp-idf (as late as yesterday), and installed eclipse neon, all according to the latest instructions.
Everything works well, with only one exception, I cannot make flash from within eclipse. It does work from the msys32 built in command window.
What I get on the eclipse console when doing a “make flash” target is the following:

...
make[1]: Entering directory 'C:/msys32/home/Marcus/esp/hello_world/build/xtensa-debug-module'
ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
File "C:\msys32\mingw32\lib\python2.7/hashlib.py", line 147, in <module>
globals()[__func_name] = __get_hash(__func_name)
File "C:\msys32\mingw32\lib\python2.7/hashlib.py", line 97, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5
ERROR:root:code for hash sha1 was not found.
Traceback (most recent call last):
File "C:\msys32\mingw32\lib\python2.7/hashlib.py", line 147, in <module>
globals()[__func_name] = __get_hash(__func_name)
File "C:\msys32\mingw32\lib\python2.7/hashlib.py", line 97, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha1
ERROR:root:code for hash sha224 was not found.
Traceback (most recent call last):
File "C:\msys32\mingw32\lib\python2.7/hashlib.py", line 147, in <module>
globals()[__func_name] = __get_hash(__func_name)
File "C:\msys32\mingw32\lib\python2.7/hashlib.py", line 97, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha224
ERROR:root:code for hash sha256 was not found.
Traceback (most recent call last):
File "C:\msys32\mingw32\lib\python2.7/hashlib.py", line 147, in <module>
globals()[__func_name] = __get_hash(__func_name)
File "C:\msys32\mingw32\lib\python2.7/hashlib.py", line 97, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha256
ERROR:root:code for hash sha384 was not found.
Traceback (most recent call last):
File "C:\msys32\mingw32\lib\python2.7/hashlib.py", line 147, in <module>
globals()[__func_name] = __get_hash(__func_name)
File "C:\msys32\mingw32\lib\python2.7/hashlib.py", line 97, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha384
ERROR:root:code for hash sha512 was not found.
Traceback (most recent call last):
File "C:\msys32\mingw32\lib\python2.7/hashlib.py", line 147, in <module>
globals()[__func_name] = __get_hash(__func_name)
File "C:\msys32\mingw32\lib\python2.7/hashlib.py", line 97, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha512
Traceback (most recent call last):
File "C:/msys32/home/Marcus/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 2349, in <module>
_main()
File "C:/msys32/home/Marcus/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 2342, in _main
main()
File "C:/msys32/home/Marcus/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 2100, in main
operation_func(esp, args)
File "C:/msys32/home/Marcus/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 1626, in write_flash
calcmd5 = hashlib.md5(image).hexdigest()
AttributeError: 'module' object has no attribute 'md5'
make: *** [/home/Marcus/esp/esp-idf/components/esptool_py/Makefile.projbuild:53: flash] Error 1
make[1]: Leaving directory 'C:/msys32/home/Marcus/esp/hello_world/build/xtensa-debug-module'

I get this same problem under the new python script under eclipse, as well as under the previous shell script invoked from eclipse. All was set up according to the latest instructions online (last try yesterday).
I know that this is a problem on my development environment, as I have used the same setup files and instructions on a second PC, and it builds properly from eclipse on that machine.
The msys32 environment seems very self-contained, and even more so from eclipse, where the path is set to only directories under the msys2 environment, but something is throwing off the make flash target, and it would seem to be deep in the guts of python (my guess is its somewhere in loading its internal security modules), where I have no experience.
The principle differences between the machine were it works and the one which fails is that the machine which fails:
1. Had a standalone python 2.7 environment installed on it, which has since been removed, and rebooted, but the problem remains.
2. Has a GIT windows client installed on it.
3. Has the self-contained esp8266 development environment installed on it under c:/MinGW and an older version of eclipse.

I would appreciate any advice on what to do next or if anyone else has seen this problem.

Thanks.

[ESP_Angus]

Hi Marcus,

Sorry for the slow reply. Did you make any progress with this?

Is it possible that another version of python.exe has slipped onto the PATH somehow? Or that the PYTHONPATH environment variable is being overriden somewhere?

[MarcusW]

Hi ESP_Angus,
Thanks for taking the time to reply. I'd put this aside for a while and just flashed from the msys32 command prompt, as it was getting too frustrating. Under the command prompt, "make flash" works, as does calling the python script which was specified to run under Eclipse. I've also tried "python -version" (syntactically wrong, but prints out a "usage..." with the exe location) from both eclipse and the command line, and they both show the same python location.

The other strangeness I've seen is in this environment when building the i2c examples, I need to explicitly include
#include <limits.h>
#include "sdkconfig.h"
or else eclipse shows errors that it cannot find some of the #defined values. (the make builds properly either way). I did not need to do this on the other environment which works.

I knew that it was a long shot, but I posted the question to the forum in case anyone had run across the same thing.

Thanks again for the reply,
MarcusW

[ESP_Angus]

The other strangeness I've seen is in this environment when building the i2c examples, I need to explicitly include
#include <limits.h>
#include "sdkconfig.h"
or else eclipse shows errors that it cannot find some of the #defined values. (the make builds properly either way). I did not need to do this on the other environment which works.

This usually implies that Eclipse's path discovery isn't parsing the build output properly to find the include search directories, although it's odd that you can fix it by editing the file in this way. Can you confirm that removing these #includes causes the errors in Eclipse to reappear? (I'm thinking maybe re-compiling the file with the changes gave Eclipse a second chance to parse the include paths.)

(The settings I'm referring to are the ones shown here.)