[17492] Failed to execute script __main__
Traceback (most recent call last):
File "nordicsemi/__main__.py", line 315, in <module>
File "click/core.py", line 722, in __call__
File "click/core.py", line 676, in main
File "click/_unicodefun.py", line 118, in _verify_python3_env
RuntimeError: Click will abort further execution because Python 3 was configured to use ASCII as encoding for the environment. Consult http://click.pocoo.org/python3/for mitigation steps.
This system lists a couple of UTF-8 supporting locales that
you can pick from. The following suitable locales where
discovered: af_ZA.UTF-8, am_ET.UTF-8, be_BY.UTF-8, bg_BG.UTF-8, ca_ES.UTF-8, cs_CZ.UTF-8, da_DK.UTF-8, de_AT.UTF-8, de_CH.UTF-8, de_DE.UTF-8, el_GR.UTF-8, en_AU.UTF-8, en_CA.UTF-8, en_GB.UTF-8, en_IE.UTF-8, en_NZ.UTF-8, en_US.UTF-8, es_ES.UTF-8, et_EE.UTF-8, eu_ES.UTF-8, fi_FI.UTF-8, fr_BE.UTF-8, fr_CA.UTF-8, fr_CH.UTF-8, fr_FR.UTF-8, he_IL.UTF-8, hr_HR.UTF-8, hu_HU.UTF-8, hy_AM.UTF-8, is_IS.UTF-8, it_CH.UTF-8, it_IT.UTF-8, ja_JP.UTF-8, kk_KZ.UTF-8, ko_KR.UTF-8, lt_LT.UTF-8, nl_BE.UTF-8, nl_NL.UTF-8, no_NO.UTF-8, pl_PL.UTF-8, pt_BR.UTF-8, pt_PT.UTF-8, ro_RO.UTF-8, ru_RU.UTF-8, sk_SK.UTF-8, sl_SI.UTF-8, sr_YU.UTF-8, sv_SE.UTF-8, tr_TR.UTF-8, uk_UA.UTF-8, zh_CN.UTF-8, zh_HK.UTF-8, zh_TW.UTF-8
exit status 255
Compilation error: exit status 255
I am getting this error when trying to verify a very simple app with Arduino
[47069] Failed to execute script __main__
Traceback (most recent call last):
File "nordicsemi/__main__.py", line 315, in <module>
File "click/core.py", line 722, in __call__
File "click/core.py", line 676, in main
File "click/_unicodefun.py", line 118, in _verify_python3_env
RuntimeError: Click will abort further execution because Python 3 was configured to use ASCII as encoding for the environment. Consult http://click.pocoo.org/python3/for mitigation steps.
Cross-posting is against the Arduino forum rules. The reason is that duplicate posts can waste the time of the people trying to help. Someone might spend a lot of time investigating and writing a detailed answer on one topic, without knowing that someone else already did the same in the other topic.
Repeated cross-posting can result in a suspension from the forum.
In the future, please only create one topic for each distinct subject matter. This is basic forum etiquette, as explained in the "How to get the best out of this forum" guide. It contains a lot of other useful information. Please read it.
This bug is being tracked by the Arduino IDE developers here:
I investigated and found that I was able to reproduce the error when using the "0.5.3.post12" version of the adafruit-nrfutil tool that is bundled with your boards platform:
/Users/per/Library/Arduino15/packages/smartwatch-boards/hardware/nRF5/0.1.4/tools/adafruit-nrfutil/adafruit-nrfutil dfu genpkg --application-version 65535 --application /private/var/folders/sx/07hx_hp11nz50sf4ljwylj080000gn/T/arduino-sketch-BDB5AD5F69F49B6353CEC689ABE08A1D/sketch_jan17a.ino.hex /private/var/folders/sx/07hx_hp11nz50sf4ljwylj080000gn/T/arduino-sketch-BDB5AD5F69F49B6353CEC689ABE08A1D/sketch_jan17a.ino.zip
[7696] Failed to execute script __main__
Traceback (most recent call last):
File "nordicsemi/__main__.py", line 315, in <module>
File "click/core.py", line 722, in __call__
File "click/core.py", line 676, in main
File "click/_unicodefun.py", line 118, in _verify_python3_env
RuntimeError: Click will abort further execution because Python 3 was configured to use ASCII as encoding for the environment. Consult http://click.pocoo.org/python3/for mitigation steps.
This system lists a couple of UTF-8 supporting locales that
you can pick from. The following suitable locales where
discovered: af_ZA.UTF-8, am_ET.UTF-8, be_BY.UTF-8, bg_BG.UTF-8, ca_ES.UTF-8, cs_CZ.UTF-8, da_DK.UTF-8, de_AT.UTF-8, de_CH.UTF-8, de_DE.UTF-8, el_GR.UTF-8, en_AU.UTF-8, en_CA.UTF-8, en_GB.UTF-8, en_IE.UTF-8, en_NZ.UTF-8, en_US.UTF-8, es_ES.UTF-8, et_EE.UTF-8, eu_ES.UTF-8, fi_FI.UTF-8, fr_BE.UTF-8, fr_CA.UTF-8, fr_CH.UTF-8, fr_FR.UTF-8, he_IL.UTF-8, hr_HR.UTF-8, hu_HU.UTF-8, hy_AM.UTF-8, is_IS.UTF-8, it_CH.UTF-8, it_IT.UTF-8, ja_JP.UTF-8, kk_KZ.UTF-8, ko_KR.UTF-8, lt_LT.UTF-8, nl_BE.UTF-8, nl_NL.UTF-8, no_NO.UTF-8, pl_PL.UTF-8, pt_BR.UTF-8, pt_PT.UTF-8, ro_RO.UTF-8, ru_RU.UTF-8, sk_SK.UTF-8, sl_SI.UTF-8, sr_YU.UTF-8, sv_SE.UTF-8, tr_TR.UTF-8, uk_UA.UTF-8, zh_CN.UTF-8, zh_HK.UTF-8, zh_TW.UTF-8
exit status 255
Compilation error: exit status 255
% /Users/per/Library/Arduino15/packages/smartwatch-boards/hardware/nRF5/0.1.4/tools/adafruit-nrfutil/adafruit-nrfutil version
adafruit-nrfutil version 0.5.3.post12
However, I was not able to reproduce the error when I replaced /Users/per/Library/Arduino15/packages/smartwatch-boards/hardware/nRF5/0.1.4/tools/adafruit-nrfutil/adafruit-nrfutil with the 0.5.3.post16 version in use in the latest "Adafruit nRF52" boards platform:
So I think the easiest fix would be for you to update the adafruit-nrfutil tool that is bundled with your boards platform.
Ok. I am new to this and you have been very patient. So, in the board definition I created, use an updated version of the adafruit, right? I could also run a simple test by selecting the latest adafruit board for nRF52, correct? I see Adafruit Feather nRF52832 listed, is that what I should use?
Yes. Typically tool dependencies are distributed separately from the boards platform, as you are doing with the nRF52D6Fitness:gcc-arm-none-eabi and nRF52D6Fitness:openocd dependencies:
But for some reason the developer of the platform (I realize you inherited this decision from the platforms yours is based on ) decided to put the adafruit-nrfutil tool in the platform itself, so it is located here in your platform:
So you should be able to just replace that adafruit-nrfutil file with the one from here:
Yes, that is an excellent approach.
I used the Tools > Board > Adafruit nRF52 > Feather nRF52840 Sense board selection for my test because that board was mentioned in the bug report.
I think it is reasonable, but keep in mind that if you are intending your boards platform to be used by others in the Arduino community then you are sure to get reports of people having the same problem, since some of them are likely to be using Arduino IDE 2.x.
You can hope that a fix will be found for the bug in Arduino IDE 2.x soon, but the bug is very confusing and might even be in some of the software Arduino IDE 2.x depends on instead of in the Arduino IDE 2.x codebase. This means it might take some time before a fix is made. So it seems to me that if a workaround is available that only requires spending a few minutes to replace one file with another, it would be worth doing.
Incredibly helpful. Thank you. Trying to test now. If copying the adafruit-nrfutil down and replacing the one I have works (I am testing but need to address the “adafruit-nrfutil” cannot be opened because the developer cannot be verified. issue), the next step would be for me to put the right version in my package, correct? I see the dependency listed in the .json file, but I need to replace it in my repo, correct? Release -> Update .json (MD5 + file size + version) -> uninstall boards -> reinstall boards. Do I have that correct?
Well, it depends on what you mean by "package". A package is a collection of platforms and tools distributed by a "vendor" or packager. It is all the things under the packages[0] object in your package index file:
The smartwatch-boards:nRF5@0.1.4 platform
The smartwatch-boards:gcc-arm-none-eabi@5_2-2015q4 tool
The smartwatch-boards:openocd@0.10.0-dev.nrf5 tool
Unfortunately there is a lot of incorrect use of terminology when people are talking about Arduino platforms, packages, and cores. So you will sometimes see people using the term "package" when they really mean "platform".
But back to your question, the adafruit-nrfutil tool is not currently in your smartwatch-boards package in the sense that the gcc-arm-none-eabi and openocd tools are in the package. Instead, the adafruit-nrfutil tool is in the platform:
You could move the tool to the package if you like. This would mean you must produce archive files (e.g., ZIP or .tar.gz files) of the tool and make the files available for download from the Internet. For example, the macOS version of your smartwatch-boards:gcc-arm-none-eabi@5_2-2015q4 tool is downloaded from here:
The more simple thing to do would be to leave the adafruit-nrfutil tool in the platform where it is now and simply replace the current file in the platform with the newer working version.
After reading that long and convoluted answer, maybe you can see why it is important for us to have and use standardized terminology when writing about complex technical subjects. It is really sad that the already very complicated subject of the Arduino platform framework has been made even more difficult to discuss and understand by the inconsistent and overlapping terminology in use for the main components of the system.
Ok. I am new to this, which is likely obvious already, and will work on learning the appropriate terminology. By package I was referring to the repo with all my files in it (platform, boards, etc.). I replaced the adafruit-nrfutil with the one you referenced in your previous post and did what you said and generating a new tar.gz, updated the .json file, uninstalled the boards I created (0.1.4) and installed the new one (0.1.5), which now should have the updated adafruit-nrfutil.
Ok. I don't think I've ever been so excited to fail. On Arduino 2.0.3 (which I will move forward with from here on out) I got the following when the st-link is connected and I ran Upload Using Programmer:
Open On-Chip Debugger 0.10.0-dev-gdc53227 (2016-04-09-13:45)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 0
0x4000
adapter speed: 10000 kHz
nrf52.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x000008e8 msp: 0x20000400
** Programming Started **
auto erase enabled
nrf52.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000001e msp: 0x20000400
wrote 4096 bytes from file /private/var/folders/b9/jzy3mm9s1yx5sd1jh3lbs2gm0000gn/T/arduino-sketch-3618EEE9983E43C8A9B5F41E8AC96E57/hello-world.ino.hex in 0.138928s (28.792 KiB/s)
** Programming Finished **
** Verify Started **
nrf52.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20000400
verified 2948 bytes in 0.040313s (71.414 KiB/s)
** Verified OK **
** Resetting Target **
shutdown command invoked
I might need to follow a similar pattern here for openocd, but at least I know how to do it. Thank you, @ptillisch!
At any rate, you solved the "Click will abort further execution because Python 3 was configured to use ASCII as encoding for the environment." error, which is great news.